用途
brainstorm 用于在动手实现之前澄清需求。当开发提示中包含新功能、功能变更或缺陷报告，且细节尚不清晰时，它通过自然协作对话，把一段开发提示逐步转化为经过验证的 PRD 和设计文档。整个流程分为三个阶段，必须按顺序执行，且不得跳过任何验证关口。
主要能力
阶段一：理解
- 先检查当前项目状态（文件、文档、近期提交）；若不存在代码仓库，应说明这一限制并基于现有证据推进。
- 在详细提问前先评估范围：若请求包含多个独立子系统（例如同时包含聊天、文件存储、计费和分析的平台），应立即指出，而不是继续细化一个需要先拆分的项目。
- 当项目过大、不适合单个 PRD 时，帮助用户拆分为子项目：独立部分是什么、彼此如何关联、按什么顺序构建；然后对第一个子项目执行常规流程，每个子项目各自拥有 PRD → 设计 → 计划循环。
- 每次只问一个聚焦问题，直到问题、目标、约束和成功标准足够清晰。
- 每个澄清问题至少提供两个具体选项，标注其中一个为推荐并简要说明理由（更贴合证据、约束或最简路径），同时保留开放式回答以覆盖选项未涵盖的意图。
阶段二：PRD
- 基于 assets/prd.md 草拟 PRD，保留阶段一的结论，不虚构范围。
- 功能需求使用唯一且稳定的 FR-* 编号，非功能需求使用唯一且稳定的 NFR-* 编号。
- 验收标准使用唯一且稳定的 AC-* 编号，每条映射到 FR-/NFR- 编号，并保证可观测。
- 每条“当前行为”声明都需有仓库证据支持；全新项目应省略该章节。
- 对不适用的可选章节直接删除，而不是写 N/A。
- 立即保存到 docs/agentic-engineering/prd/<session>/<subject>.md，状态为 status: draft。<session> 为当前日期 YYYY-MM-DD；<subject> 为简洁的 kebab-case，冲突时追加 -2、-3 等后缀。frontmatter 的 subject 设为同一 slug。写入失败时报错并停止。
- 报告保存路径并附简短摘要，请用户验证文档；根据反馈修改并再次询问，直至用户批准。
- 批准后将状态设为 status: validated，进入阶段三。
阶段三：设计
- 只问设计层面的问题：接口契约、数据形态、错误处理、验证策略；不重复已验证 PRD 已回答的内容，提问风格与阶段一一致。
- 基于 assets/design.md 草拟设计文档。
- 将 prd: 指向已验证的 PRD 路径，并在 Goal & PRD Reference 与 Verification & Testing 中映射其 FR-/NFR-/AC-* 编号。
- 在 Alternatives Considered 中记录被否决的方案及理由。
- 对不适用的可选章节直接删除，而不是写 N/A。
- 立即保存到 docs/agentic-engineering/specs/<session>/<subject>.md，状态为 status: draft；复用 PRD 的 <session> 和 <subject>，使两份产物按名称配对；冲突与写入失败规则同阶段二。
- 报告保存路径并附简短摘要，请用户验证；根据反馈修改并再次询问，直至用户批准。
- 批准后将状态设为 status: validated，并报告设计文档路径，作为规划阶段的输入。
使用方式
按阶段一 → 二 → 三的顺序使用；每个阶段产出文档后需经用户明确批准才能进入下一阶段。产物位置固定为 docs/agentic-engineering/prd/ 与 docs/agentic-engineering/specs/ 下的日期-主题路径。
适用场景
适用于新功能、功能变更或缺陷报告在实现前需要澄清与文档化的开发协作场景，尤其是希望先形成可验证 PRD 与设计文档、再进入规划阶段的团队工作流。也可用于识别并拆分过大的项目范围。
限制与约束
- 始终遵守三条不变量：未经用户明确同意不得执行 git commit（批准保存产物或继续流程不等于同意提交）；不创建实现计划；不检查、编辑或询问 .gitignore。保存首个产物后可原样提示：Consider adding docs/agentic-engineering/ to .gitignore manually.
- 无代码仓库时只能基于现有证据工作。
- 文档必须经用户逐份批准后才从 draft 转为 validated。
- 资料未提供安装命令、收费或平台信息。