multi-agent-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Multi-Agent Review

多Agent评审

Run a panel of independent reviewers on a spec or plan before execution starts. Two model tiers (fast + standard) review each of three topics in parallel. When the tiers disagree, a single reasoning-tier juror adjudicates. The verdict gates whether the next workflow step proceeds. Concrete model IDs come from the plugin manifest (Step 3); the tier names below are variables, not model names.

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

When to invoke

调用时机

Command	Fire after	Proceeds to
`/multi-agent-review spec`	spec is written and committed	`writing-plans`
`/multi-agent-review plan`	plan is written and committed	`subagent-driven-development`

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

Invocation syntax

调用语法

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

mode:    spec | plan          (required)
path:    explicit file path   (optional — omit to use most-recent artifact)
--fast:  fast tier only, skip standard tier and juror (cost-saving for fast iteration)

If the operator omits the mode, infer it from the artifact's path (

docs/superpowers/specs/

docs/superpowers/plans/

) and confirm the inference before dispatching.

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

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

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

docs/superpowers/specs/

对应spec模式，

docs/superpowers/plans/

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

Coordinator steps

协调器步骤

Step 1 — Locate the artifact

步骤1 — 定位工件

spec mode:

bash

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

Use the path returned. If a

path

arg was provided, use that instead.

Also check for a matching

docs/design/

subdirectory:

bash

ls docs/design/ 2>/dev/null

If matching design mockups exist, read their filenames — pass them to the alignment reviewer as supplementary context.

plan mode:

bash

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

Also find the linked spec: read the plan file, look for a

Spec:

header line or

planPath

, and load that spec as supplementary context for the alignment reviewer.

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

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

Step 2 - Validate, then read the artifact

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

Pre-dispatch validation. Before spawning anything: the artifact file exists and is non-empty, and every spec, mockup, or companion path it references resolves on disk. A missing or empty artifact burns a six-agent panel on false positives; report it to the operator instead of dispatching.

Oversized artifacts. Above roughly 2,000 lines, stop and ask the operator: proceed with the full artifact, or narrow to a named section. Six reviews of a document too large to hold degrade silently; the question costs one turn.

Read the full artifact content verbatim. Never truncate or summarise any part of the artifact before passing it to agents — an agent that receives an abbreviated spec will flag missing sections as BLOCKERs, producing false positives that poison the verdict. If the file is large, read it in chunks but assemble the full text before building prompts.

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

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

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

Step 3 — Resolve model tiers, read companion files, read project rules

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

Model tier resolution:

Locate the plugin manifest (do NOT use a bare

.claude-plugin/plugin.json

relative path — that resolves against the user's project, not the plugin install). Try in order until one succeeds:

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

- Claude Code

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

- Codex if it sets this var

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

- Cursor

<dir of this SKILL.md>/../../.claude-plugin/plugin.json

- walk up two levels

<dir of this SKILL.md>/../../.codex-plugin/plugin.json

- same fallback for Codex

<dir of this SKILL.md>/../../.cursor-plugin/plugin.json

- same fallback for Cursor

Hardcoded fallback:

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

Read the

"models"

object from the first manifest that loads and contains a
models
key. A manifest that loads but has no

models

key does not stop the search - keep trying the next candidate, and use the hardcoded fallback only when the list is exhausted. (Without this rule, a manifest that merely exists resolves the tiers to nothing and Step 5 dispatches with undefined model IDs.)

Quick bash to try options 1-3:

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

Store

FAST_TIER

STANDARD_TIER

REASONING_TIER

from

models.fast

models.standard

models.reasoning

. Use these in Step 5 and Step 7 - never hardcode model names.

Read companion prompt files:

Read these four files from the

agents/

directory beside this SKILL.md:

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

Each contains a fenced prompt template. Extract the content inside the outermost ``` fence.

Also check for a

project-rules.md

file in the project root (same directory as CLAUDE.md):

bash

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

If found, read it into

PROJECT_CONTEXT

. This file is where projects configure their standing rules, safety constraints, and codebase-specific conventions.

If absent, fall back to the project's

CLAUDE.md

(or

AGENTS.md

) rather than reviewing rules-blind, prefixed with this framing so reviewers do not treat working instructions as review criteria: "The following are the project's general working instructions, not purpose-built review rules. Apply only the ones that read as standing constraints on specs and plans; ignore instructions about tooling, workflow, or agent behavior." If neither file exists,

PROJECT_CONTEXT

is the empty string.

模型层级解析：

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

.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

为空字符串。

Step 4 — Build the six agent prompts

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

For each of the three topic prompts (completeness, alignment, risk):

Replace
```
[ARTIFACT_CONTENT]
```
with the full artifact text.
Replace
```
[MODE_LABEL]
```
with
```
"spec"
```
or
```
"plan"
```
.
Replace
```
[PROJECT_CONTEXT]
```
with the content of
```
project-rules.md
```
(or empty string).
For the alignment reviewer only — replace
```
[SUPPLEMENTARY_CONTEXT]
```
with:
- spec mode: list of mockup HTML filenames + their paths
- plan mode: the linked spec content

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

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

Step 5 — Dispatch six agents in parallel

步骤5 — 并行调度六个Agent

Send all six in a single message with parallel Agent tool calls:

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

(Substitute

FAST_TIER

STANDARD_TIER

with the actual model IDs resolved in Step 3.)

Cross-vendor dispatch. A tier value prefixed

cli:

(for example

"standard": "cli:codex"

) means: dispatch that tier's three reviewers by running the named CLI with the built prompt, instead of the Agent tool. Same prompts, same output contract. This makes cross-model disagreement an independent second opinion rather than a same-vendor capability gap; a fast/standard pair from one vendor still catches real defects, but its disagreements partly measure model size, and the juror inherits that bias. Prefer a cross-vendor standard tier where a second vendor's CLI is available.

--fast escalation guard. Before honoring

--fast

, scan the artifact for high-risk markers: authentication, authorization, security, secrets, payment, billing, migration, data deletion, production infrastructure, or anything the project rules mark safety-critical. On a hit, refuse

--fast

, tell the operator which marker triggered the refusal, and run the full panel. The single-tier discount is never available for the work that needs the panel most.

--fast

was passed (and not refused): dispatch only the three

FAST_TIER

agents, then skip Steps 6 and 7 entirely and go to Step 8. With one model per topic there is no pair to compare and nothing to adjudicate, so

CONTESTED_LIST

does not exist in this mode.

⚠ --fast safety note:

--fast

is a single-tier review: no cross-model check and no juror. Do NOT use

--fast

on anything touching production-safety-critical or irreversible paths. Reserve it for lightweight non-safety artifacts (tooling, docs, UI copy).

After dispatching, track which agents returned valid reports. A valid report contains at least one line starting with

FINDINGS:

. Record which agents errored or timed out — this is used in Step 8's quorum check.

通过单条消息并行调用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的法定人数检查。

Step 6 — Compare pairs, identify contested findings

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

First — check for errored agents. If a report is missing or malformed (no

FINDINGS:

line), treat that agent as having returned

FINDINGS: ERROR — agent did not respond

. Proceed to the quorum check in Step 8 before comparing.

For each topic pair (haiku report vs sonnet report for that topic):

A finding is CONTESTED if ANY of the following:

Same finding appears in both reports but at different severity levels
A finding appears in one report but NOT in the other (match by title keywords or detail content)
One model emitted
```
FINDINGS: none
```
but the other emitted findings

Build a

CONTESTED_LIST

with this format for each contested item:

TOPIC: completeness | alignment | risk
HAIKU said: [severity] — <exact text> or "not raised"
SONNET said: [severity] — <exact text> or "not raised"

首先——检查出错的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"

Step 7 — Invoke juror (ONLY if CONTESTED_LIST is non-empty)

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

CONTESTED_LIST

is empty: skip directly to Step 8.

CONTESTED_LIST

has entries:

Build the juror prompt from
```
synthesis-agent.md
```
:
- Replace
```
[ALL_SIX_REPORTS]
```
  with the concatenated raw text of all six reports
- Replace
```
[CONTESTED_LIST]
```
  with the contested list built in Step 6
Dispatch a single juror agent:
```
model=REASONING_TIER
```
(resolved in Step 3)
Collect
```
JUROR RULINGS
```
response

Juror failure fallback: If the juror agent errors, times out, or returns a malformed response (no

JUROR RULINGS:

line), do NOT proceed to Step 8. Instead: promote every contested finding to BLOCKER severity (conservative fallback) and present them to the operator as "JUROR FAILED — treating all contested findings as BLOCKER". This is fail-closed: a dead juror cannot let a contested BLOCKER silently degrade.

如果

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被忽略。

Step 8 — Quorum check + compile final verdict

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

Quorum check (do this FIRST):

Count valid reports (those that returned a

FINDINGS:

line, including

FINDINGS: none

--fast

mode quorum: the panel is 3, not 6. Fewer than 2 valid reports = HALT (same message, with N/3); exactly 2 = add the panel-health WARNING; 3 = proceed normally.

Full-panel quorum:

if valid_reports < 3:
    HALT — present to operator:
    "⛔ REVIEW ABORTED — only N/6 agents returned valid reports.
     Cannot produce a reliable verdict with fewer than 3 reviewers.
     Options: (a) Re-run, (b) Check for API/rate-limit issues, (c) Override and proceed."
    Do NOT invoke the decision gate.

if valid_reports < 6:
    Add a panel-health WARNING to the verdict:
    [WARNING] Partial panel — N/6 agents responded
      detail: <N> of 6 reviewers failed to return a valid report; coverage gaps possible.
      location: Agent dispatch

Then compile accepted findings:

--fast

mode compile rule: there are no pairs and no juror, so accept EVERY finding from every valid report, at the severity the emitting model assigned. This rule exists because the pair-agreement logic below would otherwise accept nothing in

--fast

mode, and an always-empty accepted_findings list silently produces a clean verdict on every run - the exact failure the panel-failure table forbids.

Full-panel compile:

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

Cross-topic deduplication (before bucketing): the same defect flagged by two topics (matching location and overlapping description) is one finding, kept at the highest severity assigned, annotated with both topics. Without this, one gap double-counts in the verdict and reads as two problems to fix.

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

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

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

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

Step 9 — Decision gate

步骤9 — 决策门

Alongside every human verdict, emit a fenced JSON block so downstream automation and the next skill can consume the gate result without parsing prose:

json

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

Iteration cap. Track the iteration count — first invocation = 1, each operator-requested re-run increments it. The cap is 3 iterations.

When

iteration_count >= 3

Do NOT offer "fix + re-run" again.
Present the current verdict with header:

"⛔ REVIEW EXHAUSTED — 3 iterations reached. Showing final findings."
The operator's only choices are:
- (a) Override and proceed — invoke next skill despite remaining blockers (log the override per the override-log rule below).
- (b) Abort — do not invoke the next skill; the artifact is not ready.

Do not loop indefinitely. After 3 rounds we have enough signal — keep chasing blockers only burns cycles and surfaces stylistic noise.

If BLOCKERS exist:

Present blockers clearly:

⛔ REVIEW BLOCKED — N blocker(s) must be addressed before proceeding.

BLOCKERS:
1. [title] (topic: X, confidence: Y)
   detail: ...
   location: ...

Ask the operator:

Two options:
  (a) Fix blockers in the artifact now, then I'll re-run the full review.
  (b) Override — acknowledge the blockers and proceed anyway (I'll note the override).

Do NOT auto-proceed. Wait for operator response.

If (a): after operator confirms fixes, re-run from Step 1 (full loop).
If (b): write the override record to stdout AND append a
```
git note
```
to the artifact's most-recent commit:
bash
```
git notes append -m "MULTI-AGENT-REVIEW OVERRIDE $(date -u +%Y-%m-%dT%H:%M:%SZ): operator acknowledged N blockers: [titles]" HEAD
```
Then invoke next skill. The git note is durable and co-located with the artifact's commit history.

If WARNINGS exist (no blockers):

⚠ REVIEW PASSED WITH WARNINGS — N warning(s).

WARNINGS:
1. [title] (topic: X)
   detail: ...
   location: ...

Fix warnings before proceeding, or accept and continue?

Wait for operator response.

Fix → re-run from Step 1 after operator confirms.
Continue → invoke next skill.

If clean (no blockers, no warnings):

✅ Review passed — N findings (0 blockers, 0 warnings, M observations).

If OBS > 0, list them below the pass line.

Auto-invoke next skill:

```
spec
```
mode → invoke
```
writing-plans
```
```
plan
```
mode → invoke
```
subagent-driven-development
```

在每个人工结论旁，输出一个带围栏的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
```

Panel failure semantics

评审小组故障语义

These rules govern what happens when the panel does not complete cleanly:

Failure	Behaviour
< 3 valid reports	HALT — abort, present to operator, do not produce verdict
3–5 valid reports	Add panel-health WARNING, continue with partial coverage
6 valid reports	Proceed normally
Juror error/timeout	Conservative fallback — promote all contested findings to BLOCKER, present as "JUROR FAILED"
All agents error	HALT — empty accepted_findings must never silently trigger clean verdict
`--fast` mode	Single tier, nothing is contested: every finding from a valid report is accepted at its emitted severity; quorum is 2 of 3; the verdict carries a note that no cross-model adjudication ran

Never allow an incomplete panel to produce a clean verdict. If any doubt, halt and present to operator.

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

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

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

Model assignments

模型分配

Model IDs are resolved at runtime from the active plugin manifest's

"models"

field. Default Claude Code values shown; Codex and other platforms override via their own plugin.json.

Tier variable	CC default	Codex default	Cursor default	Role
`FAST_TIER`	`haiku`	`gpt-5.6-luna`	`claude-haiku`	Fast reviewer (always used)
`STANDARD_TIER`	`sonnet`	`gpt-5.6-terra`	`claude-sonnet`	Standard reviewer (skipped with `--fast` )
`REASONING_TIER`	`opus`	`gpt-5.6-sol`	`claude-opus`	Juror (not overridable: adjudication on a weak model defeats its purpose)

A tier value prefixed

cli:

(e.g.

"standard": "cli:codex"

) dispatches that tier through the named external CLI per Step 5's cross-vendor rule. Prefer it where a second vendor's CLI is available.

模型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可用，优先选择此方式。

What this skill does NOT do

本skill不做的事情

Does not repair artifacts — surfaces findings only; the operator makes changes
Does not review code — that is
```
subagent-driven-development
```
's job
Defaults to the most recent spec or plan under
```
docs/superpowers/
```
; an explicit path argument overrides this

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

Companion files

关联文件

```
agents/completeness-reviewer.md
```
- placeholders, missing criteria, undefined refs
```
agents/alignment-reviewer.md
```
- mockup/codebase consistency, standing rules
```
agents/risk-reviewer.md
```
- production safety, fail-closed paths
```
agents/synthesis-agent.md
```
- juror prompt, only dispatched on contested findings

assets/project-rules.example.md

- template to copy into your project as

project-rules.md

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

assets/project-rules.example.md

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

project-rules.md