多Agent评审

在执行开始前，由一组独立评审员对规格说明或计划进行评审。两个模型层级（快速+标准）并行评审三个主题中的每一个。当两个层级意见不一致时，由单个推理层级的评审员进行裁决。评审结论将决定后续工作流步骤是否可以继续。具体模型ID来自插件清单（步骤3）；以下层级名称为变量，而非模型名称。

调用时机

命令	调用时机	后续流程
`/multi-agent-review spec`	规格说明已编写并提交	`writing-plans`
`/multi-agent-review plan`	计划已编写并提交	`subagent-driven-development`

调用语法

/multi-agent-review [mode] [path?] [--fast]

mode:    spec | plan          (必填)
path:    明确的文件路径   (可选 — 省略则使用最新生成的工件)
--fast:  仅使用快速层级，跳过标准层级和评审员（用于快速迭代以节省成本）

如果操作者未指定mode，则从工件路径推断（

docs/superpowers/specs/

对应spec模式，

docs/superpowers/plans/

对应plan模式），并在调度前确认推断结果。

协调器步骤

步骤1 — 定位工件

spec模式：

bash

ls -t docs/superpowers/specs/*.md | head -1

使用返回的路径。如果提供了path参数，则使用该参数指定的路径。

同时检查是否存在匹配的

docs/design/

子目录：

bash

ls docs/design/ 2>/dev/null

如果存在匹配的设计原型，读取其文件名——将其作为补充上下文传递给一致性评审员。

plan模式：

bash

ls -t docs/superpowers/plans/*.md | grep -v tasks.json | head -1

同时查找关联的规格说明：读取计划文件，查找

Spec:

标题行或

planPath

字段，并加载该规格说明作为一致性评审员的补充上下文。

步骤2 - 验证，然后读取工件

调度前验证。在生成任何评审员之前：确认工件文件存在且非空，并且它引用的所有规格说明、原型或关联路径都能在磁盘上找到。缺失或为空的工件会导致六位评审员小组做无用功；此时应向操作者报告问题，而非进行调度。

超大工件。当工件超过约2000行时，停止操作并询问操作者：是继续使用完整工件，还是缩小到指定章节。对无法完整处理的文档进行六次评审会导致结果质量下降；询问操作者仅需一次交互。

完整读取工件内容，逐字保留。绝不要在将工件传递给Agent之前截断或总结任何部分——收到缩写规格说明的Agent会将缺失部分标记为BLOCKER，产生误报从而影响评审结论。如果文件较大，可以分块读取，但在构建提示词前要组装成完整文本。

步骤3 — 解析模型层级，读取关联文件，读取项目规则

模型层级解析：

定位插件清单（请勿使用相对路径

.claude-plugin/plugin.json

——该路径相对于用户项目，而非插件安装目录）。按以下顺序尝试，直到找到可用的清单：

${CLAUDE_PLUGIN_ROOT}/.claude-plugin/plugin.json

- Claude Code

${CLAUDE_PLUGIN_ROOT}/.codex-plugin/plugin.json

- Codex（如果设置了该变量）

${CLAUDE_PLUGIN_ROOT}/.cursor-plugin/plugin.json

- Cursor

<本SKILL.md所在目录>/../../.claude-plugin/plugin.json

- 向上遍历两级目录

<本SKILL.md所在目录>/../../.codex-plugin/plugin.json

- Codex的相同回退路径

<本SKILL.md所在目录>/../../.cursor-plugin/plugin.json

- Cursor的相同回退路径

硬编码回退值：

{ "fast": "haiku", "standard": "sonnet", "reasoning": "opus" }

从第一个加载成功且包含
models
键的清单中读取

"models"

对象。如果加载的清单没有

models

键，不要停止搜索——继续尝试下一个候选清单，仅当所有候选都尝试完毕后才使用硬编码回退值。（如果没有此规则，仅存在的清单会将层级解析为空，导致步骤5调度时使用未定义的模型ID。）

用于尝试选项1-3的快速bash命令：

bash

for m in .claude-plugin .codex-plugin .cursor-plugin; do
  jq -e '.models' "$CLAUDE_PLUGIN_ROOT/$m/plugin.json" 2>/dev/null && break
done

从

models.fast

、

models.standard

、

models.reasoning

中分别存储

FAST_TIER

、

STANDARD_TIER

、

REASONING_TIER

。在步骤5和步骤7中使用这些变量——绝不要硬编码模型名称。

读取关联提示词文件：

从本SKILL.md所在目录旁的

agents/

目录中读取以下四个文件：

```
agents/completeness-reviewer.md
```
```
agents/alignment-reviewer.md
```
```
agents/risk-reviewer.md
```
```
agents/synthesis-agent.md
```

每个文件都包含一个带围栏的提示词模板。提取最外层```围栏内的内容。

同时检查项目根目录（与CLAUDE.md同一目录）中是否存在

project-rules.md

文件：

bash

cat project-rules.md 2>/dev/null || echo ""

如果找到，将其内容读取到

PROJECT_CONTEXT

中。该文件用于项目配置其常规规则、安全约束和特定代码库的约定。

如果不存在，则回退到项目的

CLAUDE.md

（或

AGENTS.md

），并添加以下说明，以便评审员不会将工作指令视为评审标准：“以下是项目的通用工作指令，并非专门制定的评审规则。仅将其中可视为规格说明和计划的常规约束的内容应用于评审；忽略有关工具、工作流或Agent行为的指令。”如果两个文件都不存在，

PROJECT_CONTEXT

为空字符串。

步骤4 — 构建六个Agent的提示词

对于三个主题提示词（完整性、一致性、风险）中的每一个：

将
```
[ARTIFACT_CONTENT]
```
替换为完整的工件文本。
将
```
[MODE_LABEL]
```
替换为
```
"spec"
```
或
```
"plan"
```
。
将
```
[PROJECT_CONTEXT]
```
替换为
```
project-rules.md
```
的内容（或空字符串）。
仅针对一致性评审员——将
```
[SUPPLEMENTARY_CONTEXT]
```
替换为：
- spec模式：原型HTML文件名及其路径列表
- plan模式：关联的规格说明内容

步骤5 — 并行调度六个Agent

通过单条消息并行调用Agent工具发送所有六个请求：

Agent(completeness-fast):     model=FAST_TIER,     prompt=completeness_prompt
Agent(completeness-standard): model=STANDARD_TIER, prompt=completeness_prompt
Agent(alignment-fast):        model=FAST_TIER,     prompt=alignment_prompt
Agent(alignment-standard):    model=STANDARD_TIER, prompt=alignment_prompt
Agent(risk-fast):             model=FAST_TIER,     prompt=risk_prompt
Agent(risk-standard):         model=STANDARD_TIER, prompt=risk_prompt

（将

FAST_TIER

STANDARD_TIER

替换为步骤3中解析得到的实际模型ID。）

跨供应商调度。如果层级值以

cli:

为前缀（例如

"standard": "cli:codex"

），则表示：通过运行指定的CLI来调度该层级的三位评审员，而非使用Agent工具。提示词相同，输出约定相同。这使得跨模型意见不一致成为独立的第二意见，而非同一供应商的能力差距；来自同一供应商的快速/标准组合仍能发现实际缺陷，但其意见不一致部分反映了模型规模的差异，评审员会继承这种偏差。如果有第二个供应商的CLI可用，优先选择跨供应商的标准层级。

--fast模式的升级防护。在启用

--fast

模式之前，扫描工件中的高风险标记：认证、授权、安全、密钥、支付、计费、迁移、数据删除、生产基础设施，或项目规则标记为安全关键的任何内容。如果检测到这些标记，拒绝使用

--fast

模式，告知操作者触发拒绝的标记，并运行完整的评审小组。对于最需要评审小组的工作，绝不能使用单层级折扣。

如果传递了

--fast

参数（且未被拒绝）：仅调度三个

FAST_TIER

Agent，然后完全跳过步骤6和步骤7，直接进入步骤8。由于每个主题只有一个模型，没有可比较的配对，也没有需要裁决的内容，因此在此模式下

CONTESTED_LIST

不存在。

⚠ --fast模式安全说明：

--fast

是单层级评审：没有跨模型检查，也没有评审员。请勿在涉及生产安全关键或不可逆路径的内容上使用

--fast

模式。仅将其用于轻量级非安全工件（工具、文档、UI文案）。

调度后，跟踪哪些Agent返回了有效的报告。有效报告至少包含一行以

FINDINGS:

开头的内容。记录哪些Agent出错或超时——这将用于步骤8的法定人数检查。

步骤6 — 对比配对结果，识别有争议的发现

首先——检查出错的Agent。如果报告缺失或格式错误（没有

FINDINGS:

行），则将该Agent视为返回了

FINDINGS: ERROR — agent did not respond

。在对比之前，先进行步骤8的法定人数检查。

对于每个主题配对（该主题的haiku报告与sonnet报告）：

如果出现以下任何一种情况，则该发现被视为有争议：

同一发现出现在两份报告中，但严重程度不同
某一发现出现在一份报告中，但未出现在另一份报告中（通过标题关键词或详细内容匹配）
一个模型输出
```
FINDINGS: none
```
，但另一个模型输出了发现结果

为每个有争议的条目构建

CONTESTED_LIST

，格式如下：

TOPIC: completeness | alignment | risk
HAIKU said: [severity] — <确切文本> 或 "not raised"
SONNET said: [severity] — <确切文本> 或 "not raised"

步骤7 — 调用评审员（仅当CONTESTED_LIST非空时）

如果

CONTESTED_LIST

为空：直接跳至步骤8。

如果

CONTESTED_LIST

包含条目：

从
```
synthesis-agent.md
```
构建评审员提示词：
- 将
```
[ALL_SIX_REPORTS]
```
  替换为所有六份报告的原始文本拼接内容
- 将
```
[CONTESTED_LIST]
```
  替换为步骤6中构建的有争议列表
调度单个评审员Agent：
```
model=REASONING_TIER
```
（步骤3中解析得到）
收集
```
JUROR RULINGS
```
响应

**评审员故障回退：**如果评审员Agent出错、超时或返回格式错误的响应（没有

JUROR RULINGS:

行），请勿进入步骤8。相反：将所有有争议的发现升级为BLOCKER严重程度（保守回退），并向操作者展示“JUROR FAILED — treating all contested findings as BLOCKER”。这是故障关闭机制：评审员故障不能让有争议的BLOCKER被忽略。

步骤8 — 法定人数检查 + 编译最终结论

法定人数检查（首先执行）：

统计有效报告数量（那些返回了

FINDINGS:

行的报告，包括

FINDINGS: none

）。

--fast

模式法定人数：评审小组为3人，而非6人。有效报告少于2份 = 终止（使用相同消息，显示N/3）；恰好2份 = 添加评审小组健康状况警告；3份 = 正常继续。

完整评审小组法定人数：

if valid_reports < 3:
    终止 — 向操作者展示：
    "⛔ 评审中止 — 仅N/6个Agent返回了有效报告。
     少于3位评审员无法生成可靠结论。
     选项：(a) 重新运行，(b) 检查API/速率限制问题，(c) 覆盖并继续。"
    不要调用决策门。

if valid_reports < 6:
    向结论添加评审小组健康状况警告：
    [WARNING] 部分评审小组 — N/6个Agent响应
      详情：6位评审员中有<N>位未能返回有效报告；可能存在覆盖缺口。
      位置：Agent调度

然后编译已接受的发现：

--fast

模式编译规则：没有配对，也没有评审员，因此接受所有有效报告中的每一个发现，保留生成该发现的模型指定的严重程度。存在此规则是因为下面的配对一致逻辑在

--fast

模式下会接受无内容，而始终为空的accepted_findings列表会在每次运行时默认生成干净结论——这是评审小组故障表禁止的精确故障情况。

完整评审小组编译：

accepted_findings = []

For each topic pair:
  For each finding where BOTH models agreed (same title + same severity):
    add to accepted_findings at agreed severity

If juror was invoked:
  For each RULING in JUROR RULINGS:
    add to accepted_findings
  For each SYNTHESISED finding (if any):
    add to accepted_findings

BLOCKERS  = findings with severity BLOCKER
WARNINGS  = findings with severity WARNING
OBS       = findings with severity OBS

**跨主题去重（分组前）：**同一缺陷被两个主题标记（位置匹配且描述重叠）视为一个发现，保留最高严重程度，并标注两个主题。如果没有此规则，一个缺口会在结论中被重复计数，被视为两个需要修复的问题。

步骤9 — 决策门

在每个人工结论旁，输出一个带围栏的JSON块，以便下游自动化工具和下一个skill无需解析 prose 即可使用决策门结果：

json

{"verdict": "BLOCKED | WARNINGS | CLEAN | HALTED",
 "blockers": [], "warnings": [], "obs": [],
 "panel_health": [], "iteration": 1}

迭代上限。跟踪迭代次数——首次调用=1，每次操作者请求重新运行时递增。上限为3次迭代。

当

iteration_count >= 3

时：

不再提供“修复+重新运行”选项。
展示当前结论，并添加标题：

"⛔ 评审已耗尽 — 已达到3次迭代。显示最终发现结果。"
操作者的唯一选择是：
- (a) 覆盖并继续 — 尽管存在剩余阻塞项，仍调用下一个skill（根据下面的覆盖日志规则记录覆盖操作）。
- (b) 中止 — 不调用下一个skill；工件未准备就绪。

不要无限循环。经过3轮后，我们已经获得足够的信号——继续追逐阻塞项只会浪费周期，还会出现风格化噪音。

如果存在BLOCKERS：

清晰展示阻塞项：

⛔ 评审被阻塞 — 必须解决N个阻塞项才能继续。

阻塞项：
1. [标题] (主题: X, 置信度: Y)
   详情: ...
   位置: ...

询问操作者：

两个选项：
  (a) 现在修复工件中的阻塞项，然后我将重新运行完整评审。
  (b) 覆盖 — 确认阻塞项并继续（我会记录覆盖操作）。

请勿自动继续。等待操作者响应。

如果选择(a)：操作者确认修复后，从步骤1重新运行（完整循环）。
如果选择(b)：将覆盖记录写入stdout，并将
```
git note
```
追加到工件最新提交中：
bash
```
git notes append -m "MULTI-AGENT-REVIEW OVERRIDE $(date -u +%Y-%m-%dT%H:%M:%SZ): operator acknowledged N blockers: [titles]" HEAD
```
然后调用下一个skill。git note是持久化的，与工件的提交历史共存。

如果存在WARNINGS（无阻塞项）：

⚠ 评审通过但存在警告 — N个警告。

警告：
1. [标题] (主题: X)
   详情: ...
   位置: ...

在继续前修复警告，还是接受并继续？

等待操作者响应。

修复 → 操作者确认后从步骤1重新运行。
继续 → 调用下一个skill。

如果结论干净（无阻塞项，无警告）：

✅ 评审通过 — N个发现结果（0个阻塞项，0个警告，M个观察项）。

如果OBS > 0，在通过行下方列出这些观察项。

自动调用下一个skill：

```
spec
```
模式 → 调用
```
writing-plans
```
```
plan
```
模式 → 调用
```
subagent-driven-development
```

评审小组故障语义

以下规则规定了当评审小组未干净完成时的处理方式：

故障	行为
有效报告<3份	终止 — 中止，向操作者展示，不生成结论
有效报告3–5份	添加评审小组健康状况警告，继续进行部分覆盖评审
有效报告6份	正常继续
评审员出错/超时	保守回退 — 将所有有争议的发现升级为BLOCKER，展示为“JUROR FAILED”
所有Agent出错	终止 — 空的accepted_findings绝不能默认触发干净结论
`--fast` 模式	单层级，无争议内容：接受所有有效报告中的每一个发现，保留其生成时的严重程度；法定人数为3份中的2份；结论附带说明：未进行跨模型裁决

绝不允许不完整的评审小组生成干净结论。如有任何疑问，终止并向操作者展示。

模型分配

模型ID在运行时从活动插件清单的

"models"

字段解析得到。以下显示Claude Code的默认值；Codex和其他平台通过各自的plugin.json覆盖。

层级变量	CC默认值	Codex默认值	Cursor默认值	角色
`FAST_TIER`	`haiku`	`gpt-5.6-luna`	`claude-haiku`	快速评审员（始终使用）
`STANDARD_TIER`	`sonnet`	`gpt-5.6-terra`	`claude-sonnet`	标准评审员（使用 `--fast` 时跳过）
`REASONING_TIER`	`opus`	`gpt-5.6-sol`	`claude-opus`	评审员（不可覆盖：使用弱模型进行裁决会失去其意义）

如果层级值以

cli:

为前缀（例如

"standard": "cli:codex"

），则根据步骤5的跨供应商规则，通过指定的外部CLI调度该层级。如果有第二个供应商的CLI可用，优先选择此方式。

本skill不做的事情

不修复工件 — 仅展示发现结果；由操作者进行修改
不评审代码 — 这是
```
subagent-driven-development
```
的工作
默认使用
```
docs/superpowers/
```
下最新的规格说明或计划；显式路径参数会覆盖此默认行为

关联文件

```
agents/completeness-reviewer.md
```
- 占位符、缺失的评审标准、未定义的引用
```
agents/alignment-reviewer.md
```
- 原型/代码库一致性、常规规则
```
agents/risk-reviewer.md
```
- 生产安全、故障关闭路径
```
agents/synthesis-agent.md
```
- 评审员提示词，仅在存在争议发现时调度

assets/project-rules.example.md

- 模板，可复制到项目中作为

project-rules.md

multi-agent-review

NPX安装

标签

SKILL.md 内容（中文）

多Agent评审

调用时机

调用语法

协调器步骤

步骤1 — 定位工件

步骤2 - 验证，然后读取工件

步骤3 — 解析模型层级，读取关联文件，读取项目规则

步骤4 — 构建六个Agent的提示词

步骤5 — 并行调度六个Agent

步骤6 — 对比配对结果，识别有争议的发现

步骤7 — 调用评审员（仅当CONTESTED_LIST非空时）

步骤8 — 法定人数检查 + 编译最终结论

步骤9 — 决策门

评审小组故障语义

模型分配

本skill不做的事情

关联文件