<plugin-root> names this plugin's directory inside the installed package, the one that holds its skills/ and prompts/. Resolve it once from where this file was loaded, then substitute it into every path below that starts with it.
Cross-Model Peer Review
The protocol is the product, this plugin is its Claude Code implementation. The
normative text is <plugin-root>/skills/cross-model-peer-review/references/PROTOCOL.md: harness-independent,
provider-independent, its requirement numbers stable identifiers that this skill and
every agent in this plugin cite by number rather than restate loosely. Read it before
touching a run that behaves unexpectedly; this skill explains why the rules exist and
when to reach for the command at all, not what each phase does mechanically.
The doctrine
Two statements govern everything else in the protocol. Both are quoted verbatim from
PROTOCOL.md's Doctrine section and R14.
Cross-family independence is the strongest practical model-level independence
available in this workflow, not absolute independence. Two frontier participants may
share a training corpus, conventions, and reasoning patterns. What makes a second
participant worth its cost is that its errors are sufficiently decorrelated, not that
it is a clean-room observer.
A second model is not oracle, not a clean room, and not free of the anchoring risk of
having read the same packet the first model wrote in spirit. It is worth running
because its errors are unlikely to be the same errors, not because it is independent
in any absolute sense. Run it for decorrelation, not for purity.
Within a participant's contribution, repeating a GIVEN fact corroborates nothing. The
rule is about the act, not the fact: a participant that independently reaches the
authoritative source and verifies the fact there has derived it, and the ledger
records the promotion GIVEN -> DERIVED with the deriving role and locator, after which
it counts. Agreement produced by reading the packet back never counts.
This is the provenance rule that keeps the ledger honest. A fact enters a run as
GIVEN (supplied by the packet), TO JUDGE (submitted for evaluation, most
notably a considered-and-rejected rationale), or DERIVED (established by a
participant's own access to the authoritative source, most notably the respondent's
repository access under R8). A GIVEN fact stays GIVEN, however many times it is
repeated inside one contribution, until a participant reaches the source itself and
the ledger records the promotion with the deriving role and a locator. Reading the
packet back and calling it verification is the single most common way a run's evidence
looks stronger than it is.
The six hardening rules
Each rule targets one specific way a two-participant debate degrades into theater.
| Failure mode |
What protects against it |
Requirement |
| Anchoring on the packet builder's framing |
A rejection rationale enters the packet flagged TO JUDGE, never GIVEN, so the challenger owes it scrutiny instead of deference; the first challenge round opens with a frame challenge (is the mandate the right question, is the decomposition natural) before a single finding is raised |
R3, R6 |
| Strategic packet omission |
Ground truth and constraints are built by mechanical extraction: naming a source in the artifact is what earns it a place, never a relevance judgment made by the packet builder. The packet builder must also name at least three genuine weaknesses of its own artifact. The challenger can request more context, and every refusal is recorded and surfaced in the verdict rather than silently dropped |
R3, R6 |
| False falsifiers |
Every falsifier is checked for admissibility, decidable against the source, decidable in bounded effort, actually dispositive, before any investigation starts. One that still fails after a single restatement request terminates UNTESTABLE rather than being forced toward ACCEPT or REFUTE either way |
R9 |
| Debate laundering |
A finding's claim and falsifier travel verbatim through the whole ledger; the challenger certifies the proposed terminal state of its own findings before the verdict and can flag a misrepresentation by quoting its own original words against the respondent's rendering; the verdict itself is computed from the ledger and prose may only explain a state, never assign one |
R10, R12, R13 |
| Premature convergence |
A refutation requires positive evidence at a stable locator, never absence of evidence standing in for one; a withdrawal that names no falsifying evidence does not close its finding and is reported as a run weakness regardless of outcome; a run with findings can never terminate after round one, and saturation is a mechanical same-claim-same-evidence-same-position test, never a shortcut taken because the round is running long |
R7, R11 |
| Transmission fidelity |
The packet records the artifact's byte length and content digest, and the verdict verifies source, packet embedding, and outgoing request are byte-identical before any finding is trusted. The last of those three is not reproduced and then checked, it is sent from the stored packet, because a participant asked to retype 48 KB summarizes it instead and nothing downstream can see that it did; the transport reports the digest of what it actually sent. A finding attacking material genuinely absent from the source terminates TRANSMISSION_ARTIFACT and the run is repeated rather than the finding being judged on its merits |
R15 |
When not to run a review
A run costs a transmission of real bytes to an external service and several rounds of
model time. Three situations do not earn that cost:
- The artifact is too vague to attack. A packet built from a vague plan produces
ground truth with nothing pinned down and findings that stand on air; the challenger
ends up debating what the artifact might mean instead of whether it holds up.
Sharpen the plan or spec into decidable claims first, then run the review. In brief
mode this is the dominant risk rather than an edge case, because the brief is drafted
rather than written by hand:
brief-builder's decidability self-check is what catches
it, its "could not be sharpened" list is what makes the softness visible, and the
command stops outright when nothing in the brief passes.
- The reason for the decision cannot be written down. The protocol judges the
artifact, never its author (R1), and it has no way to weigh a constraint that is
absent from the artifact. A reason that came from outside every document (a budget, a
date, someone's call) does not disqualify a run: write it into the Constraints
section, where it becomes GIVEN and judgeable, which is what brief mode's Constraints
section exists for. What disqualifies a run is a reason that cannot be stated at all,
because then the challenger attacks a document that does not represent the decision.
- The target is a diff. This plugin reviews intent artifacts, not code changes; the
command itself refuses anything that looks like a unified diff or a source file.
senior-review owns diff and PR review.
Relationship to senior-review
senior-review:review-quality-gates states the same rule this skill's doctrine states,
one level up: evidence derived from a shared context artifact cannot independently
corroborate a claim contained in that same artifact, so N reviewers agreeing on a
premise they were all given is one observation, not N. That rule guards against shared
context collapsing independence across reviewers inside one review pipeline. R14
above guards against the identical collapse across the two participants of one
debate. Same failure mode, different multiplicity; neither plugin depends on the
other to enforce it.
1---2name: cross-model-peer-review-23description: Doctrine for putting a plan, a spec, or a session's own decisions in front of a second model family: when the cost is earned, the GIVEN versus DERIVED provenance rules, when to skip it. TRIGGER WHEN: running or configuring /peer-review:review, deciding whether an artifact warrants external challenge, or interpreting a verdict's standoffs and promotions. DO NOT TRIGGER WHEN: reviewing code diffs (use senior-review), or running same-family multi-reviewer pipelines (use senior-review:review-quality-gates).4---56> `<plugin-root>` names this plugin's directory inside the installed package, the one that holds its `skills/` and `prompts/`. Resolve it once from where this file was loaded, then substitute it into every path below that starts with it.78# Cross-Model Peer Review910The protocol is the product, this plugin is its Claude Code implementation. The11normative text is `<plugin-root>/skills/cross-model-peer-review/references/PROTOCOL.md`: harness-independent,12provider-independent, its requirement numbers stable identifiers that this skill and13every agent in this plugin cite by number rather than restate loosely. Read it before14touching a run that behaves unexpectedly; this skill explains why the rules exist and15when to reach for the command at all, not what each phase does mechanically.1617## The doctrine1819Two statements govern everything else in the protocol. Both are quoted verbatim from20`PROTOCOL.md`'s Doctrine section and R14.2122> Cross-family independence is the strongest practical model-level independence23> available in this workflow, not absolute independence. Two frontier participants may24> share a training corpus, conventions, and reasoning patterns. What makes a second25> participant worth its cost is that its errors are sufficiently decorrelated, not that26> it is a clean-room observer.2728A second model is not oracle, not a clean room, and not free of the anchoring risk of29having read the same packet the first model wrote in spirit. It is worth running30because its errors are unlikely to be the same errors, not because it is independent31in any absolute sense. Run it for decorrelation, not for purity.3233> Within a participant's contribution, repeating a GIVEN fact corroborates nothing. The34> rule is about the act, not the fact: a participant that independently reaches the35> authoritative source and verifies the fact there has derived it, and the ledger36> records the promotion GIVEN -> DERIVED with the deriving role and locator, after which37> it counts. Agreement produced by reading the packet back never counts.3839This is the provenance rule that keeps the ledger honest. A fact enters a run as40**GIVEN** (supplied by the packet), **TO JUDGE** (submitted for evaluation, most41notably a considered-and-rejected rationale), or **DERIVED** (established by a42participant's own access to the authoritative source, most notably the respondent's43repository access under R8). A GIVEN fact stays GIVEN, however many times it is44repeated inside one contribution, until a participant reaches the source itself and45the ledger records the promotion with the deriving role and a locator. Reading the46packet back and calling it verification is the single most common way a run's evidence47looks stronger than it is.4849## The six hardening rules5051Each rule targets one specific way a two-participant debate degrades into theater.5253| Failure mode | What protects against it | Requirement |54|---|---|---|55| Anchoring on the packet builder's framing | A rejection rationale enters the packet flagged TO JUDGE, never GIVEN, so the challenger owes it scrutiny instead of deference; the first challenge round opens with a frame challenge (is the mandate the right question, is the decomposition natural) before a single finding is raised | R3, R6 |56| Strategic packet omission | Ground truth and constraints are built by mechanical extraction: naming a source in the artifact is what earns it a place, never a relevance judgment made by the packet builder. The packet builder must also name at least three genuine weaknesses of its own artifact. The challenger can request more context, and every refusal is recorded and surfaced in the verdict rather than silently dropped | R3, R6 |57| False falsifiers | Every falsifier is checked for admissibility, decidable against the source, decidable in bounded effort, actually dispositive, before any investigation starts. One that still fails after a single restatement request terminates UNTESTABLE rather than being forced toward ACCEPT or REFUTE either way | R9 |58| Debate laundering | A finding's claim and falsifier travel verbatim through the whole ledger; the challenger certifies the proposed terminal state of its own findings before the verdict and can flag a misrepresentation by quoting its own original words against the respondent's rendering; the verdict itself is computed from the ledger and prose may only explain a state, never assign one | R10, R12, R13 |59| Premature convergence | A refutation requires positive evidence at a stable locator, never absence of evidence standing in for one; a withdrawal that names no falsifying evidence does not close its finding and is reported as a run weakness regardless of outcome; a run with findings can never terminate after round one, and saturation is a mechanical same-claim-same-evidence-same-position test, never a shortcut taken because the round is running long | R7, R11 |60| Transmission fidelity | The packet records the artifact's byte length and content digest, and the verdict verifies source, packet embedding, and outgoing request are byte-identical before any finding is trusted. The last of those three is not reproduced and then checked, it is sent from the stored packet, because a participant asked to retype 48 KB summarizes it instead and nothing downstream can see that it did; the transport reports the digest of what it actually sent. A finding attacking material genuinely absent from the source terminates TRANSMISSION_ARTIFACT and the run is repeated rather than the finding being judged on its merits | R15 |6162## When not to run a review6364A run costs a transmission of real bytes to an external service and several rounds of65model time. Three situations do not earn that cost:6667- **The artifact is too vague to attack.** A packet built from a vague plan produces68 ground truth with nothing pinned down and findings that stand on air; the challenger69 ends up debating what the artifact might mean instead of whether it holds up.70 Sharpen the plan or spec into decidable claims first, then run the review. In brief71 mode this is the dominant risk rather than an edge case, because the brief is drafted72 rather than written by hand: `brief-builder`'s decidability self-check is what catches73 it, its "could not be sharpened" list is what makes the softness visible, and the74 command stops outright when nothing in the brief passes.75- **The reason for the decision cannot be written down.** The protocol judges the76 artifact, never its author (R1), and it has no way to weigh a constraint that is77 absent from the artifact. A reason that came from outside every document (a budget, a78 date, someone's call) does not disqualify a run: write it into the Constraints79 section, where it becomes GIVEN and judgeable, which is what brief mode's Constraints80 section exists for. What disqualifies a run is a reason that cannot be stated at all,81 because then the challenger attacks a document that does not represent the decision.82- **The target is a diff.** This plugin reviews intent artifacts, not code changes; the83 command itself refuses anything that looks like a unified diff or a source file.84 `senior-review` owns diff and PR review.8586## Relationship to senior-review8788`senior-review:review-quality-gates` states the same rule this skill's doctrine states,89one level up: evidence derived from a shared context artifact cannot independently90corroborate a claim contained in that same artifact, so N reviewers agreeing on a91premise they were all given is one observation, not N. That rule guards against shared92context collapsing independence **across reviewers** inside one review pipeline. R1493above guards against the identical collapse **across the two participants of one94debate**. Same failure mode, different multiplicity; neither plugin depends on the95other to enforce it.
acaprino