brainstorming

# 头脑风暴：将想法转化为设计 通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。 首先了解当前项目的上下文，然后逐一提问来完善想法。一旦你理解了要构建的内容，就展示设计方案并获得用户批准。 <HARD-GATE> 在你展示设计方案并获得用户批准之前，不要调用任何实现��能、编写任何代码、搭建任何项目或采取任何实现行动。这适用于所有项目，无论看起来多简单。 </HARD-GATE> ## 反模式："这个太简单了，不需要设计" 每个项目都要经过这个流程。一个待办事项列表、一个单函数工具、一个配置变更——全都需要。"简单"的项目恰恰是未经检验的假设造成最多浪费的地方。设计可以很简短（对于真正简单的项目几句话就够了），但你必须展示出来并获得批准。 ## 检查清单 你必须为以下每个条目创建任务，并按顺序完成： 1. **探索项目上下文** — 检查文件、文档、最近的 commit 2. **提供视觉伴侣**（如果主题涉及视觉问题）— 这是一条独立的消息，不要与澄清问题合并。参见下方的"视觉伴侣"部分。 3. **提出澄清问题** — 每次一个，了解目的/约束/成功标准 4. **提出 2-3 种方案** — 附带权衡分析和你的推荐 5. **展示设计** — 按复杂度分节展示，每节展示后获得用户批准 6. **编写设计文档** — 保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并 commit 7. **规格自检** — 快速内联检查占位符、矛盾、模糊性、范围（详见下方） 8. **用户审查书面规格** — 在继续之前请用户审查规格文件 9. **过渡到实现** — 调用 writing-plans 技能创建实现计划 ## 流程图 ```dot digraph brainstorming { "探索项目上下文" [shape=box]; "有视觉相关问题?" [shape=diamond]; "提供视觉伴侣\n（独立消息，不含其他内容）" [shape=box]; "提出澄清问题" [shape=box]; "提出 2-3 种方案" [shape=box]; "分节展示设计" [shape=box]; "用户批准设计?" [shape=diamond]; "编写设计文档" [shape=box]; "规格自检\n（内联修复）" [shape=box]; "用户审查规格?" [shape=diamond]; "调用 writing-plans 技能" [shape=doublecircle]; "探索项目上下文" -> "有视觉相关问题?"; "有视觉相关问题?" -> "提供视觉伴侣\n（独立消息，不含其他内容）" [label="是"]; "有视觉相关问题?" -> "提出澄清问题" [label="否"]; "提供视觉伴侣\n（独立消息，不含其他内容）" -> "提出澄清问题"; "提出澄清问题" -> "提出 2-3 种方案"; "提出 2-3 种方案" -> "分节展示设计"; "分节展示设计" -> "用户批准设计?"; "用户批准设计?" -> "分节展示设计" [label="否，修改"]; "用户批准设计?" -> "编写设计文档" [label="是"]; "编写设计文档"...