Cross-check

Get a second opinion on a document from a model that did not write it, settle every disagreement on the evidence, and apply only what survives.

Classification: Degraded — the reviewer has two rungs. Strongest is a different model, launched through diff-review's bundled review_runner.py; next is a fresh reviewer in the same runtime. There is no third rung: an in-context reset is what cyw already did in Step 1, so where neither reviewer can be reached the skill reports that and stops rather than present a self-review as a second opinion.

Progress: observable — rung 1's reviewer streams into the supervisor's append-only display log while it runs; rung 2 returns in one shot.

Step 1 — Anchor and self-check

1. Name the target files. With no argument, use the document this conversation just produced; if that is ambiguous, ask (autonomously: the most recently modified document the conversation touched, and say so). Name too any context documents the caller names — a master plan behind its phase documents. Never edit a context document.
2. Write one sentence saying what the document is for and who acts on it. A reviewer without it judges the wrong thing.
3. If a cyw pass ran on these files earlier in this conversation and none of them has changed since, skip this pass and say so. Otherwise run the cyw skill in single-pass mode on the target. If cyw isn't installed or doesn't run, re-read the target for correctness, completeness and consistency and fix what you find. The reviewer's attention belongs on what you could not see.

Step 2 — Get the review

Pick the reviewer, strongest first.

1. A different model. Either the other runtime's CLI, or this runtime's CLI on a backend the user names whose model is not yours; a named backend's harness picks which CLI launches. This needs the diff-review skill installed beside this skill, Python 3, and that CLI on PATH. If any is unavailable, or the supervisor reports a status other than ok, record why and take rung 2. A review with no parseable verdict object is still a review: read its findings as prose. Launch it with the command diff-review gives for launching that CLI, with this skill's reviewer prompt in place of that skill's, diff-review's review-schema.json for the verdict where that command takes one, --backend <name> when a backend is named, and --cwd set to the repository holding the target (its own directory, outside one).
2. A fresh reviewer in this runtime, given the reviewer prompt and nothing from this conversation: a sub-agent, or where the host has none, a fresh launch of this runtime's CLI with diff-review's read-only flags (with diff-review absent, that launch is unavailable). Never a native code-review command — it reviews the working tree's changes, not the document.
3. Neither → stop. Report that no independent reviewer was available, what was missing, and that the Step 1 pass is the only review this document has had.

The reviewer prompt carries exactly:

• the target paths and the one-sentence purpose, and any context documents' paths as read-only context: read them, and report where a target falls short of them;
• the lens. For a plan or phase document: does following it reach the goal; steps missing, misordered or unverifiable; success criteria a builder could tick while the goal is unmet; assumptions stated as fact; a cheaper route to the same result. For anything else: whether its reader can act on it correctly;
• the burden of proof: every finding names the reader or builder who goes wrong and what they do next. A concern without one is labeled an observation;
• report only, never edit a file;
• close with one JSON object: findings (each with file, line, severity — blocker, major, minor or nit — summary, and failure_scenario holding that consequence), overall (the verdict in prose) and blocking_count (blockers plus majors). It is the shape of diff-review's review-schema.json, spelled here so a sub-agent needs no other skill.

Keep the supervisor's files outside the repository and delete them when done.

Step 3 — Settle each finding

Decide every finding on the document and the code, never on who wrote what:

• Accept — the failure is real.
• Reject — with the concrete reason: where the document already handles it, or the fact that makes the premise false. Disagreeing is not a reason.
• Partial — the failure is real and the suggested fix is not; say what you will do instead.

Send every rejection and partial back once, in one fresh launch on the same rung and backend, carrying each finding, your decision and your reason. Ask the reviewer to concede or answer with evidence it has not yet given, and re-decide on what comes back. A finding still disputed after that is an open disagreement: it is not applied, and it goes to the user with each position in one line.

Apply a nit only when it costs nothing.

Step 4 — Apply and re-check

Edit the target for every accepted finding, and for every partial one the send-back settled; an open disagreement is never applied. Then run the cyw skill — the full loop, not single-pass — over what changed, and tell the final cyw which findings are open so it leaves them alone. If cyw isn't installed or doesn't run, do its full loop by hand: review for correctness, completeness and consistency, fix, re-verify, and repeat until a pass finds nothing — a clean first pass still gets a confirming second — at most three passes.

Step 5 — Report

• Which reviewer ran: the other CLI or this one, with the backend's name and model or on the CLI's own sign-in, and on this runtime's own CLI your own model beside it, stating their independence as unverified; or rung 2, and why rung 1 was not reached.
• A table: finding, severity, decision, reason, applied.
• Open disagreements for the user to decide. Autonomously: leave them unapplied and list them.
• What the final cyw pass changed.