Skill Amplifier

---
name: skill-amplifier
description: 执行模式增强器，配合其他能力型 skill 使用。将目标 skill 的工作拆分为多个维度，派发子 Agent 并行深度调研，汇总后由主 Agent 交叉复核再给出结论，放大执行深度。分析类 skill 走输出放大（拆评估维度深挖），生成类 skill 走输入放大（拆调研维度收集证据，写作仍由主 Agent 单线程完成）。仅显式触发：'放大执行'、'拆维度并行审查'、'深度模式跑一遍'、'skill amplifier'、'用放大模式执行 xxx'。区别于 expert-team（深挖业务模块）与 task-dispatch（拆分独立开发任务）：本 skill 拆的是同一对象的评估/调研维度。不自动介入任何 skill 的常规执行。
---

# 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（按角色/场景拆）、bug-impact-analysis（按影响面拆） |
| 生成/写作类 | ✅ 输入放大 | 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. 报告末尾附加"放大执行说明"段：

```markdown
### ⚡ 放大执行说明
- 执行方式：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 常规执行，不派发
```