brainstorming

> 借鉴来源：Superpowers (obra/superpowers) 的 brainstorming skill

>

> 在动手写代码之前，先通过追问把需求搞清楚，展示设计方案给用户确认，再动手。

>

> 核心理念：写代码前不问清楚 = 返工成本 10x。

触发条件

满足以下任一场景时自动激活，无需用户调用：

• 用户要求创建一个新的功能/模块/项目
• 用户描述了一个需求，但没有明确的范围边界
• 用户说"帮我做个 XXX"（模糊请求）
• 用户要求实现某个功能，但没有说明输入/输出/边界条件

不适用于：纯搜索、纯阅读、简单确认、快速修复已知 bug。

工作流程

Step 1：追问澄清（不跳步）

遇到模糊需求，按以下清单追问：

[需求澄清]
1. 用户故事：谁在什么场景下需要这个功能？
2. 输入：数据从哪来？格式是什么？
3. 输出：期望的结果是什么？格式是什么？
4. 边界：什么情况算成功？什么情况算失败？
5. 优先级：这个功能的核心价值是什么？MVP 是什么？
6. 约束：有没有技术限制？性能要求？兼容性要求？

规则：

• 一次问 2-3 个最重要的问题，不要一次问完（减少用户认知负担）
• 用户回答后继续追问，直到需求明确
• 如果用户拒绝回答，告诉用户这会影响实现质量，让他决定是否继续

Step 2：产出设计文档（分块展示）

需求明确后，产出设计文档，但不要一次性全部展示，分块展示：

## 设计草案 v0.1

### 模块结构
[文字描述]

### 风险点
[列出 1-2 个最需要用户确认的点]

---
请确认以上方向是否正确，我会继续细化。

原则：每次展示用户能在 30 秒内读完的分量。

Step 3：用户确认 → 产出实施计划

用户确认设计后，产出实施计划：

## 实施计划（简化版）

| 阶段 | 任务 | 验收标准 |
|------|------|---------|
| Phase 1 | [任务描述] | [标准] |
| Phase 2 | [任务描述] | [标准] |

每个 Phase 完成后再进入下一个。

Step 4：TDD 循环（用户说"go"之后）

进入此步之前，必须先通过 grill-me 确认。

• 每个任务：先写失败测试 → 再实现 → 再验证
• 每完成一个任务，主动报告进度
• 遇到阻塞，立刻报告，不要等
• 完成后 → 调用 skill-compounding 检查是否值得沉淀

关键原则

下一跳（Skill 链式调用）

brainstorming 是入口技能，完成后按以下路径自动调用：

brainstorming → grill-me → [implementation]
              ↘ agent-teams（需要多角度审查时）
              ↘ conductor（大型项目/多阶段任务）

下一跳触发条件：

• 设计确认后 → 自动调用 grill-me 做实施前最后确认
• 需要多角色并行审查 → 调用 agent-teams
• 项目规模大/多阶段 → 调用 conductor 接管后续流程
• 解决方案有复用价值 → 调用 skill-compounding

与其他 Skill 的配合

• skill-compounding：如果这个需求的解决方案值得复用，在完成后提取为 Skill
• refactoring：如果发现现有代码结构不合理，先讨论再改
• test-specialist：测试用例设计有疑问时调用

触发命令

自动触发，不需要用户手动调用。当检测到模糊需求时主动激活。