Review a change with another provider

Use a second provider to test whether a different reviewer finds useful problems on your task. Keep both reviewers anchored to the same change and acceptance criteria. Agreement is evidence to inspect, not a guarantee.

This example assigns correctness review to Claude Code and edge-case review to Gemini CLI. You can swap roles in a recipe. These assignments demonstrate a workflow; they do not establish a ranking of model strengths.

Try the executable example

Download and extract the reference package. It needs Node.js 22 or later and uses no dependencies or provider credentials.

node cli.mjs new ./review-run --recipe review

The command stops at the scope gate. Read the task, participating providers, source files, limits, and local-artifact target. If those are the scope you want, record your decision using the digest printed by the command:

node cli.mjs decide ./review-run --gate scope --digest PRINTED_DIGEST --decision approve --by YOUR_NAME
node cli.mjs run ./review-run

The default is fixtures execution. Both provider responses are synthetic recordings. No provider is contacted and no subscription or API quota is used.

Inspect the concrete change

The baseline retry configuration numbers the first attempt incorrectly. For attempt 1 it produces 2000 ms; the contract requires 1000 ms. The candidate changes firstAttempt from 0 to 1.

The trusted checker evaluates attempts 1, 2, and 6 plus invalid inputs. It runs a fixed function against JSON data. The candidate cannot replace that function, insert a command, or write a different file.

Read the baseline and final values in the acceptance packet. The evidence includes the original contract, the full proposed configuration, and both reviews. The source snapshot and artifacts have recorded hashes.

Give the reviewers independent inputs

Both review stages depend on the checks, so they can run in parallel. Neither stage depends on the other review. They receive the same original evidence before findings are combined.

Ask each reviewer for a concrete location, failure condition, severity, and a check that could confirm the issue. For example:

Inspect retry numbering, cap behavior, and invalid inputs. Report only findings supported by the attached configuration and contract. State which behaviors were not exercised.

A second reviewer repeating the first model's summary does less to test the original reasoning. Preserve the independent first pass before discussion.

Decide and retain the evidence

The acceptance gate displays findings and limitations separately by stage. Run a proposed check when reviewers disagree about observable behavior. A product requirement that remains ambiguous needs a human decision.

Approve, deny, or use a recipe with a bounded revision path. This read-only review recipe has no writer revision stage; changing the candidate means a new run. An approved report remains a local artifact. The runner has no merge, deployment, or publishing command.

Replace recorded stages deliberately

Create a new run with --execution import to export eligible requests and import real results. The package README explains the native envelopes and manual JSON alternative. Preserve each request digest and actual process exit code. A changed role or recipient requires a newly reviewed recipe.

Native invocation examples are documentation-checked. Fixture tests do not establish live policy enforcement, account access, model quality, or cost.

What goes wrong

Both reviewers may repeat the same mistake, especially if they share a misleading summary. Findings without reproducible evidence add review work. A changed candidate invalidates both reviews even when their original conclusions sounded reasonable.

How to check

Run node --test test.mjs in the package. Then deny a scope gate and restart: no review should run. Modify a completed artifact and confirm the hash check rejects it. A stale approval digest must fail.

To evaluate value, compare a single-review baseline with this recipe on the same changes. Count confirmed defects, false alarms, missed cases, human review time, elapsed time, and reported usage. Keep the extra stage when it helps enough to justify its cost.