Cross-Model Peer Review 是一套用于跨模型同行评审的协议，其规范文本位于 ${CLAUDE_PLUGIN_ROOT}/skills/cross-model-peer-review/references/PROTOCOL.md，本插件是该协议在 Claude Code 中的实现。协议本身与具体 harness 和 provider 无关，其需求编号是稳定标识符，本技能及插件中的每个 agent 都按编号引用，而非松散复述。
用途
该协议用于把一份计划、一份规格，或某次会话自身的决策，提交给第二个模型家族进行评审。它关注的是：何时值得付出这种成本，以及如何让评审过程保持诚实。
核心原则
协议由两条原则统辖，均引自 PROTOCOL.md 的 Doctrine 部分与 R14。
第一，跨家族独立性是此工作流中实际可得的较强模型级独立性，但不是绝对独立性。两个前沿参与者可能共享训练语料、约定和推理模式。第二个参与者之所以值得其成本，是因为它的错误足够去相关，而不是因为它是洁净室观察者。
第二，第二个模型不是神谕，不是洁净室，也不能免于锚定风险——它可能已经读过第一个模型在精神上写出的同一份数据包。它值得运行，是因为它的错误不太可能是相同的错误，而不是因为它在任何绝对意义上独立。运行它是为了去相关，不是为了纯粹。
来源规则
在一个参与者的贡献内，重复一个 GIVEN 事实不能佐证任何东西。规则针对的是行为，不是事实：一个参与者如果独立到达权威来源并在那里验证了该事实，它就派生了该事实，账本会记录 GIVEN -> DERIVED 的升级，并附上派生角色和定位符，此后它才计数。通过回读数据包产生的一致永远不计数。
事实以三种身份进入一次运行：GIVEN（由数据包提供）、TO JUDGE（提交评估，最典型的是经过考虑后被拒绝的理由）、DERIVED（由参与者自己访问权威来源而确立，最典型的是 R8 下受访者的仓库访问）。一个 GIVEN 事实保持 GIVEN，无论在一个贡献内被重复多少次，直到某个参与者到达来源本身，且账本记录升级并附上派生角色和定位符。回读数据包并称之为验证，是一次运行的证据看起来比实际更强的常见方式。
六条加固规则
每条规则针对双参与者辩论退化为表演的一种具体方式。
锚定于数据包构建者的框架：拒绝理由以 TO JUDGE 而非 GIVEN 进入数据包，因此挑战者对其负有审视义务而非遵从；第一轮挑战以框架挑战开场（任务是否是正确的问题，分解是否自然），然后才提出发现。对应 R3、R6。
策略性数据包遗漏：地面真相和约束通过机械提取构建——在工件中命名一个来源才使它获得位置，绝不是由数据包构建者做相关性判断。数据包构建者还必须至少命名自己工件的三个真实弱点。挑战者可以请求更多上下文，每次拒绝都被记录并在裁决中呈现，而不是被静默丢弃。对应 R3、R6。
虚假证伪：每个证伪在调查开始前都要检查可受理性、能否对来源判定、能否在有界努力内判定、是否真正具有决定性。一个在单次重述请求后仍失败的证伪，以 UNTESTABLE 终止，而不是被强行推向 ACCEPT 或 REFUTE。对应 R9。
辩论洗白：一个发现的声明和证伪在整个账本中逐字传递；挑战者在裁决前认证自己发现的拟议终态，并可以通过引用自己的原始措辞来标记受访者表述中的歪曲；裁决本身从账本计算，散文只能解释状态，永远不能指派状态。对应 R10、R12、R13。
过早收敛：反驳需要稳定定位符处的正面证据，绝不能用证据缺失来代替；一个未命名任何证伪证据的撤回不关闭其发现，且无论结果如何都报告为运行弱点；有发现的运行永远不能在首轮后终止，饱和是机械的同一主张、同一证据、同一立场测试，绝不是因为轮次拖长而走的捷径。对应 R7、R11。
传输保真：数据包记录工件的字节长度和内容摘要，裁决在任何发现被信任之前验证来源、数据包嵌入和传出请求字节一致。三者中的最后一项不是先复现再检查，而是从存储的数据包发送，因为被要求重新输入 48 KB 的参与者会转而总结它，而下游无法看到它这样做了；传输报告它实际发送内容的摘要。一个攻击来源中确实不存在的材料的发现，以 TRANSMISSION_ARTIFACT 终止，运行被重复，而不是对该发现进行实质评判。对应 R15。
何时不应运行评审
一次运行的成本是向外部服务传输真实字节，以及数轮模型时间。三种情况不值得付出这种成本。
工件过于模糊，无法攻击。从模糊计划构建的数据包产生的地面真相没有任何被钉住的东西，发现也悬在空中；挑战者最终辩论的是工件可能意味着什么，而不是它是否站得住。先把计划或规格锐化为可判定的主张，再运行评审。在简要模式下，这是主要风险而非边缘情况，因为简要内容是起草的而非手写的：brief-builder 的可判定性自检是捕捉它的机制，其“无法锐化”列表使软性可见，当简要中没有任何内容通过时命令直接停止。
决策理由无法写下。协议评判工件，永远不评判其作者（R1），它无法权衡工件中缺失的约束。来自所有文档之外的理由（预算、日期、某人的决定）并不取消一次运行：把它写进 Constraints 部分，在那里它成为 GIVEN 且可评判，这正是简要模式 Constraints 部分存在的意义。取消一次运行的是完全无法陈述的理由，因为那样挑战者攻击的是一份不代表该决策的文档。
目标是 diff。本插件评审意图工件，不评审代码变更；命令本身拒绝任何看起来像统一 diff 或源文件的东西。senior-review 负责 diff 和 PR 评审。
与 senior-review 的关系
senior-review:review-quality-gates 陈述了本技能原则所陈述的同一规则，只是高一层：从共享上下文工件派生的证据不能独立佐证包含在同一工件中的主张，因此 N 个评审者同意一个他们都被给予的前提，是一个观察，不是 N 个。该规则防止共享上下文在一个评审管道内跨评审者坍缩独立性。上述 R14 防止在一次辩论的两个参与者之间发生相同的坍缩。相同的失败模式，不同的重数；两个插件都不依赖对方来执行它。