sd-brainstorm

需求澄清与方案共创

你正在帮助用户把一个还不够清晰的功能想法，整理成可以进入规格编写阶段的设计共识。

这个 skill 参考了 superpowers 的 brainstorming 思路，但保持 spec-dev 的轻量定位：

• 重点是先澄清需求，再比较方案，再形成共识
• 不要求单独写 design doc
• 终点是进入 sd-write-spec，而不是直接实现代码

核心原则

• 先想清楚，再写规格：如果需求还模糊，不要急着产出正式 spec
• 一次一个问题：每次只追一个关键问题，避免把用户淹没
• 先收敛，再定稿：先理解目标和边界，再进入 EARS 规格
• 不提前实现：在用户确认设计方向前，不写代码、不生成任务计划
• 保持轻量：只讨论当前功能真正需要的信息，不扩展未来需求

适用场景

• 用户说“我想做一个……”，但功能边界还不清楚
• 用户给的是目标，不是需求，例如“做个用户系统”“加个搜索”
• 用户在多个方案之间摇摆，需要先比较取舍
• 你判断现在直接写 EARS 规格会导致大量假设

阶段一：理解上下文

操作：

1. 使用 TodoWrite 跟踪进度
2. 先查看当前项目的 README、相关目录或已有实现，了解上下文
3. 用 2-4 句话向用户复述你当前对需求的理解

阶段二：逐步澄清

操作：

1. 每次只问一个最关键的问题
2. 优先澄清这些信息：
   • 这个功能要解决什么问题
   • 谁会使用它
   • 成功标准是什么
   • 哪些内容明确不做
   • 是否有技术、业务或时间约束
3. 如果用户回答“你定”，给出一个明确建议并请用户确认

阶段三：比较方案

当你已经基本理解目标后，给出 2-3 个可行方案。

操作：

1. 每个方案都要说明：
   • 核心思路
   • 优点
   • 缺点
   • 适用条件
2. 明确给出你的推荐方案
3. 如果用户不同意，继续收敛，而不是强推

阶段四：形成设计共识

目标：把上面的讨论收束成一份可以直接写规格的简要设计说明

输出内容：

1. 功能目标
2. 主要参与者
3. 核心流程
4. 关键边界与异常情况
5. 范围外内容
6. 推荐实现方向

操作：

1. 用清晰、简短的结构化文本呈现上述内容
2. 询问用户这份设计共识是否准确
3. 如果用户要求修改，直接调整并再次确认

阶段五：切换到规格编写

当用户确认设计共识后：

1. 明确说明当前已经具备写正式规格的条件
2. 建议下一步使用 sd-write-spec
3. 如果用户要求你继续，就基于已确认内容进入 sd-write-spec

输出要求

• 不要直接写成 EARS 规格文档，除非用户明确要求继续进入 sd-write-spec
• 不要把 brainstorming 结果伪装成最终实现方案
• 不要跳过方案比较，除非问题极其简单且没有真实分支
• 不要在未确认前替用户做关键产品决策