brainstorming

头脑风暴

通过协作对话，将原始意图转化为共同理解——在编写任何规格说明或动手编写任何代码之前。这项技能是探索阶段遵循的提问规范；write-idea 和 write-prd 都假定已经进行过这样的对话。

在完成以下探索并获得用户确认方向之前，不要调用任何实现技能、编写任何代码或搭建任何内容。无论请求看起来有多简单，都必须遵守。

反模式：“这件事太简单，不需要探索”

待办列表、单函数实用工具、配置变更——这些都要经过探索。“简单”的请求最容易因为未经检验的假设而造成大量无谓工作。对于真正简单的工作，探索可以只包含三个问题、耗时两分钟，但必须进行。

提问规范

• 每条消息只问一个问题。 需要深入探讨的主题应通过一系列问题展开，绝不能变成问卷。
• 优先使用选择题，尤其是选项可以列举时——提供两个或三个选项，将推荐选项放在首位并标注 (Recommended)，不要提供 Other 选项。如果选项确实无法预先确定，也可以开放提问。结构化提问工具会提供自定义回答；没有此类工具时，就在聊天中提出同一个问题，并接受自定义回答。
• 先探索，再提问。 首先检查项目状态——文件、文档、CONTEXT.md、docs/specs/ 中的活跃规格说明、docs/history/specs/ 中的已退役规格说明，以及近期提交。代码库能够回答的问题，不要浪费用户时间去问。
• 关注是什么、为什么、为谁——而非如何实现。 数据库、API、框架和架构属于技术规格阶段；在此阶段提出这些问题会带偏产品讨论。
• 严格遵循 YAGNI。 对每项功能都要问：能否用最小版本实现价值？

提问阶段

按顺序进行；如果对话或代码库已经回答了某项内容，则跳过。至少问 3 个问题，最多约 6 个——一旦问题、用户和范围都已明确，就尽早停止。

1. 问题／痛点——这要解决什么具体问题？是什么促使用户提出这个需求？如果含义不明确，提供 2–3 种解读。
2. 目标用户和使用场景——这是为谁设计的？在工作流的哪个环节使用？他们目前如何应对？
3. 范围——理想的 V1 规模：最小可行产品、完整功能还是平台。推荐前两者之一。
4. 目标——快速见效、战略性投入，还是持续增值的功能？以及：“怎样才能让它的价值提升 10 倍，而不只是小幅改进？”
5. 依赖项——它会涉及或扩展现有功能吗？从代码库中列出可能相关的功能。
6. 成功标准——我们如何判断它是否成功？

收敛方向

当理解已经足够完整时：

1. 提出 2–3 种方案，说明各自的权衡，并首先给出你的推荐方案及理由。
2. 分段呈现方向，根据复杂度调整篇幅（简单情况用几句话，复杂情况用 200–300 字），每次都先让用户确认，再继续下一部分。
3. 随着共识逐步形成，记录相关表述——对话中明确的术语应立即写入 CONTEXT.md；通过三部分关卡且难以逆转的决策应记录为 ADR。

结果的去向

对话本身就是交付物——将它路由到相应流程，而不是重复创建：

• 产品层面的想法（市场问题、尚未确定的解决方案形式）→ write-idea（生成 docs/specs/<slug>/_idea.md）。
• 已准备好撰写规格说明的功能 → write-prd（综合本次对话；不会重新访谈）。
• 重构或 Bug 修复（不改变产品行为）→ 直接使用 write-techspec——它会创建规格文件夹，并生成精简的 _prd.md，不会进行产品访谈。
• 简单且清楚的改动（单行修复、拼写错误、配置调整）→ 直接实施，不创建规格文件夹；并明确说明这一点。

如果代码库包含 docs/agents/spec-routing.md，请遵循其中的路由表——它是该项目此列表的权威版本。

不要单独编写设计文档——成果应保存在规格流程的产物（_idea.md、_prd.md）中。

核心原则

一次只问一个问题 · 优先采用多选题 · 提问前先探索 · 严格遵循 YAGNI · 确定方案前始终提出备选方案 · 逐步验证 · 如果某个回答推翻了先前的假设，随时准备回头调整。