Skill Amplifier（执行模式放大器）

概述

目的：解决单线程执行能力型 skill 时"每个维度都只能浅走一遍"的问题——上下文有限，维度越多每个维度分到的深度越少。

功能：把目标 skill 的工作拆成独立维度，每个维度交给一个子 Agent 深度调研，主 Agent 汇总后做覆盖检查、冲突检测、关键结论核实，最后按目标 skill 的原生输出格式给出结论。支持两种放大模式：输出放大（分析类 skill，拆评估维度并行深挖）与输入放大（生成类 skill，拆调研维度并行收集证据，写作仍由主 Agent 单线程完成）。

使用场景：

• 用户明确说"放大执行"、"拆维度并行审查"、"深度模式跑一遍"时
• 用户说"用 amplifier 跑 code-review"、"把这个 review 拆开深挖"时
• 任务对象规模大（多文件变更、长文档、大模块），单线程执行明显吃不下深度时，可向用户建议使用（但仍需用户确认，不自动介入）

核心定位

本 skill 不提供任何业务能力，只改变目标 skill 的执行方式：

常规执行：主 Agent 单线程走完目标 skill 全部工作（每个环节浅）
输出放大（分析类）：拆评估维度 → 子 Agent 各深挖一个维度 → 主 Agent 复核汇总（每个维度深）
输入放大（生成类）：拆调研维度 → 子 Agent 并行收集证据 → 主 Agent 单线程写作（输入更厚，写作不拆）

三条底线：

1. 只在显式触发时介入，绝不劫持目标 skill 的常规执行
2. 尊重目标 skill 的原生方案：目标 skill 自带并行/串行纪律的，按它自己的来，本 skill 只补它没覆盖的环节
3. 不发明新报告格式：最终产出必须用目标 skill 的原生输出格式，本 skill 只附加一段"放大执行说明"

---

执行流程

步骤 1：确认目标 skill 与适用性

1. 确认目标 skill：用户已指明（如"用放大模式跑 code-review"）则直接锁定；未指明则根据当前任务推断并向用户确认
2. 适用性检查——目标 skill 的工作必须可按维度独立评估或调研：

类型	放大模式	示例
分析/审查/调研类	✅ 输出放大	code-review、design-review、challenger、code-survey、harness-review
推演/验证类	✅ 输出放大	scenario-rehearsal（按角色/场景拆）、code-change-impact（按影响面拆）
生成/写作类	✅ 输入放大	design-craft、document-writer、api-design（只放大写作前的调研；写作不拆——拆开写会风格割裂）
流程编排类	❌ 不适用	task-dispatch、auto-review（本身就是编排器，无维度可拆）

不适用时明确告知用户原因，退回目标 skill 常规执行。

步骤 2：读取目标 skill，提取维度

维度来源优先级：

1. 目标 skill 自带维度定义 → 直接采用（如 code-review 的七大维度、scenario-rehearsal 的角色/场景拆分、harness-review 的五维度）
2. 无维度定义 → 现场推导：按任务对象特征拆出 3~6 个维度，要求相互独立、合并后覆盖目标 skill 的完整职责；推导结果先向用户展示确认再派发
3. 输入放大模式 → 同样遵循自带优先：目标 skill 自带调研环节（如 design-craft 集成的 code-survey、dependency-docs）则直接沿用其调研维度定义，只把执行方式换成并行派发；无自带调研环节才按信息需求推导（如：代码现状 / 依赖约束 / 已知坑与风险 / 相似实现参考），同样 3~6 个，向用户展示确认再派发

原生并行纪律检查（关键）：

读取目标 skill 时同时检查它是否已内置并行/串行纪律（如 code-review 约束 13：语义一致性与架构必须主 Agent 串行、其余维度可派发）：

• 有内置纪律 → 完全按它的来：它说必须串行的维度绝不派发给子 Agent；它已定义的派发方式不重复设计；本 skill 只补它未覆盖的环节（通常是"汇总后交叉复核"）
• 无内置纪律 → 按本 skill 默认协议执行（步骤 3~5）

维度数量控制在 3~6 个，超出则按相关性合并——维度过碎会导致子 Agent 上下文不足、跨维度问题无人认领。

对象过大时的二维拆分：任务对象规模超过单个子 Agent 可深挖范围（经验阈值：变更超过 20 个文件、文档超过万字，可按对象实际情况调整）时，只按维度拆意味着每个子 Agent 仍面对全量对象，深度会被重新摊薄。此时先按对象分片（模块 / 文件组 / 章节），形成"对象 × 维度"矩阵派发：优先每个维度一个子 Agent、维度内按分片顺序深挖；仍吃不下则同一维度拆多个子 Agent 各管一片。分片方案随维度一并向用户确认。

步骤 3：准备共享上下文，派发子 Agent

1. 共享上下文先行：主 Agent 先完成一次性调研（任务对象概况、全局图景、关键背景），写成共享上下文，避免每个子 Agent 重复调研同样的基础信息
2. 原生串行维度先行：目标 skill 的原生纪律要求串行、且作为其他维度前置上下文的维度（如 code-review 约束 13 的语义一致性、架构），必须由主 Agent 先执行，其结论并入共享上下文后再派发其余可并行维度——否则子 Agent 拿不到前置结论会各判各的
3. 轻量派发协议：每个维度直接派发一个子 Agent（只读调研，不修改任何文件），维度报告落盘到 .codebuddy/skill-amplifier/<任务名>/dimensions/<维度名>.md，主 Agent 读文件汇总——子 Agent 的中间调研过程不进主上下文，报告可追溯留档。不复用 task-dispatch——它面向编码任务（代码产出、合并集成、编译校验），分析型子任务套用只会空转流程。子任务卡必须包含：

- 维度定义：本子 Agent 只负责 <维度名>，不越界处理其他维度
- 执行依据：目标 skill 中该维度对应的章节/清单/标准（摘录或指路）
- 共享上下文：主 Agent 预调研结论
- 深挖要求：不是把流程走一遍，而是深度调研——读代码/文档/历史提交等一手证据，
  每条结论必须附证据（文件:行号 / 文档章节 / 复现步骤）
- 输出契约：结论清单（含证据与置信度）+ 跨维度线索（发现疑似属于其他维度的问题时，
  标注线索移交主 Agent，不自行处理），写入指定的维度报告文件

4. 降级路径：子 Agent 派发能力不可用时，主 Agent 按维度串行深挖，报告仍落盘，其余流程不变
5. 输入放大模式：派发协议相同，各调研维度报告合并为证据包，供步骤 5 主 Agent 写作时引用

步骤 4：汇总与交叉复核（本 skill 的核心增值）

子 Agent 结论不直接采信，主 Agent 依次做四项复核：

复核项	做法	不通过的处理
覆盖检查	逐维度核对交付是否完整，有无维度缩水成"走了个过场"	缩水维度退回补查或主 Agent 补做
冲突检测	跨维度结论是否矛盾（如 A 维度说"该路径无调用方"、B 维度基于该路径调用方报了问题）	回查证据裁决，以一手证据为准
关键结论核实	高严重度发现逐条回查原始证据核实（不凭子 Agent 转述），其余结论抽样核实	证据不实的结论降级或剔除
归并去重	多个维度报同一根因的问题合并为一条，跨维度线索认领处理	—

补查协议：退回补查必须定向——把复核发现的具体缺口写进补查任务卡，只补缺口不重跑全量；补查最多 1 轮，仍不达标由主 Agent 接管补做，防止无限循环。

步骤 5：按目标 skill 原生格式输出结论

1. 最终报告使用目标 skill 的输出格式（如 code-review 的 Review Report、challenger 的质疑报告），使目标 skill 的下游消费方（auto-review、评审人）无感知差异
2. 输入放大模式：主 Agent 按目标 skill 原生流程单线程完成写作，证据包只作输入，产出天然是原生格式且全局一致
3. 报告末尾附加"放大执行说明"段：

### ⚡ 放大执行说明
- 执行方式：skill-amplifier × <目标 skill>（输出放大 / 输入放大）
- 维度拆分：<维度1> / <维度2> / ...（来源：skill 自带 / 现场推导）
- 派发情况：N 个子 Agent 并行（或降级串行），串行保留维度：<按原生纪律保留的维度>
- 复核结果：覆盖 ✅｜冲突 X 处已裁决｜核实 X 条（高严重度逐条 / 证据不实降级 X）

---

约束与原则

1. 显式触发：只有用户明确要求时才启用，任务大时最多"建议"，不得自行切换执行模式
2. 尊重原生方案：目标 skill 自带并行/串行纪律时完全遵从，其串行约束绝不违反；本 skill 只补空缺环节
3. 维度来源优先级：skill 自带维度 > 现场推导；现场推导必须经用户确认
4. 子 Agent 结论不直接采信：高严重度结论必须逐条经主 Agent 证据核实后才能进入最终报告，其余结论抽样核实
5. 输出格式跟随目标 skill：不发明新报告模板，只附加放大执行说明段
6. 越界纪律：子 Agent 只做分配维度，跨维度发现只标线索、移交主 Agent
7. 降级不失能：子 Agent 派发能力不可用时降级为主 Agent 串行分维度深挖，复核环节照常执行
8. 适用性守门：流程编排类 skill 不适用，明确告知后退回常规执行
9. 写作不拆：输入放大模式只并行化写作前的调研，写作环节绝不拆分给子 Agent，保产物全局一致性

示例

场景：用户说"用放大模式 review 这次提交"

1. 锁定目标 skill：code-review（分析类 → 输出放大）
2. 读取 code-review：有七大维度 + 内置并行纪律（约束 13）
   → 维度直接用；语义一致性/架构按原生纪律保留主 Agent 串行，
     安全/Bug风险/规范/性能/测试派发子 Agent
3. 主 Agent 预调研 + 先跑串行维度：变更概况 + 全局图景，并先执行语义一致性/架构分析，结论写入共享上下文
4. 派发 5 个子 Agent 深挖安全/Bug风险/规范/性能/测试维度（读代码、查调用方、附行号证据），报告落盘 dimensions/
5. 汇总复核：安全维度与 Bug 维度报了同一根因 → 归并；高严重度结论逐条核实 → 证据属实保留
6. 按 code-review 的 Review Report 格式输出，末尾附放大执行说明

场景：目标 skill 无维度定义 → 现场推导

1. 用户"用放大模式审查这份接口文档"：无专用 skill，退回通用审查（分析类 → 输出放大）
2. 无自带维度 → 现场推导 4 个维度（契约完整性 / 错误码 / 兼容性 / 安全），展示给用户确认
3. 无原生串行纪律 → 主 Agent 预调研后直接派发 4 个子 Agent
4. 复核：契约维度与兼容性维度结论冲突 → 回查证据裁决
5. 按通用审查格式输出 + 放大执行说明

场景：生成类 skill → 输入放大

1. 用户"用放大模式写这个模块的设计文档"：锁定 design-craft（生成类 → 输入放大）
2. 推导调研维度：design-craft 自带调研环节（code-survey、dependency-docs）→ 直接沿用其维度定义，并行化执行，向用户确认
3. 派发 4 个子 Agent 并行调研，报告落盘合并为证据包
4. 主 Agent 按 design-craft 原生流程单线程写作，引用证据包，全局一致性不破
5. 产出即 design-craft 原生格式 + 放大执行说明

场景：不适用对象 → 拒绝并退回

1. 用户"用放大模式跑 auto-review"：流程编排类 ❌ 不适用（本身是编排器，无维度可拆）
2. 告知用户原因，退回 auto-review 常规执行，不派发