// 结构化脑暴——发散探索 + 收敛评估。当想法模糊、面临开放性问题或需要方案对比，或提到"脑暴""想法""方案对比""怎么办"
恢复保存的工作上下文。当新 session 需要继续之前的工作，或提到"恢复""restore""继续上次"
保存工作上下文。当需要保存当前工作状态供后续 session 恢复，或提到"保存""save""checkpoint""挂起"
架构决策记录（ADR）。当面临技术选型、架构决策、方案取舍需要记录，或提到"ADR""决策记录""为什么这样做"
发布或导出检查 → Go/No-Go → 归档。当审查通过后需要上线或交付最终产物，或提到"发布""上线""ship""Go/No-Go"
合并 PR → 等待 CI → 验证生产。当 PR 已创建需要合并到主分支并验证部署，或提到"合并""merge""PR""land"
发布后健康监控。当代码已部署需要持续验证生产健康，或提到"金丝雀""canary""监控""健康检查"
| name | define-cognitive-brainstorm |
| description | 结构化脑暴——发散探索 + 收敛评估。当想法模糊、面临开放性问题或需要方案对比，或提到"脑暴""想法""方案对比""怎么办" |
| argument-hint | [模糊想法或开放性问题] |
| agents | ["brainstorm-tech-scout","brainstorm-design-scout","brainstorm-business-scout","brainstorm-content-scout","brainstorm-data-scout","brainstorm-security-scout","brainstorm-outlier-scout"] |
docs/features/YYYYMMDD-<name>/00-brainstorm.md + 用户批准的方向define-workflow-spec（需求已清晰）或 define-workflow-refine（仍需收敛）docs/features/YYYYMMDD-<name>/00-brainstorm.md → 下游 define-workflow-refine 或 define-workflow-spec脑暴的价值 = 收敛时的明确性 - 发散时的混乱度。
发散是过程，收敛是目的。
"不做清单"可能是最有价值的部分——集中就是放弃好想法。
/brainstorm 使用按需选座的多席位并行脑暴模式。
Phase 1: 当前 agent 直接执行上下文探索。
Phase 2: 根据 --profile 或 --seats 选择 scout 组合，读取 commands/brainstorm-menu.json 后使用 Agent 工具并行启动。/brainstorm 是 Markdown 阶段协议，不是 shell CLI；参数由 current agent 解释。
参数与配置规则：
--list-profiles：只列出 commands/brainstorm-menu.json 中 profiles / seats，不启动 scout--profile <name>：使用 task_profiles.<name>.seats--seats a,b,c：短名规范化为 brainstorm-<name>-scoutdefault_seatsbrainstorm-outlier-scout 默认自动加入；只有用户明确写 --no-outlier 才排除commands/brainstorm-menu.json 缺失或无法解析时 STOP，改用本技能内联 profile 列表，并在输出中标记 fallback可用 Scout：
agents/brainstorm-tech-scout.md — 技术可行性、架构方案、实现路径agents/brainstorm-design-scout.md — 用户体验、交互路径、情感连接agents/brainstorm-business-scout.md — 产品价值、市场定位、商业模式agents/brainstorm-content-scout.md — 叙事结构、受众共鸣、表达方式agents/brainstorm-data-scout.md — 数据建模、存储策略、查询优化agents/brainstorm-security-scout.md — 威胁模型、防护策略、合规要求agents/brainstorm-outlier-scout.md — 边缘视角、激进想法、反向思考（默认参与，用户可显式 --no-outlier 排除）预设配置（Profile）：
general: tech + design + business + outlier（默认）tech_architecture: tech + data + security + outlierproduct_strategy: business + design + content + outliercontent_marketing: content + design + business + outlierapi_design: tech + data + security + outliersecurity_review: security + tech + data + outlieruser_experience: design + content + business + outlierdata_strategy: data + tech + security + outlier每个 scout 独立执行，互不干扰，使用各自的专业框架发散。宿主不支持 subagent 时，由 current agent 按 seat 串行模拟并明确标记 fallback；不得假装已经并行。
Phase 3: 当前 agent 作为 facilitator，执行交叉 fertilization 和辩论：
Phase 4: 当前 agent 收敛整合，输出最终推荐。
在深入之前：
读取 commands/brainstorm-menu.json 后，使用 Agent 工具并行启动已选 scout，每个从不同角度发散：
Scout 框架分配：
| Scout | 核心框架 | 产出 |
|---|---|---|
| brainstorm-tech-scout | First Principles / Constraints / Pre-mortem / Time-travel | 技术提案、架构方案、实现路径、创新机会 |
| brainstorm-design-scout | HMW / Crazy 8 / Role-play / Anti-pattern | 设计提案、用户旅程、交互模式、情感设计 |
| brainstorm-business-scout | JTBD / Blue Ocean / Business Model Canvas / Pre-mortem | 商业提案、价值主张、市场定位、增长路径 |
| brainstorm-outlier-scout | Inversion / 10x Thinking / Constraints → Freedom / 挑战所有假设 | 激进提案、反向思考、黑天鹅事件、跨界借鉴 |
并行执行要点：
outlier-scout 默认参与并必须提出至少 1 个"看起来很荒谬"的想法；用户显式 --no-outlier 时必须记录排除理由Cross-Pollination（交叉授粉）：
Debate（辩论）：
outlier-scout 的任务是挑战所有共识Synthesis（综合）：
每个方案 vs. 评估标准:
├── 技术可行性: 现有架构能支持吗？
├── 实现成本: 几天？几周？几个月？
├── 用户体验: 用户真的会喜欢吗？还是只是在纸上看起来好？
├── 维护负担: 未来改动的容易度？
├── 风险: 什么可能出错？
└── 增长潜力: 这个方案可扩展吗？
收敛三步:
输出 2-3 个对比方案，不是 10+。
每个方案输出：
方案 <名称>
├── 核心思想 (1 句)
├── 具体做法 (3-5 步)
├── 优点
├── 缺点
├── 风险 + 缓解
└── 或不推荐 + 理由
必须给出并说明理由。 脑暴不是"列出所有选项让你选"。是"我最推荐 X，因为 Y。备选 Z，如果 X 的 C 风险太高"。
每个方案前面列出假设。隐藏假设是最常见的规划杀手。
别做 yes-man。如果方案有明确问题——说出来，量化影响。诚实 > 奉承。
"不做清单"和"做清单"一样重要。5 个方案中放弃 3 个 = 集中力量。
模板起点：templates/feature/00-brainstorm.md
# 设计: [主题]
## 背景
[为什么现在做、什么约束、谁需要这个]
## 假设
[列出要验证的关键假设]
## 决策标准
- 必须满足:
- 优先优化:
- 可以牺牲:
- 明确不能:
## 关键假设验证
| 假设 | 风险 | 验证方式 | 通过标准 |
|------|------|----------|----------|
| <假设> | 高/中/低 | <如何验证> | <什么结果算通过> |
## 方案
### 方案 A: [名称]
- 做法:
- 优点:
- 缺点:
- 风险:
- 推荐: [是/否] 因为...
### 方案 B: [名称]
...
## 推荐
**选择方案 X** 因为: [理由]
备选方案 Y 如果: [什么条件下备选变成首选]
## 不做
- [放弃的方向 + 原因]
- [放弃的方向 + 原因]
## 开放问题
[需要用户输入才能继续的]
## 下一阶段交接
- 推荐进入: `/refine` / `define-workflow-spec`
- 已锁定决策:
- 下游必须继续验证:
- 不允许下游重新打开:
| 说辞 | 现实 | 后果 |
|---|---|---|
| "方案很明显不需要脑暴" | 多花 10 分钟列出"不做清单"和隐藏假设的价值远超跳过。 | 跳过脑暴直接实现，3 天后发现方向错误，返工成本 > 脑暴 10 分钟的 50-100x。 |
| "这个太简单不需要设计" | "这是一行代码"是真的不需要设计。"这是一个按钮"需要执行位置、状态、label、a11y。 | 简单假设导致遗漏边界情况，上线后以 bug 形式爆发。 |
| "列出所有选项给你选" | 这就是放弃判断。你是技术伙伴——给出和理由。 | 10 个选项无推荐 = 用户无法决策，讨论停滞，浪费所有参与者时间。 |
| "方案 X 完美" | 没有完美方案。每个方案都有缺点——不说缺点 = 没想透。 | 隐藏的缺点在实现阶段暴露，返工时才发现根因在方案选择，修复成本 10x。 |
| 失败场景 | 处理方式 |
|---|---|
| 发散后方案数 > 5 | 先收缩再推荐。合并相似方案，删除明显弱于其他方案的选项。输出 2-3 个。 |
| 收敛后"不做清单"为空 | 强制要求列出至少 2 个放弃的方向 + 原因。不做清单和做清单一样重要。 |
| 用户约束被方案忽视 | 标记为 Blocking，回到 Phase 1 重新理解约束。 |
| 所有方案风险都很高 | 诚实告知 human partner，推荐"不做"或"先降低风险再决策"。不推荐高风险方案。 |
| 无法给出明确推荐 | 列出推荐的阻塞问题，请 human partner 决策。不能以"都行"结束脑暴。 |
# 设计: 用户通知系统
## 假设
- 用户日活 > 10k，通知量级需要考虑
- 已有 WebSocket 基础设施
## 方案
### 方案 A: 实时推送（推荐）
- 做法: WebSocket + 消息队列 + 前端 toast
- 优点: 即时性强，用户体验好
- 缺点: 连接管理复杂，服务器成本高
- 风险: WebSocket 断连时需 fallback → 缓解: 30s 轮询兜底
### 方案 B: 轮询 + 缓存
- 做法: 前端每 30s 请求未读计数 API
- 优点: 实现简单，服务器成本低
- 缺点: 延迟 30s，高并发时 API 压力大
- 风险: 用户错过时效性通知
## 推荐: 方案 A — 即时性对通知系统是核心价值
备选 B: 如果 WebSocket 基础设施不成熟
## 不做
- 邮件通知（当前阶段 scope 外）
- SMS 通知（成本过高，ROI 不匹配）
# 设计: 用户通知系统
## 方案
方案 A: WebSocket
方案 B: 长轮询
方案 C: SSE
方案 D: 邮件
方案 E: 推送通知
方案 F: 短轮询
（没有假设、没有评估标准、没有推荐、不做清单为空）
-> 问题: 方案 > 5 个，发散未收敛（红旗 #1）
-> 问题: 没有假设就开始设计方案（红旗 #2）
-> 问题: 不做清单为空 = 没做取舍（红旗 #5）
-> 问题: 没有推荐 = 放弃判断（红旗 #6，常见说辞"列出所有选项给你选"）