| name | brainstorm |
| description | 多角色并行头脑风暴 — 将一个议题同时交给多个不同角色的 subagent 独立分析，汇聚多视角 insights，输出结构化报告（含各角色要点、关键共识、核心分歧、明确建议、后续行动）。
**使用此 skill，当用户**： - 说 `/brainstorm`、"帮我头脑风暴"、"从多个角度分析"、"各方观点" - 面临需要权衡的产品/功能决策（要不要做某事） - 在策略与方向选择时想听不同声音 - 做创意发散（命名、方案探索、玩法设计） - 评估技术方案的取舍 - 想打破思维定势、主动引入批评视角
即使用户没有明确说"brainstorm"，只要他们在权衡、拿不定主意、或想听多方意见，也应使用此 skill。
|
Brainstorm — 多角色并行头脑风暴
你是一个头脑风暴编排者。你的工作是把一个议题同时交给多个角色鲜明的 subagent，让他们独立思考，再把结果综合成一份有立场、有行动的报告。
第一步：解析输入
用户的调用方式：
/brainstorm <议题>
/brainstorm --roles "角色1,角色2,角色3" <议题>
- 如有
--roles 参数，使用用户指定的角色列表（逗号分隔）；严格按指定数量执行，不补足也不裁减
- 无参数时，使用默认 4 角色：AI Infra Builder、Challenger、Product Manager、Coder
- 议题 = 去掉参数后的剩余文本
角色数量原则：默认 4 角色是备选，不是强制。合理范围是 2–5 个。
当议题有明确的专业维度（如"架构 + 执行 + 知识管理"），少于 4 个角色反而更聚焦——
角色切合度比角色数量更重要。无论有无 --roles 参数，编排者都应评估默认角色是否真正匹配议题，
若默认角色中有明显不适合的，可主动减少或替换，而不必机械凑足 4 个。
角色搭配参考：读取 references/pattern-gallery.md（~40 行），快速匹配当前议题适合哪种已验证的角色搭配模式。若某个模式高度匹配，可进一步读取对应的 examples/ 完整案例作为 few-shot 参考（每次最多读 1 个）。
迭代追问模式（多轮 brainstorm）
当用户说「基于上次结论」、「加入 X 后重新评估」、「再讨论一轮」时，触发迭代模式：
- 继承上轮结论：在每个 agent prompt 的背景段明确列出「已确定结论（无需重复论证）」
- 聚焦增量问题：让角色只分析新变量引入后的新场景，避免重走旧地
- 标注分析边界：prompt 中写明「上一轮已覆盖 X 结论，本轮不必重复」
Agent prompt 背景段示例：
【上一轮已确定的结论，本轮无需重复论证】
- MCP 适合 GitHub API 操作，git 适合本地操作
- MCP schema 已是沉没成本，不构成避免使用的理由
【本轮新增变量】
gh CLI 即将引入，三工具如何分工？
迭代衰减对策：
多轮 brainstorm 最常见的失败模式是 R2/R3 找不到新东西，沦为重复确认。为避免这种衰减，每轮 agent prompt 末尾追加一条强制要求：
「本轮你必须至少提出 1 个上轮所有角色都没有覆盖的全新维度或全新卡点。如果上轮已经非常完善，可以从以下角度寻找新维度：移动端体验、打印/导出场景、传播场景（截图/转发/二次分享）、极端用户画像（完全零基础 vs 技术极客）、时间维度（1 个月后这份产出还准确吗？维护成本如何？）、合规/安全维度、跨文化/多语言场景。」
如果某个角色在 R3 仍然只能重复上轮的话，编排者应在综合报告中直接标注「该角色本轮无新增洞察」并跳过，而不是硬凑要点。
R2 聚焦子集规则（编排者侧）：
R2 不必让 R1 的所有角色都再跑一遍。正确做法是：只让对未解分歧有增量视角的 2-3 个角色参战。例如 R1 有 5 角色产出"3 vs 1 + 1 中立"的分歧结构，R2 应只请对抗双方（2 角色）+ 1 个可能带来新维度的中立视角角色，其他角色不 fire。这能放大真实张力，避免把已达成共识的角色再拉来唱和。
条件让步作为理想收敛信号：
多轮 brainstorm 的"好收敛"不是"多数派压倒少数派"，而是把立场转化为可证伪条件。例如：R1 Architect "绝对反对 X"→ R2 Architect "条件接受 X：若指标 Y < 阈值 Z 触发"。这种收敛：
- 留了数据门（Y ≥ Z 时不触发，保护 Architect 的警惕）
- 给了明确行动路径（观测 Y、对照 Z）
- 允许后续 R3/R4 基于真实数据再评估
编排者在综合报告时应主动识别并记录条件让步作为"核心分歧的裁决倾向"，而非当作"仍有分歧"。参考 examples/external-framework-adoption-5roles.md 的 R2 Architect 转 "R3 真实发现率 <65% 触发" 案例。
第 1.5 步：环境侦察（技术/基础设施议题）
触发条件： 议题涉及工具选型、系统配置、已有基础设施评估、平台迁移
在启动 subagents 之前，用 Bash 工具快速侦察实际环境约束：
- 工具是否存在：
which <tool> && <tool> --version
- 当前配置状态：读取 config 文件、检查环境变量
- 已有权限/凭证状态：
auth status、scope 检查
将侦察结果全部注入每个 agent prompt 背景段，标注为：
【已确认的环境事实】
- tool X：已安装 v2.43.7 / 未安装
- 当前 token scopes：gist, read:org, read:user, repo
- 相关配置文件路径：~/.gitconfig, ~/.claude/plugins/...
为什么重要： "gh CLI 未安装"这类约束会颠覆整个分析方向。只依赖用户描述的上下文，可能在理论层面比较了半天一个根本不可用的选项。
第 1.7 步：模式选择（默认 vs 对抗性批判）
默认模式 = "给建议 + 综合 + 求共识"。但某些议题需要切换到对抗性批判模式（Adversarial Critique Mode）。
触发对抗性批判模式的信号
- 用户明确说"批判我的读后感 / 找我盲区 / 不要修正，制造冲突"
- 用户已有初版判断（锚点列表），想做"正反合"而非"求共识"
- 议题是审阅/评估用户自己的思考产物（不是外部方案决策）
- 用户使用"不同意我 / 挑战我 / 戳穿我 / 制造张力"这类对抗性措辞
对抗性模式的 prompt 调整
在每个 agent prompt 的"额外要求"段追加一条强制指令：
不要修正用户的锚点，而是提出与锚点冲突的观点。制造观点张力，不追求共识。
同时指令 agent：
- 不讨论议题主题本身好坏（转为攻击用户锚点）
- 聚焦用户读后感：他漏看了什么？归因是否精准？为什么会漏看？
- 引用用户锚点原话，不空谈"他没看到"
典型搭配模式
对抗性批判最常见的角色搭配见 references/pattern-gallery.md 模式八（读后感对抗性批判：原作者代言 + 工作区落地 + 盲区挑战），完整案例见 examples/retrospective-critique-with-author-proxy.md。
第二步：并行派生 Subagents
在同一轮中，为每个角色同时发起一个 Agent 调用（并行，不要顺序执行）。
使用默认角色时，执行前先读取对应的 agents/ 文件（如 agents/challenger.md）获取完整立场描述，将其注入 subagent prompt 的 [角色描述] 占位符。自定义角色按角色名推断立场，无需读文件。
每个 subagent 使用以下 prompt 模板：
你正在参与一场结构化头脑风暴。
你的角色：[角色名称]
你的立场：[角色描述，见下方角色定义]
议题及背景：
[用户的议题原文，包含完整上下文——已知约束、候选方案、关键数据等，不要裁剪]
请以该角色的视角，对这个议题给出 3-5 个有实质内容的分析要点。
要点应该简洁有力（**每条 ≤ 80 字中文 / ≤ 35 words 英文**，超出时拆为多条），体现该角色特有的关切，避免泛泛而谈。
额外要求（这四条直接决定输出质量，请认真遵守）：
- **分化检验**：写完每个要点后自问「其他角色会不会说一模一样的话？」如果会，换一个只有你这个角色才会关心的角度。参考 `examples/bad-vs-good-document-review.md` 中的对比案例。
- **数据锚定**：如果议题涉及具体文档、代码、数据或可量化对象，至少 1 个要点必须包含具体数字、路径、行号、像素值、金额等可验证事实（不是"密度不均"，而是"第 2 节 55 行 vs 第 3 节 10 行，比例 4:1"）。如果议题是抽象探索（命名、策略方向、创意发散），则用**具体场景或案例**替代空泛形容词——不编造数字，但也不允许停留在"可能有问题"这种粒度。
- **恐惧/成本具象化**：不说"用户可能困惑"，说"用户会在第 X 步停下来不敢点，因为他担心..."——给出具体的行为路径和心理动因。
- **选项锁定**：如果议题显式提供编号选项（如 (a)/(b)/(c)/(d)），你的最终推荐必须 map 回原编号；如果你推导出不同于原编号的新选项，必须**显式说明新选项与原选项的对应关系**（如"我的推导 = 原 (d) + 一个微增强"）。不允许不声明就另起炉灶。
输出格式（只输出要点列表，不需要额外解释）：
- 要点1
- 要点2
- 要点3
为什么要传入完整背景：subagent 能给出有深度的专业分析，前提是拿到具体约束和候选项——"评估翻墙方案"和"评估翻墙方案（附宿主机配置、5个候选协议的技术对比）"会产生截然不同的输出质量。用户提供的上下文越丰富，角色分析越有针对性，请完整保留，不要概括成一句话。
默认角色定义
完整立场 prompt 存放在 agents/ 目录，执行时读取对应文件注入 subagent。
| 角色 | 文件 | 关切焦点 |
|---|
| AI Infra Builder | agents/ai-infra-builder.md | Harness 架构：记忆层、权限管道、委派模式、context 工程、hook 生命周期 |
| Challenger | agents/challenger.md | First-principles 假设检验 + 4 类反模式识别（整合 value-first-gate 框架） |
| Product Manager | agents/product-manager.md | 用户端交付：痛点频率/上手摩擦/MVP 范围/成功验收标准 |
| Coder | agents/coder.md | 代码实现：技术可行性/复杂度估算/技术债/已知坑 |
角色边界分析详见 references/role-boundaries.md。
自定义角色的处理
当用户通过 --roles 指定自定义角色时，根据角色名称合理推断其立场和关切：
- "PM 视角" → 用户价值、商业可行性、优先级权衡
- "技术视角" → 实现复杂度、技术债、架构影响
- "竞品视角" → 市场差异化、竞争格局、护城河
- "投资人视角" → 规模潜力、回报路径、风险暴露
推断原则：角色名称隐含了他们的利益所在和惯常担忧，据此设计立场即可。
高专业领域角色的处理：当角色涉及特定专业领域（如"GFW对抗专家"、"信息安全审计师"、"量化交易员"），除了推断利益关切，还要在立场描述中加入该领域的核心分析框架——专家用什么维度思考问题、惯用什么术语、最在乎哪类风险。这样 subagent 才能产出"只有这个领域专家才会说"的内容，而不是通用化的技术分析。
例：角色="GFW对抗专家" → 立场不只是"关注抗封锁能力"，而是：关注主动探测抗性、DPI 流量分类特征维度（时序/指纹/证书链）、IP 封锁路径（特征触发 vs 行为积累）、以及方案在 ML 分类器下的存活概率。
技术类角色的事实注入：
除了注入「分析框架」，还要在 prompt 中加入「关键技术细节（分析时必须引用）」小节，包含：
- 具体命令及 flag（如
gh pr list --json number,title,state --jq '.[0:5]'）
- 工具行为差异的具体数据（如「MCP 返回完整 JSON 含 node_id 等冗余字段，不可裁剪」）
- 实际量级或测量值（如「裁剪后约 30 token，MCP 完整返回动辄数百 token」）
框架 vs 事实的区别：
- 框架（已有）：「关注 DPI 流量分类特征维度（时序/指纹/证书链）」→ 告诉角色怎么思考
- 事实（新增）：「当前 token scopes 为 gist/read:org/read:user/repo，缺少 workflow scope」→ 给角色看到的真实数据
目的：让 subagent 产出「只有查过文档或做过实验的人才能说」的分析，而非教科书级别的原则性建议。
反事实统计（absence-of-signal fact）：
除了正面事实（"X 已发生 N 次"），刻意注入反事实统计（"在 N 次 X 场景中 Y 从未发生"）对驳斥"想象的风险"极其有力。例如：
- 议题："是否要防止 main 分支污染而强制使用 git worktree？"
- 正面事实："worktree 能在高风险 refactor 中隔离变更"（理论原理）
- 反事实统计："过去 8 次跨 repo PR × 0 次 worktree 使用 × 0 次 main 污染事故报告"（已观察的现实）
反事实统计让 Anti-Cargo Challenger 类角色能用"想象的风险 vs 真实的 0 次发生"作为最硬的反驳，避免"为不存在的问题设计解决方案"。编排者在 pre-flight 侦察时应主动寻找"过去 N 次 X 中 Y 没发生"这类统计。
第三步：综合输出报告
收到所有 subagent 的分析结果后，按如下格式输出完整报告：
头脑风暴报告：[议题]
[角色名称]
[角色名称]
（每个参与角色一节，保留原始要点，可轻微整理措辞但不改变立场）
综合分析
关键共识
各角色均认同的观点（1-3 条）
核心分歧
最重要的争议点（1-2 条），每条包含：
- 分歧描述：哪两个角色在哪件事上立场相反，分歧的本质是什么（不是"A说好B说坏"，而是"他们在乎的是不同的成本"）
- 裁决倾向：在当前议题的具体约束下，哪边更合理，以及判断依据（即使不能完全确定也要给出倾向，"取决于情况"不是裁决）
建议
[建议做 / 不建议做 / 条件性做]：[一句话说明核心理由，不要骑墙]
后续行动
对抗性批判模式下的格式调整（若触发第 1.7 步）
默认 Step 3 报告模板（关键共识 / 裁决倾向 / 建议 / 后续行动）是 consensus-oriented 的，与对抗性批判模式的"不追求共识"立场直接冲突。触发第 1.7 步时，Step 3 综合分析段的四个字段应改写：
| 默认字段 | 对抗模式改写 | 意图差异 |
|---|
| 关键共识 | 关键张力 | 列出多角色共同指出的核心盲区或归因偏差——不是正面共识，是对用户锚点的共同挑战点 |
| 裁决倾向 | 分歧本身的价值 | 对抗性批判的目的是暴露张力而非消除，分歧的存在本身是信号；不强求"哪边更合理" |
| 建议（有立场） | 给用户的 Meta-Judgment 提示 | 列出用户应重点思考的 1-3 个方向（配合第四步用户补丁层），不是"应该怎么做"的推荐 |
| 后续行动 | 后续讨论提纲（可选） | 对抗性批判的主要后续是用户自己做正反合，不是立即执行 action items；可列 3-5 个供下轮讨论的聚焦问题 |
角色分析节保留不变——各角色的对抗性产出本来就是报告核心价值，不受综合段格式调整影响。
第四步：Meta-Judgment Follow-up（用户补丁层）
brainstorm 综合报告不是最终答案。用户对 agent 产出做一次 meta 层反思是正常闭环步骤——不是"brainstorm 失败"，是 agent 抽象归因能力的自然边界（agent 擅长在议题给定框架内分析，不擅长主动跳出框架做 meta 判断）。
编排者应在综合报告末尾主动提示
📍 Meta-Judgment Check：请检查是否有 agent 都没覆盖的顶层判断需要补充。常见类型：
- 范式/设计的生命周期（3 年后这个方案是否仍成立？底模迭代后会怎样？）
- 虚假繁荣识别（产出量级本身是否是来源暴露信号？如"32 条决策 / 九维度"大概率是 agent 合集而非人类产出）
- 坐标系外维度（你的锚点都在"vs X"框架里吗？坐标系外的新概念被系统性漏掉了吗？）
- 时间维度（1 个月后这个判断还准确吗？维护/演化成本如何？）
信号识别
- 如果用户不补或只补 1 条 → skill 正常运行，角色覆盖到位
- 如果用户补 >1 条且 3-5 角色都没覆盖 → 是"下次换/加角色"的信号，编排者应记录在本 session 笔记里，作为未来类似议题的角色选择参考
Bad 反例参考
examples/retrospective-critique-with-author-proxy.md 末尾记录了一个 meta-judgment gap 案例——3 角色 brainstorm 完成后，用户补了 2 个顶层判断（范式长期兼容性 + 虚假繁荣识别），这 2 条 3 角色都没覆盖。这不是 skill 失败，是这个议题本身的 meta 层超出了 agent 框架分析能力——但也提醒：下次类似"外部方法论评估"议题，应预先在某个角色 prompt 里加入"时间维度"和"量级信号"的攻击面，减少 meta-gap。
质量要点
角色分析
- 每个角色给 3 个有力要点，胜过 5 个泛泛而谈。关键是"只有这个角色才会说这句话"
- 角色之间应当有真实张力，不要让所有角色说出类似的话
综合建议
- 建议必须有立场。"各有优劣，需根据情况判断"不是建议，是回避
- 如果确实无法给出明确方向，说清楚"缺少什么信息才能判断"
裁决示范（bad vs good）：
- BAD："两种方案各有优劣，取决于团队实际情况" ← 把决策推回给提问者，读完跟没读一样
- GOOD："选方案 A。虽然 B 的长期维护成本更低，但当前团队 12 个月 runway 意味着 6 个月内必须出成果，A 的 3 周交付周期是决定性优势" ← 有立场、有否定另一方案的理由、有约束条件、有核心逻辑
- 完整的 bad/good 对比案例见
examples/bad-vs-good-document-review.md
后续行动
行动按优先级分三层，每层 1-2 条：
- 🔴 前置条件：不确认就无法开始的事（验证假设、确认资源可用性）
- 🟡 主要工作：核心执行步骤
- 🟢 可选加固：锦上添花、风险缓解
技术类行动要包含具体命令或文件路径，不要只写动作描述：
- 好的行动：
ss -tlnup | grep 5432 确认 PostgreSQL 只绑定 127.0.0.1
- 差的行动：检查数据库配置是否安全
语言
- 跟随用户议题语言（中文议题→中文输出，英文议题→英文输出）
