一、定位与作用
brainstorming 是 Superpowers 技能系统中的设计探索技能，专门负责将模糊的想法转化为清晰的设计方案。它的核心定位是：
"帮助通过自然的协作对话，将想法转化为完整的设计和规范文档"
一句话总结：先想清楚，再动手做
二、核心铁律（HARD-GATE）
Markdown
<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
</HARD-GATE>
核心含义：
-
在呈现设计方案并获得用户批准之前，绝对不能：
- 调用任何实现技能
- 写任何代码
- 搭建任何项目结构
- 采取任何实现行动
这条规则没有例外，无论项目看起来多么简单。
三、反模式：常见误区
Markdown
## Anti-Pattern: "This Is Too Simple To Need A Design"
误区想法："这个太简单了，不需要设计"
反驳理由：
- 每个项目都要经过这个流程
- 待办清单、单函数工具、配置变更——都需要
- "简单"项目恰恰是最容易因为未经审视的假设而浪费工作的地方
- 设计可以很短（真正简单的项目几句话就行），但必须呈现并获得批准
四、检查清单（9个步骤）
brainstorming 技能要求按顺序完成以下任务：
| 步骤 | 任务 | 关键要点 |
|---|---|---|
| 1️⃣ | 探索项目上下文 | 检查文件、文档、最近提交 |
| 2️⃣ | 提供视觉伴侣（如需要） | 独立消息，不与其他内容混合 |
| 3️⃣ | 提出澄清问题 | 一次一个，理解目的/约束/成功标准 |
| 4️⃣ | 提出 2-3 个方案 | 包含权衡分析和推荐建议 |
| 5️⃣ | 呈现设计方案 | 按复杂度分节，每节后获取批准 |
| 6️⃣ | 编写设计文档 | 保存到指定路径并提交 git |
| 7️⃣ | 规范自检 | 快速检查占位符、矛盾、歧义、范围 |
| 8️⃣ | 用户审查规范 | 让用户审查文件后再继续 |
| 9️⃣ | 过渡到实现 | 调用 writing-plans 技能 |
五、流程图详解
Plain Text
┌─────────────────────────┐
│ Explore project context │
│ (探索项目上下文) │
└──────────┬──────────────┘
│
▼
┌────────────────────┐
│ Visual questions │
│ ahead? │
│ (有视觉问题吗？) │
└─────┬─────────┬─────┘
│ │
是│ 否│
▼ ▼
┌─────────────────┐ ┌──────────────────────┐
│ Offer Visual │ │ Ask clarifying │
│ Companion │ │ questions │
│ (独立消息) │ │ (澄清问题) │
└────────┬────────┘ └──────────┬───────────┘
│ │
└──────────────────────┘
│
▼
┌─────────────────────┐
│ Propose 2-3 │
│ approaches │
│ (提出 2-3 个方案) │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Present design │
│ sections │
│ (呈现设计方案) │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ User approves │
│ design? │
└──────┬─────────┬─────┘
│ │
是 │ 否│
▼ ▼
┌──────────────┐ (回到上一节重新呈现)
│ Write design │
│ doc │
│ (编写设计文档)│
└──────┬───────┘
│
▼
┌──────────────┐
│ Spec │
│ self-review │
│ (规范自检) │
└──────┬───────┘
│
▼
┌──────────────┐
│ User reviews │
│ spec? │
└──────┬───────┘
│
┌─────┴─────┐
│ │
是│ 否│
│ │
▼ ▼
┌────────────────┐ (修改文档，重新审查)
│ Invoke │
│ writing-plans │
│ skill │
│ (调用写计划技能)│
└────────────────┘
六、每一步骤详细说明
步骤 1️⃣：探索项目上下文
任务：了解当前项目状态
具体操作：
- 检查项目文件结构
- 查看相关文档
- 查看最近的 git 提交记录
- 理解项目的现有架构
为什么重要：
- 避免重复造轮子
- 遵循现有模式
- 发现可能影响工作的现有问题
步骤 2️⃣：提供视觉伴侣（如需要）
条件：如果即将讨论的内容涉及视觉问题
触发时机：
- 需要展示原型
- 需要展示布局图
- 需要展示架构图
- 需要视觉对比
关键规则：
- 这个提议必须是独立的消息
- 不能与其他内容（澄清问题、上下文摘要等）混合
- 等待用户响应后再继续
- 如果用户拒绝，用纯文本继续头脑风暴
示例提议：
"我们正在讨论的部分，如果能在网络浏览器中展示，可能更容易解释。我可以整理原型、图表、对比和其他视觉内容。这个功能还很新，可能比较消耗资源。想试试吗？（需要打开本地 URL）"
步骤 3️⃣：提出澄清问题
核心原则：一次只问一个问题
问题类型：
- 多选题（优先使用）：更容易回答
- 开放式问题：也可以使用
聚焦内容：
- 目的（Purpose） ：为什么要做这个？
- 约束（Constraints） ：有什么限制？
- 成功标准（Success Criteria） ：怎么才算成功？
重要提醒：
- 如果一个主题需要更多探索，把它分解成多个问题
- 不要一次问多个问题，让用户逐一回答
步骤 4️⃣：提出 2-3 个方案
要求：提供 2-3 个不同的方案
每个方案需要包含：
- 方案描述
- 优点
- 缺点
- 权衡分析
呈现方式：
- 对话式呈现
- 明确推荐方案并解释原因
- 先呈现推荐方案
步骤 5️⃣：呈现设计方案
原则：按复杂度调整篇幅
- 简单的部分：几句话
- 复杂的部分：200-300 字
需要覆盖的内容：
- 架构：整体结构
- 组件：各个部分
- 数据流：数据如何流动
- 错误处理：如何处理错误
- 测试：如何测试
迭代审批：
- 每呈现一节后，询问用户是否正确
- 准备好在用户有疑问时返回澄清
步骤 6️⃣：编写设计文档
保存位置：
Plain Text
docs/superpowers/specs/YYYY-MM-DD--design.md
例外：如果用户在 CLAUDE.md 中有偏好设置，按用户的设置来
提交要求：
- 提交设计文档到 git
步骤 7️⃣：规范自检
检查清单：
| 检查项 | 问题 | 行动 |
|---|---|---|
| 占位符扫描 | 有"TBD"、"TODO"、不完整部分或模糊需求吗？ | 修复它们 |
| 内部一致性 | 各部分之间有矛盾吗？架构和功能描述匹配吗？ | 修复矛盾 |
| 范围检查 | 这个范围是否足够单一实现计划，还是需要分解？ | 必要时分解 |
| 歧义检查 | 任何需求能被两种不同方式理解吗？ | 选一个并明确 |
行动：发现问题就立即修复，不需要重新审查
步骤 8️⃣：用户审查规范
标准询问：
"规范已编写并提交到
<path>。请审查一下，如果在开始编写实现计划之前有任何想修改的地方，告诉我。"
等待用户响应：
- 如果用户要求修改 → 修改后重新审查
- 只有用户批准后才能继续
步骤 9️⃣：过渡到实现
唯一选择：调用 writing-plans 技能
重要提醒：
- 不要调用 frontend-design、mcp-builder 或任何其他实现技能
- brainstorming 之后唯一的下一步是 writing-plans
七、关键设计原则
| 原则 | 说明 | 为什么重要 |
|---|---|---|
| 一次一个问题 | 不要用多个问题淹没用户 | 确保理解和专注 |
| 多选题优先 | 比开放式问题更容易回答 | 提高效率，减少歧义 |
| YAGNI 原则 | 从所有设计中删除不必要的功能 | 保持简洁，专注核心 |
| 探索替代方案 | 在确定之前总是提出 2-3 个方案 | 确保选择最佳方案 |
| 增量验证 | 呈现设计，获得批准后再继续 | 避免返工 |
| 保持灵活 | 当有问题时返回澄清 | 确保真正理解 |
八、设计隔离与清晰原则
brainstorming 技能强调设计要模块化：
设计原则：
- 将系统分解为更小的单元
- 每个单元有单一、明确的目的
- 通过明确定义的接口通信
- 可以独立理解和测试
每个单元需要能回答：
- 它做什么？
- 你如何使用它？
- 它依赖什么？
模块化检查：
- 别人能否不阅读内部实现就理解它的功能？
- 你能否在不破坏依赖者的情况下修改内部实现？
- 如果不能，边界需要调整。
为什么重要：
- 更小的、有边界的单元更容易处理
- 你能更好地理解可以一次性掌握上下文范围的代码
- 当文件变大时，往往是它做得太多的信号
九、与现有代码库协作
探索当前结构：
- 在提出更改之前，先探索当前结构
- 遵循现有模式
处理现有代码问题：
- 如果现有代码有问题影响工作，将其作为设计的一部分
- 就像一个好的开发者在工作时改进代码一样
- 提出有针对性的改进
不要做的事情：
- 不要提出无关的重构
- 保持专注于当前目标
十、Visual Companion 视觉伴侣
什么是视觉伴侣：
- 基于浏览器的原型展示工具
- 可用于展示mockup、图表和视觉选项
- 是一个工具，不是模式
使用决策：
- 每个问题独立决定是否使用浏览器
- 测试：用户通过看比读更能理解吗？
适合视觉化：
- mockup、原型
- 布局对比
- 架构图
- 并排视觉设计
适合文本：
- 需求问题
- 概念选择
- 权衡列表
- A/B/C/D 文本选项
- 范围决策
示例判断：
- "在这个语境中，'个性'意味着什么？" → 概念问题 → 用终端
- "哪个向导布局更好？" → 视觉问题 → 用浏览器
十一、工作流程总结
Plain Text
想法输入
↓
探索项目上下文
↓
(可能有)视觉伴侣提议
↓
澄清问题（一次一个）
↓
提出 2-3 个方案 + 推荐
↓
用户批准设计方案
↓
编写设计文档
↓
规范自检（修复问题）
↓
用户审查并批准
↓
调用 writing-plans 技能 ← 终止状态
十二、与其他技能的关系
| 关系 | 说明 |
|---|---|
| 前置于 | writing-plans（唯一下一步） |
| 需要 | 项目上下文探索能力 |
| 为 | 后续实现提供清晰的设计基础 |
| 不使用 | 任何实现技能（frontend-design、mcp-builder 等） |
十三、核心价值总结
brainstorming 技能的核心价值在于：
- 防止返工：通过提前设计，避免实现后发现方向错误
- 确保理解：通过提问确保真正理解需求
- 探索最佳方案：通过多方案比较，选择最优解
- 保持简洁：通过 YAGNI 原则，专注于核心功能
- 用户参与：通过审批流程，确保用户满意
- 文档化：留下可追溯的设计文档
