用途
brainstorming 用于把模糊的想法转化为成型的设计与规格，适用于设计复杂多步骤功能、构建新组件，或规划需要先做设计探索的重要行为变更。它通过自然的协作对话完成这一过程。
技能开始时会声明："I'm using the brainstorming skill to explore this design."
核心立场
技能明确反对"这个太简单，不需要设计"的思维定式。任何项目——待办清单、单函数工具、配置改动——都要走这个流程。越是"简单"的项目，未经审视的假设越容易造成最大浪费。设计可以很短（真正简单的项目几句话即可），但必须呈现并获得批准。
主要能力与流程
1. 探索项目上下文（迭代检索）
不是只扫一遍文件，而是用结构化循环逐步发现相关内容：
- 第 1 轮——广泛扫描：用 Glob 扫描项目结构与关键文件模式，用 Grep 搜索与用户请求相关的关键词，阅读项目文档、README、CLAUDE.md 和近期提交，检查 .planning/archive/*.md 中的历史归档（若找到，阅读相关归档并把关键决策与经验教训记入 ## Historical Context 小节），初始发现保存到 .planning/findings.md。
- 评估与识别缺口：对发现的文件/组件打分——High（直接实现目标功能）、Medium（含相关模式或类型）、Low（仅间接相关，排除后续探索）；识别缺失上下文；记录代码库实际使用的术语（可能与用户措辞不同）。
- 第 2-3 轮——定向细化（仅在仍有缺口时）：使用前几轮发现的代码库原生术语搜索，沿导入、类型定义和调用链追踪高相关文件，完整阅读最相关文件的实现而非只看 grep 片段，每轮后用"2-Action Rule"更新 findings.md。停止条件：识别出 3 个以上高相关文件且无关键上下文缺口，或完成 3 轮。避免过度探索——深入理解 3 个文件胜过粗略浏览 10 个。
2. 范围检查
在细化细节前，先判断请求是否实际描述多个独立子系统。若是，先提议拆分，只对第一个子项目走完整流程。
3. 澄清问题
通过 AskUserQuestion 一次只问一个问题，理解目的、约束、成功标准，并把关键用户回答与决策记录到 .planning/findings.md。
4. 提出方案
提出 2-3 种带权衡的方案，并给出推荐，通过 AskUserQuestion 让用户选择。
5. 呈现设计
按复杂度分段呈现设计，每段后用 AskUserQuestion 获取批准。覆盖架构、组件、数据流、错误处理、测试。设计应边界清晰、职责隔离，偏好小而专注的文件而非大而全的文件。
技能采用"证据优先"原则：每个设计决策（架构选择、性能假设、复杂度权衡、接口契约）都应由证据支撑——基准测试、数据、参考实现或推理分析。暂无证据时，用 [NEEDS-EVIDENCE] 行内标注后继续，不阻塞设计进度，也不静默假设。
6. 设计之后
- 文档化：将验证过的设计写入 .planning/design.md；初始化 .planning/ 目录（运行 ${CLAUDE_PLUGIN_ROOT}/scripts/init-planning-dir.sh 创建目录及规范模板）；用设计派生的任务填充 progress.md 中的 Task Status Dashboard；把设计探索发现（被否决的方案、发现的约束、有用参考）移入 .planning/findings.md。
- 规格自审：以全新视角检查占位符（TBD、TODO、不完整章节、模糊需求）、内部一致性、范围是否适合单个实施计划、是否存在可作两种解释的歧义。发现问题直接行内修复。
- 规格访谈：询问"Do you want to run a spec interview to refine details in the design?"（默认 yes）。若选 yes，以设计文档为目标调用 superpower-planning:spec-interview；若跳过则继续。
- 用户评审闸门：明确要求用户在规划前审阅写好的规格。
- 询问 worktree：用 AskUserQuestion 询问是否为实现创建隔离的 git worktree（是则调用 superpower-planning:git-worktrees，否则跳过）。
- 转入实施：调用 writing-plans 技能创建实施计划。
流程终点
终止状态是调用 writing-plans。writing-plans 之前允许的中间技能只有 spec-interview（细化设计）和 git-worktrees（隔离工作）。技能明确禁止调用任何实现类技能。
关键原则
- 所有面向用户的问题必须使用 AskUserQuestion
- 每次调用只问一个问题，不让人不堪重负
- 尽可能优先多选题
- 无情执行 YAGNI，从所有设计中移除不必要的功能
- 证据优先：每个设计决策都需要证据，暂无则标 [NEEDS-EVIDENCE] 继续
- 迭代检索：从宽到窄，用代码库原生术语细化搜索（最多 3 轮），"够好即停"，重深度而非广度
- 始终提出 2-3 种备选方案再定稿
- 增量验证：呈现设计并获批准后再继续
- 保持灵活：当某事说不通时回头澄清
- 大型系统必须拆分，不让单个规格蔓延到多个独立子系统
- 小而专注的文件，规划前明确文件边界与职责
适用场景
设计复杂多步骤功能、构建新组件、规划重要行为变更等需要设计探索的任务。
限制
技能本身不进入实现环节，最终只到 writing-plans 生成实施计划。安装方式、收费、价格等信息资料中暂未提供。