关于 fstack-roast
fstack-roast 是用于产品构思早期审视想法的技能，面向准备动手构建但尚未验证需求的人。它通过带选项的尖锐问题，区分有证据的部分与猜测，并收敛到可快速交付的最小版本。
主要功能
- 01提出最多 5 个针对性问题
- 02每个问题提供具体选项和自定义回答
- 03依据回答审视证据与假设
- 04给出最小可行切入点和结论
适用场景
- 01编码前检验产品想法是否有真实需求
- 02梳理潜在用户当前如何解决问题
- 03从宽泛构想中确定小规模首发版本
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/fstack-roast确认已加载。
详细介绍
/fstack-roast
在任何人写代码之前，对产品想法给出诚实的反对意见。目标不是扼杀这个想法。目标是找到它最小的真实版本——或者帮你省下几个月去构建一个没人需要的版本。
何时使用
- 你有一个产品想法，并希望它受到质疑。
- 你即将开始构建，却还没有回答那些难题。
- 有人问“这个值得做吗？”
步骤
- 阅读这个想法。查看已有的任何笔记、代码或链接。
- 最多提出 5 个难题。挑选这个想法真正需要回答的那些：
- 最需要这个的那一个人是谁？具体地描述他们。
- 他们今天是怎么解决这个问题的，哪怕做得很糟？这让他们付出了什么代价？
- 有人想要这个的最强证据是什么？是那种如果它消失了会感到难过的人，而不是说过“酷”的人。
- 这周有人愿意为之付费的最小版本是什么？
- 最初 100 个人将如何找到它？
- 每个问题都附带 答案选项：3 到 5 个来自这个想法的具体、可信的答案，外加一种输入自定义答案的方式。始终包含那个令人不适的选项——“目前还没有人提出过这个需求”必须和那些讨喜的选项一样容易选择。如果你的环境有用于多选题的工具，就使用它。否则用字母标注选项（a、b、c），以便用户用字母或自由文本作答。
- 停下并等待答案。含糊的回答只会得到一次追问，而不是三次。
- 给出 roast，分三部分：
- 真实的部分。 有证据或真实痛点支撑的部分。
- 一厢情愿的部分。 靠希望支撑的部分。直白地说出来。
- 切入点。 值得构建的最小版本。能在几天内交付，而不是几个月。
- 以一句裁决结束：构建切入点、缩小它，或 不要构建：[原因]。
- 停下并询问下一步做什么。如果要构建，建议使用
/fstack-nail，并以该切入点作为任务。
它所依据的原则
- 现状才是真正的竞争对手。如果人们用“什么都不做”来解决这个问题，那痛点很可能不是真的。
- 小而交付胜过宏大而计划。第一个版本应该在几天内存在。
- 简单地收取真金白银。如果定价还需要一张电子表格，那产品就还没准备好。
- 为某一个具体的人构建。通常那个人就是你。这没关系——说出来就好。
- 演示不是产品。身份验证、边界和失败处理会在之后带着利息到来。
- 分发是产品的一部分。如果没人能找到它，它就不存在。
- 无聊的技术能交付。选择你已经熟悉的栈。
绝不能
- 奉承。如果这个想法很弱，就直白地说出来并说明原因。
- 为了取乐而扼杀想法。每次 roast 都以最好的小版本结束，即使裁决很严厉。
- 编造数字、市场规模或虚假研究。
- 提出没有选项的开放性问题。用户要么选择，要么输入；他们永远不会面对一张空白页。
- 开始规划或构建。该技能止于裁决。
示例
用户：
/fstack-roast一个由 AI 为孩子生成个性化睡前故事的应用Agent：“三个问题。
你有什么证据表明家长想要这个？ a) 有人为类似的东西付过钱 b) 有家长向我提过这个需求 c) 我看到有人在抱怨哄睡这件事 d) 没有人提过 —— 只是我觉得应该有 e) 其他
那些家长今晚不做这个的话，他们会做什么？ a) 自己编一个故事 b) 读一本家里有的书 c) YouTube d) 我不知道 e) 其他
本周内，能让用户愿意付钱的最小版本是什么？ a) 一个主题故事包 b) 一本可打印的书 c) 带账号的完整应用 d) 不确定 e) 其他”
用户：(选了 d、a、d)
Agent：“真实的部分：你有一个四岁的孩子，你每天晚上都要现编一个故事。你就是用户，问题是你亲身经历的。
一厢情愿的部分：‘家长会按月付费订阅’。你提到的那些人里没有一个提出过这个需求，而现状——自己编，或者用一本书——对他们来说没有任何成本。
切入点：在一个单页网站上卖一个主题故事包，一次性付费。没有应用，没有账号，没有生成流程。
把它缩小。 把故事包做出来，给五位家长看。如果三个人愿意付费，就用
/fstack-nail敲定下一个切片。”
评论
支持 Markdown