用途
Brainstorming 旨在通过自然的协作式对话，帮助把想法转化为完整成型的设计与规格说明，作用于编码之前的阶段。当请求涉及新功能、行为变更、架构等内容时可以使用。
主要能力与流程
理解想法
- 首先查看当前项目状态（文件、文档、最近的提交）。
- 一次只问一个问题，逐步打磨想法。
- 尽可能优先使用多选题，开放式问题也可以。
- 每条消息只提一个问题；如果某个话题需要更多探索，就把它拆成多个问题。
- 聚焦于理解：目的、约束、成功标准。
探索方案
- 提出 2-3 种不同的方案，并说明各自的取舍。
- 以对话方式呈现选项，附上推荐意见与理由。
- 先给出推荐的选项，再解释原因。
呈现设计
- 当你认为自己已经理解要构建的内容后，呈现设计。
- 将其拆分为每段 200-300 字的若干段落。
- 每一段之后询问目前看起来是否正确。
- 覆盖：架构、组件、数据流、错误处理、测试。
- 如果有地方讲不通，要准备好回头澄清。
使用方式
在编码之前，通过对话逐步澄清需求；提出 2-3 种方案并推荐；分段呈现设计并逐段验证；最后把得到验证的设计写入文档。
设计之后
- 将验证过的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md。
- 如果可用，使用 writing-clearly-and-concisely 技能。
关键原则
- 一次只问一个问题——不要用多个问题淹没对方。
- 优先多选题——在可能时比开放式问题更容易回答。
- 严格遵循 YAGNI——从所有设计中移除不必要的功能。
- 探索替代方案——在定稿前始终提出 2-3 种方案。
- 增量验证——分段呈现设计，并逐段验证。
- 保持灵活——当某处讲不通时，回头澄清。
适用场景
适用于新功能、行为变更、架构等需求，在开始编码之前使用。
限制
资料未提供关于收费、价格、平台支持范围、具体效果的明确说明。