使用另一个模型以最多三轮的方式审查代码变更：审查者阅读变更，破坏者尝试通过测试来打破它。始终保持每项修复尽可能小以解决其发现，并在发现错误时用证据反驳。
1. 简报审查者和破坏者
审查者和破坏者是最新的模型，位于orchestrator_capabilities中，属于用户命名的系列（sol、opus等），以他们指定的投入程度运行；不设置其他模型选项。仅提供者名称（gpt、claude）不代表系列。如果系列或投入程度缺失，请询问，并在他们回答前不执行任何其他操作。
锁定基线：使用调用者传入的基线，否则使用 git merge-base HEAD <remote>/<default-branch>，其中远程仓库是变更合并到的仓库（在分支上为 upstream），或当变更仅未提交时使用 HEAD。运行覆盖该变更的检查，通过仓库的 verify 技能（如果存在，在 .agents/skills/verify/ 下），并在第一轮之前修复任何失败的检查。记录它们运行时的修订版本，包括未提交的变更。
每一轮都以全新的 delegate_task 开始。反驳和后续轮次应放在新的简报中，绝不要在已完成的审查者的后续消息中。超时或错误不代表批准：重新启动失败的代理一次。
当差异仅涉及注释、文档或格式时，不运行循环，并在最终消息中说明。在第一轮中，并行启动审查者和破坏者，破坏者使用 isolation: "worktree"。当差异不改变任何可运行代码时，跳过破坏者。在轻量运行中（传入层级 see-it-through），第一轮不启动破坏者；一旦审查者回复，启动一个破坏者，其范围仅限定在其“Not verified”行中测试可以解决的条件（如果有的话）。
两个简报都以这个头部开始：
仓库：<绝对路径> 基线：<sha> 范围外：<scope>
标准：<仓库的规则文件，例如 AGENTS.md 或 CONTRIBUTING.md；或 无>
设置：<每个 shell 必须首先运行的内容，例如固定的工具链脚本，以及全新检出所需的内容，例如安装；或 无>
检查：<结果> 正在运行：<仍在进行中的检查；或 无>
请求：<用户的请求或简报，逐字照录，或其绝对路径>
方法：<已批准的方法，或其绝对路径；或 无>。其声明是作者的：检查变更所依赖的声明。
验收：<包含在变更前编写的验收检查的提交或补丁；或 无>
差异：git diff <base>；同时读取 git status --short 中的未跟踪文件。
条件：在读取差异之前，根据请求编写验收条件：用户在成功、失败、取消和重试时应该看到或得到什么；在部分失败后（内存、磁盘和屏幕上留下的内容）；在重复操作或较早尝试在新操作之后完成时；当 await 在用户离开后返回时；在显示结果的每个界面上，包括缓存数据；以及变更可能留下的每个状态都有退出的方法。仅在变更代码到达该情况时编写：在预期路径上，通过变更代码的其他每个调用者，以及通过变更现在信任的状态的其他每个写入者（搜索两者）。
审查者简报，在头部之后：
仅审查：阅读和追踪。不要编辑、提交、推送、评论、启动子代理，或编写或运行测试或构建。
按照“条件”所述编写验收条件，然后说明你如何在“方法”内进行变更。以两者逐字照录开始你的最终回复；VERDICT 行紧随其后。
发现变更的问题，追踪每个条件通过代码直到用户看到或得到的内容。你的方法只有在它满足差异未满足的条件，或用更少的代码满足所有条件时才构成发现。
对于你发现的每个错误，命名其类别并在差异的其余部分及其调用者中寻找相同的错误，包括变更处理方式不同的兄弟情况；按类别报告一个发现，列出每个位置。
对照标准文件检查变更；将这些发现标记为 [标准]，并跳过 lint 和类型检查强制执行的内容。
将不需要任何条件的代码或防护、仓库或平台已经提供的新代码、以及违背标准或周围代码约定的代码标记为 nit（吹毛求疵）；不要仅仅是你偏好的风格。
检查变更是否引入了竞争性的状态所有权、在两个地方做出的决策、调用者必须记住的义务、或调用者可以绕过的边界；将这些标记为 [结构]，命名代码及其后果，并按以下定义分级。没有这种后果的不同设计是 nit；更大的重新设计只有在最小修正无法修复时才构成发现。
对验收中检查的编辑，如果使其无法证明其所承诺的内容，则视为 should。
blocker = 预期情况是错误的。should = 此变更导致的问题，可以通过受支持的操作或输入到达：用户操作、磁盘上的文件、I/O 故障、用户创建的文件，通过运行它或通过代码追踪显示，包括未触及的调用者。变更添加的测试，如果可以在没有其所证明的行为的情况下通过，则视为 should。
nit = 风格、微小性能、润色。pre-existing = 在基线上发生同样的失败，通过测试或追踪显示，并且变更既没有使其更容易到达，也没有与其声明相矛盾。
VERDICT: APPROVE 或 CHANGES，然后每个发现一行：
S1 [blocker|should|nit|pre-existing] <文件>:<行> <声明>. 修复：<最小修复>
然后 Checked: 每个条件一行：<文件>:<行> 以及该行建立的内容。
然后 Not verified: 你无法确认的内容及其原因；或 无。
破坏者简报，在头部之后：
破坏此变更。不要提交、推送、评论或启动子代理。
仅在你自己的检出目录中工作，即你启动时的工作目录，它是 <repo> 的 HEAD 的副本。首先将变更的未提交部分引入：git -C <repo> diff HEAD | git apply，然后复制 git -C <repo> status --short 列出的未跟踪文件。绝不要更改 <repo> 中的文件或用户的配置，并且不运行任何推送、发布或通知的内容；包管理器缓存是可以的。跳过 E2E 运行和“正在运行”中列出的任何内容；仅编译测试所需的内容。
按照“条件”所述编写验收条件。对于每个条件，编写并运行最小的测试，如果条件被破坏，该测试将失败，断言用户看到或得到的内容。
对于变更添加的 E2E 级别以下的每个证明测试，撤销它应该捕获的防护，或破坏其前置条件，运行它，然后恢复代码。
COULDN'T TEST 仅适用于此级别无法达到的条件，例如需要 E2E 的条件。慢队列或你自己损坏的设置不属于此类：将你的测试批量化为一个作业，等待它而不取消，并修复你的设置。
在回复之前，将你通过的、覆盖了现有测试未覆盖的条件的测试补丁写入 <keep path>，并删除你添加的其他所有内容。
回复，每个条件一行：B1 HELD <条件> — <命令>；B2 BROKE <条件> — <命令> 和失败输出；或 B3 COULDN'T TEST <条件> — 原因。然后每个证明测试一行：P1 FAILS <测试> 在 <防护> 撤销后；或 P2 STILL PASSES <测试> 在 <防护> 撤销后。然后：Kept: <keep path> 以及每个测试覆盖的条件；或 无。
选择 <keep path>：两个检出目录之外的绝对路径。
2. 处理发现
根据审查者简报中的定义自行对每个发现进行分级，无论其带有什么标签。将每个 BROKE 和 STILL PASSES 行视为一个发现。
- 同意：首先重现它，使用一个在实际可行时会对当前代码失败的测试，否则直接重现（命令和输出）并注明其限制；检查关于事实的声明，例如 CI 运行什么或基线是什么，需要对照其来源。然后搜索变更代码的兄弟情况和调用者以查找更多该类发现，并对变更引入或暴露的每个实例应用最小修复；将无关的预先存在的发现列为后续跟进。显示测试通过（对于 STILL PASSES 发现，修复后的测试在防护撤销时失败），并保留测试。优先删除或缩小代码，而不是添加新的锁、缓存、辅助函数或选项。
- 不同意：说明原因，并附上证据（测试或命令输出）。仅从代码中读取的理由，例如“那不可能发生”，会使发现处于争议状态，而不是被丢弃或降级。
- Nit：对于差异添加、更改或移动的代码，当它的修复删除了代码、重用了仓库或平台提供的内容、或使代码符合标准或周围代码时采用它，保持所有检查通过，并且不以清晰性为代价换取长度。在一行中拒绝增加路径、情况、选项或兼容性层的 nit，其修复会改变用户看到或得到的内容的 nit，以及仅仅是品味的 nit。
- Pre-existing 或 out of scope：在一行中拒绝。
将每个测试提交到破坏者的补丁中，或命名覆盖其条件的现有测试。
绝不为了结束循环而同意。重新运行检查和 git diff --shortstat <base>；删除审查添加的、没有接受的发现需要的测试之外的内容，保持最小的正确修复，即使它增加了代码量。
3. 下一轮
仅在 blocker 或 should 未解决，或行为代码发生更改时启动下一轮。发送头部，其“条件”行替换为第 1 轮审查者的条件，审查者简报不带其条件和方法行，每个先前的 id 标记为已修复、有争议（附上证据）或已拒绝（附上理由），以及自上一轮以来更改的块。告诉审查者仅审查未解决的 id 和那些块，为行为更改的那些块及其调用者编写新条件，将每个先前的 id 标记为已解决或仍处于未解决状态，并在最后一个 id 之后对新发现进行编号。当修复更改了行为、顺序或所有权（例如将写操作移到 await 之后）时，也使用相同的头部启动一个破坏者，告诉它仅编写和测试那些块及其调用者的条件。
4. 完成
当没有 blocker 或 should 未解决，并且测试、注释和格式之外的最后一次更改已经经过一轮时完成；APPROVE 会在其审查的代码上提前结束循环。在可以修复原因的 COULDN'T TEST 上发送一个新的破坏者；列出需要 E2E 的原因供作者处理。如果 blocker 或 should 在第 3 轮后仍有争议，请运行 dispute-round.md 中的争议轮；它留下 INCONCLUSIVE 的发现将以未解决争议（而非已批准）的方式结束循环。已拒绝的 nit 和预先存在的发现保持拒绝状态。
最终消息：运行的轮次、模型、发现更改了什么、每个标记的行为、测试、声明或润色、差异前后大小、任何因为测试或输出显示其错误而被丢弃的发现，以及每个被拒绝的 nit 或预先存在的发现及其原因。添加破坏者测试了什么、什么被破坏、其中审查者也发现了哪些、以及每个没有测试覆盖的条件。如果进行了争议轮，给出每个结果。用简单语言列出每个未确认的风险。如果 evals/results.jsonl 存在且审查者模型与其中的最后一个不同，请说明并提供回归套件运行的选项 (evals/README.md).