---
name: brainstorming
description: >
  苏格拉底式创意探索技能，融合 gstack 的 brainstorm 和 superpowers 的 aside 模式。
  在不同方案之间做发散-收敛循环，用分块展示降低认知负荷，帮助团队找到最佳路线。
---

# Brainstorming

## 用途

- 把"直接跳到实现方案"改成"先发散探索、再收敛锁定"。
- 适合技术选型、架构方向、产品策略、用户体验方案等需要创造性思考的场景。
- 避免团队因锚定效应只看到第一个想到的方案。

## 默认做法

### 1. 框定问题

- 用一句话描述要解决的核心问题。
- 明确约束条件（时间、技术栈、团队能力、合规要求）。
- 明确成功标准：什么样的方案是"好方案"。

### 2. 发散阶段

- 产出至少 3 个差异化方案，每个方案包含：
  - **一句话概述**：方案的核心思路
  - **关键假设**：该方案依赖哪些前提
  - **优势**：这个方案比其他方案好在哪
  - **风险**：可能出什么问题
  - **成本估算**：时间/人力/基础设施的粗略评估

- **强制对比维度**（来自 gstack multi-perspective 方法论）：
  - 用户视角：哪个方案用户体验最好？
  - 工程视角：哪个方案最容易维护和扩展？
  - 商业视角：哪个方案 ROI 最高？
  - 风险视角：哪个方案最不容易出问题？

### 3. 分块展示（来自 gstack chunked design）

- 复杂方案不要一口气全部展示，而是分层递进：
  - **第一块**：核心架构和关键决策（最高层）
  - **第二块**：模块拆分和接口设计（结构层）
  - **第三块**：技术细节和实现路径（执行层）
  - 每块展示后暂停，等用户确认方向再展开下一层
  - 用户可以在任意一层要求调整或切换方案

### 4. 收敛阶段

- 基于讨论结论，形成推荐方案的结构化输出：
  - 推荐方案及原因
  - 被排除的方案及排除原因
  - 关键假设和待验证项
  - 下一步行动建议

### 5. 产出

- 若用于 `/team-plan` 前置：产出写入 `docs/artifacts/{slug}/brainstorm.md`
- 若用于独立探索：产出写入对话上下文，由用户决定是否持久化
- 若产出涉及架构级决策：建议同步写入 ADR

## 触发信号

- 用户说"我们讨论一下方案"、"有哪些选择"、"brainstorm"、"头脑风暴"。
- `/team-intake` 或 `discuss-phase` 识别出存在多条可行技术路线。
- `architect` 在方案设计阶段需要对比多个选项。
- 技术选型、框架选择、产品策略等需要创造性探索的场景。

## 配套约束

1. **不替代正式决策**：brainstorming 产出是输入，最终决策由 `tech-lead` 或 `architect` 在 `/team-plan` 或 ADR 中锁定。
2. **时间控制**：单次 brainstorming 控制在 3-5 个方案以内，避免无限发散。
3. **独立性**：brainstorming 可以独立调用，不依赖 `/team-*` 链路。
4. **对话友好**：分块展示模式应在每块结束后给用户反馈点，不要一次性输出整个方案。