Brainstorming 是一个用于开发前需求澄清的技能，适用于开发提示中包含新功能、功能变更或缺陷报告、且需要在实施前进一步澄清的场景。它通过自然的多轮协作对话，把开发提示转化为经过验证的产品需求文档（PRD）和设计文档，并按三个阶段依次执行，不跳过任何验证关口。
用途与定位 该技能面向开发流程的早期阶段：在真正实现之前，先把问题、目标、约束和成功标准澄清，再把结论固化为 PRD 和设计文档。它明确不生成实施计划，也不在未经用户明确同意时执行 git commit；获得保存产物或继续流程的许可不等于获得提交许可。它不检查、不编辑、不询问 .gitignore，仅在保存第一个产物后可以提示用户考虑手动将 docs/agentic-engineering/ 加入 .gitignore。
阶段一：理解 先检查当前项目状态（文件、文档、近期提交）；若不存在仓库，则说明该限制并使用现有证据。在提出详细问题前先评估范围：如果请求包含多个独立子系统（例如同时包含聊天、文件存储、计费和数据分析的平台），应立即指出，避免在需要先拆解的项目上细化细节。项目过大时，帮助用户拆分为子项目，明确独立部分、相互关系与构建顺序，再对第一个子项目走正常流程；每个子项目各自经历 PRD → 设计 → 计划循环。澄清问题时一次只问一个聚焦问题，直到问题、目标、约束和成功标准实质清晰。每个澄清问题至少提供两个具体选项，标注一个推荐项并简要说明它最符合证据、约束或最简路径的原因；当选项无法覆盖用户意图时，保留开放式回答。
阶段二：PRD 基于 assets/prd.md 起草 PRD，保留阶段一的结论，不虚构范围。为功能需求分配唯一稳定的 FR-* 编号，为非功能需求分配唯一稳定的 NFR-* 编号；为验收标准分配唯一稳定的 AC-* 编号，映射到对应的 FR-/NFR- 编号，并确保每条标准可观察。每条“当前行为”声明都需有仓库证据支持；全新项目则省略该部分。不适用的可选章节应删除而不是写 N/A。PRD 立即保存到 docs/agentic-engineering/prd/<session>/<subject>.md，状态为 draft；<session> 为当前日期 YYYY-MM-DD，<subject> 为简洁的 kebab-case，重名时追加 -2、-3 等，并将 frontmatter 的 subject 设为同一 slug。写入失败时报告并停止。随后报告保存路径与简短摘要，请用户验证文档；按请求修改并再次询问，直到用户批准；批准后将状态设为 validated 并进入阶段三。
阶段三：设计 只询问设计层面的问题——契约、数据形态、错误处理、验证策略，不重复已验证 PRD 已回答的内容，提问风格与阶段一一致。基于 assets/design.md 起草设计文档，将 prd 字段指向已验证 PRD 路径，并在“目标与 PRD 参考”和“验证与测试”中映射其 FR-/NFR-/AC-* 编号。在“备选方案”中记录被否决的方案及理由。不适用的可选章节删除而非写 N/A。设计文档立即保存到 docs/agentic-engineering/specs/<session>/<subject>.md，状态为 draft，复用 PRD 的 <session> 和 <subject> 以便两份产物按名称配对，重名与写入失败规则同阶段二。报告保存路径与简短摘要，请用户验证；修改并再次询问直到批准；批准后将状态设为 validated，并报告设计文档路径作为规划阶段的输入。
适用场景与限制 适用于需要在编码前澄清新功能、功能变更或缺陷报告，并希望产出结构化、可追溯的 PRD 与设计文档的开发场景，尤其适合需求模糊或范围偏大的提示。限制包括：不生成实施计划；不擅自提交代码；不处理 .gitignore；全新项目缺少仓库证据时需明确说明；项目过大时须先拆分子项目，不能一次性产出单一 PRD。