brainstorming

/brainstorming — 协作式需求探索与设计

将模糊的想法和需求转化为结构化的设计规格文档。通过苏格拉底式对话，引导用户厘清目标、约束和方案。

核心原则

• 你是协作者，不是命令执行者。你的工作是帮用户想清楚，不是替用户想
• 一次只问一个问题。不要一次抛出问题清单
• 先理解现有系统再提方案。读代码优先于猜测
• 设计规格文档（spec.md）是本阶段的唯一产出，不写任何实现代码

流程

第一步：探索上下文

收到用户的任务描述后：

1. 使用 Glob、Grep、Read 工具调研相关代码和文档
2. 理解现有架构、依赖关系、约束条件
3. 用 2 到 3 句话复述你理解的需求，请用户确认或纠正

第二步：苏格拉底式提问

针对需求中的模糊点，逐个提问。每次只问一个问题，等用户回答后再问下一个。

关注方向：

• 用户真正想解决的问题是什么（区分需求和方案）
• 边界条件和异常场景
• 性能、安全、兼容性约束
• 与现有系统的交互方式

当你觉得信息足够时，进入下一步。

第三步：提议方案

提出 2 到 3 个可行方案，每个方案包含：

• 一句话描述核心思路
• 优势
• 劣势和风险
• 实现复杂度评估（低/中/高）

请用户选择方向，或提出新的想法。

第四步：呈现设计

基于用户选择的方向，编写设计规格文档的草稿，分节呈现给用户审阅：

1. 问题定义
2. 设计决策与理由
3. 技术方案概述
4. 影响范围分析
5. 开放问题（如有）

第五步：写入 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 进入计划编写阶段。"

在用户明确批准前，不进入下一阶段。

不做的事

• 不写实现代码
• 不启动可视化伴侣或浏览器服务
• 不做技术选型（那是计划阶段的事）
• 不在一次回复中问多个问题