Fanout -- 选择性发散性思维过程
经验基础：维护者的两个阶段评估。Fanout 在发散性设计任务上带来微小但 一致的提升，而在收敛性根本原因工作上毫无效果。仅当任务既开放 又高风险时，其约 7 倍的 Token 成本才物有所值。此技能的存在使得 需要时可随时启用这种提升，而绝不会在常规工作中触发。
第 0 步 -- 运行前门控（强制）
根据选择器检查任务。以下两点都必须为真：
- 开放式？ 存在多种有效答案（“X 的设计 / 命名 / 方法 / 假设”）。 如果任务是“X 为什么坏了”、“修复是否有效”、“根本原因是什么”， 或任何只有一个可验证答案的问题 -> 这是收敛性问题。告知用户 单次回答是此处更合适的工具，并在运行前询问是否仍要继续。 不要对收敛性任务静默运行。
- 高风险到值得花费约 7 倍 Token？ 这是一项关键的规则 / API 形状 / 命名 / 策略，而非无关紧要的。如果看起来风险低，请明确指出并确认。
如果门控条件模棱两可，请说明你的判断并询问。一旦通过，继续执行。
第 1 步 -- 获取问题
通过以下方式接受问题陈述：@提到的文件、文件路径或用户消息中粘贴的 文本。如果仅给出模糊的主题，首先要求一两句问题框架描述 -- 框架需要 一些具体内容。
第 1.5 步 -- 如果目标是项目工件则进行方向对齐（强制）
/fanout <文件路径> 看起来是已经对齐的，但并非如此：框架仅基于工件
本身进行推理，如果你不向它们提供项目状态，它们将自信地与项目的实时
状态相矛盾。在第 2 步之前，如果问题涉及（或命名）项目文件夹下的文件
-- 一份规范、决策文档、CHECKPOINT 线程、代码文件 -- 首先从头到尾
读取该项目的 CHECKPOINT.md（以及 CLAUDE.md，如果钩子没有提供的话）。
SessionStart 收据是字节/行数，而非文件本身 -- 预览不等于读取。然后
提取关键约束条件（截止日期、资金/排序门控、既定决策、已经尝试/拒绝过
的内容、硬性数字）并将它们原样粘贴到每个框架提示和评审提示中，
就像处理工件文本一样。一个只获得工件而未获得项目状态的框架是一个
已知的失败（对一个成本规范的真实 fanout 产生了“过早，应在盈亏平衡
后执行”的框架，这与项目的 CHECKPOINT 直接矛盾）。仅当问题
确实是纯项目无关的（粘贴的抽象问题、没有实时状态作为背景的命名/API
形状练习）时，才跳过此步。
第 2 步 -- 发散（5 个并行 Agent 调用，单条消息）
并行触发 5 个 general-purpose 代理（单条消息，5 次工具调用）。
向每个代理提供相同的问题和一个独特视角。每个代理的指令：
“仅从你指定的视角分析。生成 4-6 个不同的方法/想法；针对每个方法，
指出其失败模式（陷阱）并陈述其机制。要具体，指出机制名称，不要模棱
两可，不要排序，不要评估你自己的想 法。保持紧凑（这是为评审环节提供
输入）。”直接返回输出（除非用户要求保存，否则不写入文件）。
5 个视角（逐字使用）：
- 架构 / 系统 -- 以状态机、数据流以及信息在哪里转换或丢失的 方式来思考；系统在可见行为之下的层做了什么；在并发、故障或扩展 情况下如何失效。
- 对抗性 / 魔鬼代言人 -- 假设每个选项都有致命缺陷并找到它； 每个选项默认假设了什么；如果显而易见的答案是个诱饵，那什么是 真的。
- 第一性原理 -- 剥离到潜在机制，从真实约束出发重建，不信任 惯例；什么是实际需要的，什么仅仅是习惯上的。
- 实践者 / 运维人员 -- 你在生产环境中运行过它并在凌晨 3 点被 呼叫过；关心现场故障、边缘情况、运维负担、可观测性、设计与 on-call 现实之间的差距。
- 局外人 -- 没有领域背景；什么在直觉上合理；不信任掩盖循环 论证的行话；内部的专家可能错过的明显而事后看来却显而易见的陷阱。
第 3 步 -- 评审（1 次 Agent 调用）
一旦所有 5 个 Agent 返回，触发一个 general-purpose 代理，向其
提供所有 5 个输出 + 问题。指令：“1）对每个方法在新颖性/可行性/契合度
上打分（0-10）。2）根据潜在策略进行聚类；注意 2 个或更多框架
在哪里趋同（这种趋同是信号）。3）陷阱并集：跨所有 5 个框架的
去重后、以机制方式陈述的独特陷阱并集，每个陷阱附有其机制。4）深化
前 3 个：更精确的版本、机制、要避免的陷阱、其依赖的最风险假设 +
在承诺前测试该假设的最廉价方式，以及一个具体的第一步。输出部分：## 评分结果，## 聚类，## 陷阱并集，## 深化后的前三，## 综合
（4-6 句话：最强方向 + 最威胁它的陷阱）。”
第 4 步 -- 展示
向用户显示评审的**## 深化后的前三**、## 陷阱并集和**## 综合** 在聊天中。总结趋同点（多个框架独立得出的方向）。除非被要求，否则不要 转储所有 5 个原始框架输出。
默认不持久化任何内容（残留的临时文件本身就是麻烦）。如果用户需要完整 记录，提供将评审输出 + 框架保存到他们指定的路径。
注意事项
- 仅限使用原生 Agent 工具 -- 不要通过 shell 调用嵌套的
claude -p来运行框架（嵌套的 CLI 启动在权限/安全层下不可靠；Agent 工具是 支持的方式）。 - 每次调用为一次性（n=1）。如果用户希望进行方差检查，他们可以 再次调用 /fanout -- 但较小的效果量很少能证明其合理性。
- 绝不自动触发。仅通过描述中明确的显式触发方式触发。