dual-verifier

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Dual Verifier

双重验证器（Dual Verifier）

Overview

概述

A post-implementation review skill that dispatches two independent subagents to verify a completed task. Both agents run the same verification checks without seeing each other's work. Their findings are then merged into one report — with each finding tagged by which agent(s) caught it.

Core principle: One agent can miss things, hallucinate, or rubber-stamp a summary. Two agents working independently catch more issues and — more importantly — when they disagree on a finding, that disagreement is itself a signal worth investigating.

This is NOT just running the same check twice. The value is independence: each agent must form its own picture of what was actually done by reading the code, the diff, and the test output — not by trusting any summary it was given.

这是一项实现后评审技能，会调度两个独立的子代理来验证已完成的任务。两个代理会执行相同的验证检查，且不会查看彼此的工作成果。随后它们的发现会被合并成一份报告——每个发现都会标记是由哪些代理发现的。

核心原则：单个代理可能会遗漏问题、产生幻觉或草率通过总结。两个独立工作的代理能发现更多问题，更重要的是，当它们对某个发现存在分歧时，这种分歧本身就是值得调查的信号。

**这不仅仅是重复运行相同的检查。**其价值在于独立性：每个代理都必须通过阅读代码、差异（diff）和测试输出来形成自己对实际完成工作的判断——而不是依赖任何给定的总结。

When to Use

适用场景

After an implementation task is complete and the user asks for verification
Before a commit, PR, or hand-off where over-claiming would cost
When a previous Claude session said "done" and the user is skeptical
When the user explicitly invokes a verification slash command

When NOT to use:

During active implementation (let it finish first)
For brainstorming or design reviews (use
```
brainstorm-reviewer
```
instead)
For style-only review with no functional claims (a single reviewer is sufficient)
When there is nothing concrete to verify against (no diff, no task statement)

实现任务完成后，用户要求进行验证时
在提交（commit）、拉取请求（PR）或工作交接前，此时过度宣称会造成损失的场景
之前的Claude会话称“已完成”，但用户持怀疑态度时
用户明确调用验证斜杠命令时

不适用场景：

实现过程中（需先完成任务）
头脑风暴或设计评审（请改用
```
brainstorm-reviewer
```
）
仅针对风格的评审，无功能宣称（单个评审者已足够）
没有具体内容可验证的情况（无差异、无任务说明）

Inputs the Skill Expects from the User

技能期望从用户处获取的输入

The user tells you, in conversation, what was implemented. You do not need them to fill in a form. Before dispatching, make sure you have:

What was the task? — one or two sentences on what was asked for.
What changed? — files touched, branch, or a diff range. If you don't know, get it (e.g.
```
git status
```
,
```
git diff
```
, recent edits in the conversation).
Where to look — repo path or working directory. Default to the current cwd if unspecified.
Any specific claims to challenge — e.g. "the previous agent said tests pass", "it said the form now validates X". Capture these so the subagents can pressure-test them.

If any of (1)-(3) is missing, ask one short question to fill the gap. Do not dispatch on a vague brief — both agents will then waste effort on different interpretations and their disagreement will be noise, not signal.

用户会在对话中告知你已实现的内容，无需填写表单。调度前，请确保你已获取：

任务内容是什么？——用一到两句话描述需求。
有哪些变更？——涉及的文件、分支或差异范围。如果不清楚，请获取相关信息（例如
```
git status
```
、
```
git diff
```
、对话中的最近编辑记录）。
查看位置——仓库路径或工作目录。若未指定，默认使用当前工作目录（cwd）。
需要验证的特定宣称——例如“之前的代理说测试已通过”“它说表单现在能验证X”。记录这些内容，以便子代理对其进行压力测试。

如果(1)-(3)中有任何一项缺失，请用简短的问题补充信息。不要基于模糊的说明调度代理——否则两个代理会因不同的理解而浪费精力，它们的分歧将是无效噪声而非有效信号。

Verification Flow

验证流程

dot

digraph verify {
    "Gather task brief" [shape=box];
    "Draft verifier prompt" [shape=box];
    "Dispatch Agent A and Agent B in parallel" [shape=box];
    "Receive both reports" [shape=box];
    "Merge findings" [shape=box];
    "Tag by agreement" [shape=box];
    "Produce combined report" [shape=doublecircle];

    "Gather task brief" -> "Draft verifier prompt";
    "Draft verifier prompt" -> "Dispatch Agent A and Agent B in parallel";
    "Dispatch Agent A and Agent B in parallel" -> "Receive both reports";
    "Receive both reports" -> "Merge findings";
    "Merge findings" -> "Tag by agreement";
    "Tag by agreement" -> "Produce combined report";
}

dot

digraph verify {
    "Gather task brief" [shape=box];
    "Draft verifier prompt" [shape=box];
    "Dispatch Agent A and Agent B in parallel" [shape=box];
    "Receive both reports" [shape=box];
    "Merge findings" [shape=box];
    "Tag by agreement" [shape=box];
    "Produce combined report" [shape=doublecircle];

    "Gather task brief" -> "Draft verifier prompt";
    "Draft verifier prompt" -> "Dispatch Agent A and Agent B in parallel";
    "Dispatch Agent A and Agent B in parallel" -> "Receive both reports";
    "Receive both reports" -> "Merge findings";
    "Merge findings" -> "Tag by agreement";
    "Tag by agreement" -> "Produce combined report";
}

Step 1: Draft the Verifier Prompt

步骤1：编写验证提示词

Both subagents receive the exact same prompt. This is what makes them independent verifiers of the same target rather than two specialists splitting work.

Use this template — fill in the bracketed parts from the task brief:

You are an independent verification agent. Another Claude has just completed
an implementation task and we need to confirm — independently — that the work
is actually correct. Do not trust any summary you receive. Read the code, the
diff, and the test output yourself.

两个子代理会收到完全相同的提示词。这确保它们是针对同一目标的独立验证者，而非分工协作的两个专家。

使用以下模板——根据任务说明填写括号中的内容：

You are an independent verification agent. Another Claude has just completed
an implementation task and we need to confirm — independently — that the work
is actually correct. Do not trust any summary you receive. Read the code, the
diff, and the test output yourself.

Task that was supposed to be done

[one or two sentences, verbatim from the user where possible]

Where the work lives

Repo / working directory: [path]
Files / branch / diff range: [list or
```
git diff <range>
```
]
Specific claims to pressure-test (if any): [list, or "none"]

Repo / working directory: [path]
Files / branch / diff range: [list or
```
git diff <range>
```
]
Specific claims to pressure-test (if any): [list, or "none"]

What to check

Go through each of these. For each, produce a finding with a status of PASS / FAIL / UNCLEAR and a one-sentence evidence line citing a file:line or a command output.

Requirements match. Does the code actually implement what was asked, or does it implement something adjacent? Read the diff, then re-read the task statement, and answer honestly.
Correctness. Trace the changed code paths. Are there obvious logic errors, off-by-ones, wrong operators, missing awaits, swapped arguments, wrong table/column names?
Side effects. Were files changed that have no business being in this task? Were files NOT changed that should have been (e.g. a migration was added but the model wasn't updated)?
Tests. Do tests exist for the new behavior? Did they actually run? Did they actually pass? Run them yourself if you can; do not trust the word "passed" without seeing the output.
Build / type check / lint. Does the project still build? Are there new type errors or lint failures introduced by this change?
Edge cases. What happens with null, empty, very large, very small, duplicate, or concurrent inputs? Pick the two most likely failure modes for this kind of change and check them.
Hidden assumptions. Are there claims in the implementation summary that the code does not actually back up? (E.g. "now handles X" but the X branch is empty.) List each unbacked claim.
Regression risk. Does the change touch anything that other features depend on? Spot-check the callers/consumers.

Go through each of these. For each, produce a finding with a status of PASS / FAIL / UNCLEAR and a one-sentence evidence line citing a file:line or a command output.

Requirements match. Does the code actually implement what was asked, or does it implement something adjacent? Read the diff, then re-read the task statement, and answer honestly.
Correctness. Trace the changed code paths. Are there obvious logic errors, off-by-ones, wrong operators, missing awaits, swapped arguments, wrong table/column names?
Side effects. Were files changed that have no business being in this task? Were files NOT changed that should have been (e.g. a migration was added but the model wasn't updated)?
Tests. Do tests exist for the new behavior? Did they actually run? Did they actually pass? Run them yourself if you can; do not trust the word "passed" without seeing the output.
Build / type check / lint. Does the project still build? Are there new type errors or lint failures introduced by this change?
Edge cases. What happens with null, empty, very large, very small, duplicate, or concurrent inputs? Pick the two most likely failure modes for this kind of change and check them.
Hidden assumptions. Are there claims in the implementation summary that the code does not actually back up? (E.g. "now handles X" but the X branch is empty.) List each unbacked claim.
Regression risk. Does the change touch anything that other features depend on? Spot-check the callers/consumers.

Output format

Return exactly this structure. Be terse. Cite evidence with file:line.

Summary

Findings

[SEVERITY] [CHECK#] <finding> — evidence: <file:line or command>
...

Severity is one of: BLOCKER, MAJOR, MINOR, NIT. A BLOCKER means do not ship. A MAJOR means fix before merge. MINOR/NIT are improvements.

[SEVERITY] [CHECK#] <finding> — evidence: <file:line or command>
...

Severity is one of: BLOCKER, MAJOR, MINOR, NIT. A BLOCKER means do not ship. A MAJOR means fix before merge. MINOR/NIT are improvements.

Claims pressure-tested

"<claim>" — VERIFIED / NOT VERIFIED / CONTRADICTED — <evidence>

"<claim>" — VERIFIED / NOT VERIFIED / CONTRADICTED — <evidence>

What I did not check


Save this prompt to a variable before dispatching so both agents receive byte-identical input.


调度前请将此提示词保存到变量中，确保两个代理收到完全一致的输入。

Step 2: Dispatch Both Agents in Parallel

步骤2：并行调度两个代理

Critical: Both subagents must be dispatched in the same turn — i.e. in one message containing two parallel tool calls. If you dispatch one, wait for it, then dispatch the other, the second one can be biased by your reaction to the first. Independence is the whole point.

Use whichever general-purpose subagent type your environment provides. The dispatch:

Agent A: subagent_type
```
general-purpose
```
(or equivalent), short description
```
Verifier A
```
, prompt = the verifier prompt verbatim.
Agent B: subagent_type
```
general-purpose
```
(or equivalent), short description
```
Verifier B
```
, prompt = the verifier prompt verbatim.

Do not tell either agent about the existence of the other. They should not be "checking each other" — they should each be independently checking the implementation.

While they run, do not start your own verification in the main thread. Wait for both, then synthesise. Doing your own pass risks anchoring on whichever finishes first.

关键：两个子代理必须在同一轮对话中调度——即在一条包含两个并行工具调用的消息中。如果先调度一个，等待其完成后再调度另一个，第二个代理会因你对第一个代理结果的反应而产生偏见。独立性是这项技能的核心价值。

使用你的环境提供的通用子代理类型。调度方式如下：

Agent A：subagent_type
```
general-purpose
```
（或等效类型），简短描述
```
Verifier A
```
，提示词为上述验证提示词原文。
Agent B：subagent_type
```
general-purpose
```
（或等效类型），简短描述
```
Verifier B
```
，提示词为上述验证提示词原文。

不要告知任何一个代理另一个的存在。它们不应“互相检查”——而应各自独立检查实现内容。

在它们运行时，不要在主线程中自行开始验证。等待两个代理完成后再进行综合分析。自行检查会导致你偏向先完成的那个代理的结果。

Step 3: Merge and Tag Findings

步骤3：合并并标记发现

When both reports arrive:

Normalize each finding to a short canonical form:
```
<check#> <thing> at <file:line>
```
. Strip prose differences so the same bug from both agents collapses to the same row.
Cluster findings that refer to the same underlying issue, even if the wording differs. Use file:line and the check number as the join key; fall back to semantic similarity.
Tag each cluster with which agent(s) raised it:
- BOTH — both agents independently flagged it. High confidence this is real.
- A only — Agent A flagged, Agent B did not. Worth investigating; could be a real issue Agent B missed, or a false positive from Agent A.
- B only — same as above, reversed.
Resolve severity disagreements. If Agent A said BLOCKER and Agent B said MINOR for the same item, take the higher severity for the merged row but note the disagreement in parentheses.
Pull out direct contradictions. If Agent A said a check PASSED and Agent B said the same check FAILED, that is a contradiction and goes in its own section — these are the most important things to surface.

当收到两份报告后：

标准化每个发现为简短的规范形式：
```
<check#> <问题描述> at <file:line>
```
。去除措辞差异，使两个代理发现的同一问题合并为同一行。
聚类指代同一潜在问题的发现，即使措辞不同。使用file:line和检查编号作为关联键；必要时基于语义相似度进行关联。
为每个聚类标记是由哪些代理提出的：
- BOTH——两个代理独立标记了该问题。此问题为真实存在的置信度高。
- A only——仅Agent A标记了该问题。值得调查；可能是Agent B遗漏的真实问题，也可能是Agent A的误报。
- B only——与上述情况相反。
解决严重性分歧。如果Agent A标记为BLOCKER而Agent B标记为MINOR，合并行采用较高的严重性，但在括号中注明分歧。
提取直接矛盾。如果Agent A称某检查PASS而Agent B称同一检查FAIL，这属于矛盾，需单独列为一个章节——这些是最需要突出的内容。

Step 4: Produce the Combined Report

步骤4：生成合并报告

Present this exact structure to the user:

undefined

向用户呈现以下准确结构：

undefined

Dual Verification Report

双重验证报告

Task: <one-line restatement> Verified against: <files / branch / diff range> Overall: PASS / FAIL / PARTIAL — <headline reason>

任务：<一句话重述> 验证对象：<文件/分支/差异范围> 整体结果： PASS / FAIL / PARTIAL — <核心原因>

Agreement summary

一致性摘要

Findings both agents agreed on: <N>
Findings only one agent raised: <N> (A: <n>, B: <n>)
Direct contradictions: <N>

两个代理一致的发现：<N>
仅单个代理提出的发现：<N>（A：<n>，B：<n>）
直接矛盾：<N>

Blockers and majors (merged, deduplicated)

阻塞项与主要问题（合并、去重）

Severity	Check	Finding	Evidence	Caught by
BLOCKER	1	...	file:line	BOTH
MAJOR	4	...	...	A only
...	...	...	...	...

严重性	检查项	发现	证据	发现者
BLOCKER	1	...	file:line	BOTH
MAJOR	4	...	...	A only
...	...	...	...	...

Contradictions (investigate these first)

矛盾项（优先调查）

For each: what A said, what B said, why they might disagree, what to look at to resolve.

针对每个矛盾项：A的结论、B的结论、可能的分歧原因、需查看的内容。

Minors and nits

次要问题与细枝末节

<简短列表，可简洁表述>

Claims pressure-tested

验证的宣称

Claim	A	B	Combined verdict
"tests pass"	VERIFIED	NOT VERIFIED	NOT VERIFIED — see contradiction #1

宣称	A的结论	B的结论	合并 verdict
"tests pass"	VERIFIED	NOT VERIFIED	NOT VERIFIED — 见矛盾项#1

What was not checked

未检查内容

<两个代理“未检查”列表的并集>

Recommended next actions

建议后续行动


The "Caught by" column is the heart of the report. A row tagged BOTH is high-confidence. A row tagged "A only" or "B only" tells the user where to look more carefully — either the issue is real and one agent missed it, or one agent hallucinated and that's worth knowing too.

<简短可执行列表——修复此问题、重新运行该测试、询问用户此内容>


“发现者”列是报告的核心。标记为BOTH的行置信度高。标记为“A only”或“B only”的行提示用户需更仔细地查看——要么是其中一个代理遗漏了真实问题，要么是其中一个代理产生了幻觉，这一点同样值得了解。

Interpreting the Result

结果解读

Help the user read the report:

All findings BOTH, all severities low → very likely fine to proceed.
BOTH agents flag BLOCKER on the same item → do not ship; fix first.
A-only or B-only finding marked BLOCKER → resolve before trusting. Open the file and look yourself. Do not dismiss it just because the other agent missed it.
Any contradiction → that is the single most important thing on the page. Two competent independent observers disagreed; one of them is wrong, and you do not yet know which. Resolve before claiming the task is done.

帮助用户理解报告：

所有发现均为BOTH，且严重性较低→大概率可以继续推进。
两个代理均标记同一项为BLOCKER→不要发布；先修复。
仅A或仅B标记某一项为BLOCKER→在信任结果前需解决此问题。打开文件自行查看。不要仅因另一个代理未发现就忽略它。
存在任何矛盾→这是报告中最重要的内容。两个有能力的独立观察者存在分歧；其中一方是错误的，而你尚未知晓哪一方。解决矛盾后再宣称任务完成。

Common Pitfalls

常见陷阱

Pitfall	Why it kills the value	What to do instead
Dispatching the two agents sequentially	The second one anchors on the first's framing through you	Always dispatch in parallel, in the same turn
Giving them different prompts	They become specialists, not cross-checkers	Byte-identical prompts. If you want specialists, that's a different skill
Letting an agent trust the summary	It becomes a stenographer, not a verifier	The prompt explicitly tells each agent to read the code, not the summary
Skipping the "claims pressure-tested" section	Over-claiming goes uncaught	Always pull out specific claims from the original implementer and force them to be verified
Hiding the agreement tag in the report	User loses the main signal	"Caught by" column must be visible; contradictions get their own section
Treating "A only" as automatically wrong	Misses real issues one agent caught	Treat asymmetric findings as "investigate", not "dismiss"

陷阱	为何会损害价值	正确做法
顺序调度两个代理	第二个代理会通过你受到第一个代理框架的影响	始终在同一轮对话中并行调度
给它们不同的提示词	它们会变成专家，而非交叉检查者	使用完全一致的提示词。如果需要专家，请使用其他技能
让代理信任总结内容	它会变成记录员，而非验证者	提示词明确告知每个代理需自行阅读代码，而非依赖总结
跳过“验证的宣称”部分	过度宣称无法被发现	始终提取原实现者的特定宣称，并强制对其进行验证
在报告中隐藏一致性标记	用户会失去核心信号	“发现者”列必须可见；矛盾项单独列为章节
自动认为“A only”的发现是错误的	会遗漏单个代理发现的真实问题	将不对称发现视为“需调查”，而非“可忽略”

Notes on Independence

独立性说明

Real independence is hard. These help:

Same prompt, same time, no shared context. Done above.
No leaks from your own reasoning. Do not put your own assessment of the task in the prompt. State only the task brief and the location of the work.
Do not name the implementer or quote their summary in tone-laden language. "The implementer claims X" is fine; "The implementer says they fixed X and I think they did" is not.
If both agents return suspiciously identical reports, that is a yellow flag — they may have anchored on the same obvious thing and missed everything else. Re-read the diff yourself and consider re-dispatching with a sharper brief.

真正的独立性很难实现。以下方法有助于确保独立性：

**相同提示词、同一时间、无共享上下文。**如上述步骤所示。
**避免你的推理泄露。**不要在提示词中加入你对任务的评估。仅陈述任务说明和工作位置。
不要提及实现者或用带有语气的语言引用其总结。“实现者宣称X”是可以的；“实现者说他们修复了X，我认为他们做到了”则不行。
如果两个代理返回的报告异常相似——这是一个黄色警告信号——它们可能都聚焦于同一个明显问题，而遗漏了其他所有内容。请自行重新阅读差异，并考虑使用更明确的说明重新调度代理。