name: brainstorming description: 在编写代码或实施计划之前创建或开发任何东西时使用 - 通过结构化苏格拉底式提问、替代方案探索和增量验证，将粗糙想法精炼成完整的设计

将头脑风暴想法转化为设计

概述

通过结构化提问和替代方案探索，将粗糙想法转化为完整设计。

核心原则： 提问以理解，探索替代方案，分步呈现设计以进行验证。

开始时宣布： “我正在使用头脑风暴技能来将您的想法精炼成设计。”

快速参考

阶段	关键活动	工具使用	输出
1. 理解	提问（一次一个）	使用AskUserQuestion进行选择	目的、约束、标准
2. 探索	提出2-3种方法	使用AskUserQuestion进行方法选择	带权衡的架构选项
3. 设计呈现	以200-300字的部分呈现	开放式问题	带有验证的完整设计
4. 设计文档	编写设计文档	writing-clearly-and-concisely技能	设计文档在docs/plans/中
5. 工作树设置	设置隔离工作空间	using-git-worktrees技能	准备开发环境
6. 规划交接	创建实施计划	writing-plans技能	详细任务分解

过程

复制此检查清单以跟踪进度：

头脑风暴进度：
- [ ] 阶段1：理解（目的、约束、标准收集）
- [ ] 阶段2：探索（提出并评估2-3种方法）
- [ ] 阶段3：设计呈现（分步验证设计）
- [ ] 阶段4：设计文档（将设计写入docs/plans/）
- [ ] 阶段5：工作树设置（如果要实施）
- [ ] 阶段6：规划交接（如果要实施）

阶段1：理解

检查工作目录中的当前项目状态
一次问一个问题来精炼想法
使用AskUserQuestion工具当您有多个选择选项时
收集：目的、约束、成功标准

使用AskUserQuestion的示例：

问题：“认证数据应该存储在哪里？”
选项：
  - “会话存储”（标签关闭时清除，更安全）
  - “本地存储”（跨会话持久化，更方便）
  - “Cookies”（适用于SSR，与旧方法兼容）

阶段2：探索

提出2-3种不同的方法
对于每种：核心架构、权衡、复杂性评估
使用AskUserQuestion工具将方法呈现为结构化选择
询问您的伙伴哪种方法更合适

使用AskUserQuestion的示例：

问题：“我们应该使用哪种架构方法？”
选项：
  - “带消息队列的事件驱动”（可扩展，设置复杂，最终一致性）
  - “带重试逻辑的直接API调用”（简单，同步，更容易调试）
  - “带后台作业的混合”（平衡，中等复杂性，两者兼得）

阶段3：设计呈现

以200-300字的部分呈现
覆盖：架构、组件、数据流、错误处理、测试
在每个部分后问：“到目前为止看起来对吗？”（开放式）
在这里使用开放式问题以允许自由反馈

阶段4：设计文档

设计验证后，将其写入永久文档：

文件位置： docs/plans/YYYY-MM-DD-<主题>-设计.md（使用实际日期和描述性主题）
推荐子技能： 使用elements-of-style:writing-clearly-and-concisely（如果可用）以提高文档质量
内容： 捕获讨论和验证的设计，组织成对话中出现的部分
在继续之前将设计文档提交到git

阶段5：工作树设置（用于实施）

当设计批准并即将实施时：

宣布：“我正在使用using-git-worktrees技能来设置隔离工作空间。”
必需子技能： 使用superpowers:using-git-worktrees
遵循该技能的目录选择、安全验证和设置过程
当工作树准备好时返回这里

阶段6：规划交接

问：“准备好创建实施计划了吗？”

当您的伙伴确认时（任何肯定响应）：

宣布：“我正在使用writing-plans技能来创建实施计划。”
必需子技能： 使用superpowers:writing-plans
在工作树中创建详细计划

问题模式

何时使用AskUserQuestion工具

使用AskUserQuestion用于：

阶段1：澄清问题，带有2-4个清晰选项
阶段2：架构方法选择（2-3种替代方案）
任何具有不同、互斥选择项的决策
当选项有清晰的权衡需要解释时

好处：

带有描述的结构化选项呈现
伙伴的清晰权衡可见性
强制明确选择（防止模糊的“可能两者”响应）

何时使用开放式问题

使用开放式问题用于：

阶段3：设计验证（“到目前为止看起来对吗？”）
当您需要详细反馈或解释时
当伙伴应该描述自己的需求时
当结构化选项会限制创意输入时

示例决策流程：

“使用什么认证方法？” → 使用AskUserQuestion（2-4个选项）
“这个设计是否处理您的用例？” → 开放式（验证）

何时重新访问早期阶段

digraph revisit_phases {
    rankdir=LR;
    "新约束揭示？" [shape=diamond];
    "伙伴质疑方法？" [shape=diamond];
    "需求不清晰？" [shape=diamond];
    "返回阶段1" [shape=box, style=filled, fillcolor="#ffcccc"];
    "返回阶段2" [shape=box, style=filled, fillcolor="#ffffcc"];
    "继续前进" [shape=box, style=filled, fillcolor="#ccffcc"];

    "新约束揭示？" -> "返回阶段1" [label="是"];
    "新约束揭示？" -> "伙伴质疑方法？" [label="否"];
    "伙伴质疑方法？" -> "返回阶段2" [label="是"];
    "伙伴质疑方法？" -> "需求不清晰？" [label="否"];
    "需求不清晰？" -> "返回阶段1" [label="是"];
    "需求不清晰？" -> "继续前进" [label="否"];
}

您可以并且应该后退当：

伙伴在阶段2或3揭示新约束 → 返回阶段1
验证显示需求中的根本差距 → 返回阶段1
伙伴在阶段3质疑方法 → 返回阶段2
某些内容不合理 → 返回并澄清

当后退会给出更好结果时，不要强制线性前进。

关键原则

原则	应用
一次一个问题	阶段1：每条消息单个问题，使用AskUserQuestion进行选择
结构化选择	使用AskUserQuestion工具进行2-4个带权衡的选项
YAGNI无情	从所有设计中移除不必要的功能
探索替代方案	在确定前总是提出2-3种方法
增量验证	分步呈现设计，验证每个部分
灵活进展	需要时后退 - 灵活性 > 刚性
宣布使用	在会话开始时声明技能使用