# Brainstorm

> AI-DDD 协作思考引擎，通过结构化头脑风暴澄清问题空间、分解需求、讨论技术方案。 支持 problem/requirements/technical 三种模式，生成决策记录供后续 Spec 引用。 使用场景："头脑风暴"、"讨论一下"、"brainstorm"、"需求不清楚"、"技术方案讨论"、 "问题分析"、"需要澄清需求"

- Skill: `10cg/brainstorm` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds@latest add 10cg/brainstorm`
- Raw SKILL.md: https://api.skillmd.com/api/skills/10cg/brainstorm/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: 10cg (https://skillmd.com/u/10cg)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/10cg/brainstorm

---


# 头脑风暴引擎 (Brainstorm v2.0)

> **版本**: 2.0.0 | **角色**: AI-DDD 协作思考的核心载体
> **更新**: 重构为简洁对话式设计，参考 Superpowers 最佳实践

---

## 快速开始

### 使用场景

- 需求还不清晰，需要多轮讨论澄清
- 需要在多个方案之间做选择
- 需要探索问题的本质而非急于实现

### 不使用场景

- 需求明确，直接进入实现 → 使用 `phase-b-developer`
- 简单 bug 修复 → 使用 `quick-fix`

---

## 核心原则

| 原则 | 说明 |
|------|------|
| **一次只问一个问题** | 每次只问一个问题，不要一次问多个 |
| **优先多选题** | 多选题比开放式问题更容易回答 |
| **探索替代方案** | 总是提出 2-3 个方案及权衡 |
| **分段验证** | 设计分 200-300 词展示，每段验证 |
| **灵活回退** | 随时可以回退澄清 |

---

## 执行流程

### 阶段 1: 理解想法 (Understanding)

```yaml
步骤:
  1. 检查项目状态:
     - 读取文件、文档、最近提交

  2. 一次问一个问题:
     - 优先使用多选题
     - 开放式问题也可接受
     - 每条消息只问一个问题

  3. 了解重点:
     - 目的 (Purpose)
     - 约束 (Constraints)
     - 成功标准 (Success Criteria)

示例对话:
  AI: 这个功能的主要目的是什么？
      a) 提高用户参与度
      b) 减少操作步骤
      c) 其他 (请说明)

  用户: b

  AI: 想要减少哪些操作的具体步骤？
```

### 阶段 2: 探索方案 (Exploring)

```yaml
步骤:
  1. 提出 2-3 个方案:
     - 每个方案的描述
     - 优缺点对比
     - 约束匹配度

  2. 对话式展示:
     - 说明推荐选项
     - 解释推荐理由

  3. 等待用户选择或反馈

示例对话:
  AI: 我考虑了三种方案：

      方案 A: 简化流程
      优点: 快速实现，用户学习成本低
      缺点: 功能受限

      方案 B: 智能默认值
      优点: 平衡功能和复杂度
      缺点: 需要数据积累

      方案 C: 渐进式引导
      优点: 灵活性高
      缺点: 实现复杂

      我推荐方案 B，因为...
```

### 阶段 3: 展示设计 (Presenting)

```yaml
步骤:
  1. 确认理解后开始展示设计

  2. 分段展示 (每段 200-300 词):
     - 架构概述
     - 核心组件
     - 数据流
     - 错误处理
     - 测试策略

  3. 每段后验证:
     - "这样对吗？"
     - "需要调整吗？"
     - 等待反馈再继续

  4. 随时准备回退澄清

示例对话:
  AI: [展示架构概述 200-300 词]

      这样的架构安排看起来对吗？

  用户: 某个组件不清楚

  AI: [回退澄清该组件]
```

### 阶段 3 完成后: post_brainstorm 审计检查点

```yaml
触发条件: audit.enabled == true AND audit.checkpoints.post_brainstorm != "off"

执行:
  调用 audit-engine:
    checkpoint: "post_brainstorm"
    mode: 来自 config (audit.mode) 或 adaptive
    context: 本次头脑风暴生成的决策记录文件路径  # 如 .aria/brainstorm-{id}.md 或 docs/decisions/DEC-*.md

  if verdict == FAIL:
    → 阻塞输出文件写入，呈现审计报告，等待用户决策
  else (PASS / PASS_WITH_WARNINGS):
    → 继续写入输出文件
```

> **context 类型契约 (#17 Drift Guard)**: post_brainstorm audit 的 `context` 必须传**决策记录文件路径** (非 Forgejo issue URL) — audit-engine Step 0 anchor 提取器据此识别"已确认决策"段 → `in_scope`、"DEFERRED" 条目 → `out_of_scope_hints`、核心议题 → `primary_goal` (与 audit-engine SKILL.md Step 0 post_brainstorm 调用契约对齐); context 为 issue URL 时降级 issue_title anchor。

---

## 不可协商规则

```yaml
对话控制:
  - 每次只能问 1 个问题
  - 必须等待用户回答再继续
  - 禁止一次性生成所有 User Stories
  - 禁止跳过验证步骤

设计验证:
  - 设计必须分段展示 (200-300 词/段)
  - 每段后必须询问反馈
  - 用户不满意必须调整或回退

输出控制:
  - 理解阶段不输出任何文件
  - 设计阶段分段输出并验证
  - 最终确认后才写入文件
```

---

## 输出规范

### Requirements 模式输出

```yaml
主要输出:
  - docs/decisions/requirements-{id}.md

可选输出:
  - docs/requirements/user-stories/US-*.md (逐个确认后创建)

User Story 模板:
  ## US-{序号}: {标题}
  > **优先级**: P{0-3} | **状态**: Ready

  **描述**: 作为 {角色}，我想要 {功能}，以便 {价值}

  **验收标准**:
  - [ ] {标准1}
  - [ ] {标准2}
```

### Decision 模板

```markdown
# 决策: DEC-{YYYYMMDD}-{序号} - {标题}

> **日期**: {date} | **模式**: {mode}

## 背景
{背景描述}

## 约束条件
| 类型 | 约束 | 影响 |
|------|------|------|

## 考虑的方案
| 方案 | 描述 | 评分 | 状态 |
|------|------|------|------|

## 最终选择
**方案**: {selected}

## 理由
1. {理由1}
2. {理由2}

## 风险与缓解
| 风险 | 缓解措施 |
|------|----------|
```

---

## 模式说明

### problem 模式
- 触发: 用户输入模糊，新功能想法
- 目标: 澄清问题本质
- 输出: problem-definition.md

### requirements 模式
- 触发: PRD 创建，功能分解
- 目标: 分解为 User Stories
- 输出: requirements-{id}.md + user-stories/

### technical 模式
- 触发: OpenSpec 创建前，架构选型
- 目标: 技术方案设计
- 输出: technical-{id}.md + proposal.md 草案

---

## 错误处理

| 错误 | 处理 |
|------|------|
| 无法收敛 | 展示状态，提供强制选择/放宽约束 |
| 用户中断 | 保存草稿，提供恢复方式 |
| 需求冲突 | 识别冲突，建议放宽约束 |

---

## 相关文档

详细参考文档见 **[`references/`](./references/)** 目录:

- [`principles.md`](./references/principles.md) - 核心原则详解
- [`question-patterns.md`](./references/question-patterns.md) - 提问模式库
- [`decision-workflow.md`](./references/decision-workflow.md) - 决策记录流程

---

## 集成

### state-scanner 集成
```yaml
触发: 检测到模糊需求，复杂度 >= Level 2
推荐: "发现新功能想法，建议先进行头脑风暴"
```

### spec-drafter 集成
```yaml
输入: 决策记录 + 约束条件 + 方案选择
行为: 自动填充 proposal.md，引用决策 ID
```

---

**最后更新**: 2026-06-11 (#17 audit-drift-guard — Drift Guard 原始目的锚定)
**Skill版本**: 2.0.0 (基于 Superpowers 最佳实践重构)