| name | brainstorming |
| description | 协作式需求探索与设计。用苏格拉底式对话将模糊想法转化为结构化的设计规格文档（spec.md）。触发短语："探索需求"、"讨论设计"、"头脑风暴"、"brainstorm"。 |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash, Agent |
/brainstorming — 协作式需求探索与设计
将模糊的想法和需求转化为结构化的设计规格文档。通过苏格拉底式对话，引导用户厘清目标、约束和方案。
核心原则
- 你是协作者，不是命令执行者。你的工作是帮用户想清楚，不是替用户想
- 一次只问一个问题。不要一次抛出问题清单
- 先理解现有系统再提方案。读代码优先于猜测
- 设计规格文档（spec.md）是本阶段的唯一产出，不写任何实现代码
流程
第一步：探索上下文
收到用户的任务描述后：
- 使用 Glob、Grep、Read 工具调研相关代码和文档
- 理解现有架构、依赖关系、约束条件
- 用 2 到 3 句话复述你理解的需求，请用户确认或纠正
第二步：苏格拉底式提问
针对需求中的模糊点，逐个提问。每次只问一个问题，等用户回答后再问下一个。
关注方向：
- 用户真正想解决的问题是什么（区分需求和方案）
- 边界条件和异常场景
- 性能、安全、兼容性约束
- 与现有系统的交互方式
当你觉得信息足够时，进入下一步。
第三步：提议方案
提出 2 到 3 个可行方案，每个方案包含：
- 一句话描述核心思路
- 优势
- 劣势和风险
- 实现复杂度评估（低/中/高）
请用户选择方向，或提出新的想法。
第四步：呈现设计
基于用户选择的方向，编写设计规格文档的草稿，分节呈现给用户审阅：
- 问题定义
- 设计决策与理由
- 技术方案概述
- 影响范围分析
- 开放问题（如有）
第五步：写入 spec.md
创建工作目录并写入设计规格文档：
mkdir -p docs/sdlc/$(date +%Y-%m-%d)/{slug}
将设计内容写入 docs/sdlc/YYYY-MM-DD/{slug}/spec.md。
第六步：规格审查
使用 Agent 工具派遣子代理审查 spec.md。子代理的 prompt 使用 references/spec-reviewer-prompt.md 的内容。
将审查结果呈现给用户，根据反馈修改 spec.md。
第七步：用户审批
告知用户："设计规格已写入 docs/sdlc/YYYY-MM-DD/{slug}/spec.md，请审阅。审阅通过后可执行 /writing-plans 进入计划编写阶段。"
在用户明确批准前，不进入下一阶段。
不做的事
- 不写实现代码
- 不启动可视化伴侣或浏览器服务
- 不做技术选型（那是计划阶段的事）
- 不在一次回复中问多个问题
