| 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 进入计划编写阶段。"
在用户明确批准前,不进入下一阶段。
不做的事
- 不写实现代码
- 不启动可视化伴侣或浏览器服务
- 不做技术选型(那是计划阶段的事)
- 不在一次回复中问多个问题