| name | brainstorm |
| description | AI-DDD 协作思考引擎，通过结构化头脑风暴澄清问题空间、分解需求、讨论技术方案。
支持 problem/requirements/technical 三种模式，生成决策记录供后续 Spec 引用。
使用场景："头脑风暴"、"讨论一下"、"brainstorm"、"需求不清楚"、"技术方案讨论"、
"问题分析"、"需要澄清需求"
|
头脑风暴引擎 (Brainstorm v2.0)
版本: 2.0.0 | 角色: AI-DDD 协作思考的核心载体
更新: 重构为简洁对话式设计，参考 Superpowers 最佳实践
快速开始
使用场景
- 需求还不清晰，需要多轮讨论澄清
- 需要在多个方案之间做选择
- 需要探索问题的本质而非急于实现
不使用场景
- 需求明确，直接进入实现 → 使用
phase-b-developer
- 简单 bug 修复 → 使用
quick-fix
核心原则
| 原则 | 说明 |
|---|
| 一次只问一个问题 | 每次只问一个问题，不要一次问多个 |
| 优先多选题 | 多选题比开放式问题更容易回答 |
| 探索替代方案 | 总是提出 2-3 个方案及权衡 |
| 分段验证 | 设计分 200-300 词展示，每段验证 |
| 灵活回退 | 随时可以回退澄清 |
执行流程
阶段 1: 理解想法 (Understanding)
步骤:
1. 检查项目状态:
- 读取文件、文档、最近提交
2. 一次问一个问题:
- 优先使用多选题
- 开放式问题也可接受
- 每条消息只问一个问题
3. 了解重点:
- 目的 (Purpose)
- 约束 (Constraints)
- 成功标准 (Success Criteria)
示例对话:
AI: 这个功能的主要目的是什么？
a) 提高用户参与度
b) 减少操作步骤
c) 其他 (请说明)
用户: b
AI: 想要减少哪些操作的具体步骤？
阶段 2: 探索方案 (Exploring)
步骤:
1. 提出 2-3 个方案:
- 每个方案的描述
- 优缺点对比
- 约束匹配度
2. 对话式展示:
- 说明推荐选项
- 解释推荐理由
3. 等待用户选择或反馈
示例对话:
AI: 我考虑了三种方案：
方案 A: 简化流程
优点: 快速实现，用户学习成本低
缺点: 功能受限
方案 B: 智能默认值
优点: 平衡功能和复杂度
缺点: 需要数据积累
方案 C: 渐进式引导
优点: 灵活性高
缺点: 实现复杂
我推荐方案 B，因为...
阶段 3: 展示设计 (Presenting)
步骤:
1. 确认理解后开始展示设计
2. 分段展示 (每段 200-300 词):
- 架构概述
- 核心组件
- 数据流
- 错误处理
- 测试策略
3. 每段后验证:
- "这样对吗？"
- "需要调整吗？"
- 等待反馈再继续
4. 随时准备回退澄清
示例对话:
AI: [展示架构概述 200-300 词]
这样的架构安排看起来对吗？
用户: 某个组件不清楚
AI: [回退澄清该组件]
阶段 3 完成后: post_brainstorm 审计检查点
触发条件: audit.enabled == true AND audit.checkpoints.post_brainstorm != "off"
执行:
调用 audit-engine:
checkpoint: "post_brainstorm"
mode: 来自 config (audit.mode) 或 adaptive
context: 本次头脑风暴生成的决策记录文件路径
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。
不可协商规则
对话控制:
- 每次只能问 1 个问题
- 必须等待用户回答再继续
- 禁止一次性生成所有 User Stories
- 禁止跳过验证步骤
设计验证:
- 设计必须分段展示 (200-300 词/段)
- 每段后必须询问反馈
- 用户不满意必须调整或回退
输出控制:
- 理解阶段不输出任何文件
- 设计阶段分段输出并验证
- 最终确认后才写入文件
输出规范
Requirements 模式输出
主要输出:
- docs/decisions/requirements-{id}.md
可选输出:
- docs/requirements/user-stories/US-*.md (逐个确认后创建)
User Story 模板:
> **优先级**: P{0-3} | **状态**: Ready
**描述**: 作为 {角色}，我想要 {功能}，以便 {价值}
**验收标准**:
- [ ] {标准1}
- [ ] {标准2}
Decision 模板
# 决策: 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/ 目录:
集成
state-scanner 集成
触发: 检测到模糊需求，复杂度 >= Level 2
推荐: "发现新功能想法，建议先进行头脑风暴"
spec-drafter 集成
输入: 决策记录 + 约束条件 + 方案选择
行为: 自动填充 proposal.md，引用决策 ID
最后更新: 2026-06-11 (#17 audit-drift-guard — Drift Guard 原始目的锚定)
Skill版本: 2.0.0 (基于 Superpowers 最佳实践重构)
