AI Review

Judge the diff

The tier to ask for

Review is hard reasoning about a stranger's change; ask the top tier, the model the repository's [models] section configures for it — never a model name coded here, and never a provider the repository did not choose. model_router maps review (and plan and audit) to the top tier; if the pin leaves it unconfigured, fall back to default_tier. Say which tier you ran on so the command event's tier_model can be read against reality.

What it produces

Findings, each one at file:line, each with the smallest change that would resolve it.

Steps

1. Read the spec and the plan first. Half of all real findings are "this is not what was agreed", and you cannot see those from the diff alone.
2. Read the diff whole before commenting on any part of it. A finding about a line that the next hunk deletes wastes the author's afternoon. If it does not fit in one pass, say so in the first line of the report, review it in named parts, and list the parts you have not read. A truncated pass reads exactly like a complete one, which is the failure this framework exists to cure, arriving as a confident report about the half that fit.
3. Work the checklists in references/, one lens at a time, and every lens in that directory is one of them: correctness, security, performance, testing, compatibility, architecture, simplification, docs, frontend and motion. Each is a separate pass; mixing them is how the security one gets skipped. Skip a lens the diff cannot touch and name the one you skipped — a lens nothing routes to is a checklist nobody works. Within each, follow the data flow: where the value enters, what may change it, where it is read. Then read the business rule the change encodes, not only the code — a lens applied to lines finds what is wrong, and only the rule says what is wrong here.
4. Never report what a tool already reports. Formatting, lint, secrets, dependency vulnerabilities — those ran in CI, and repeating them buries the findings only a person could have made. If the gate did not run, say that instead of standing in for it.
5. For each finding: what breaks, the inputs that break it, and the smallest fix. A finding without a failing scenario is an opinion, and it should be labelled as one.
6. Before you call anything blocking, try to kill it, and default to dismissing: re-read the file around the line, not the hunk, and look for the guard, caller, framework behaviour or config that makes the scenario impossible. Dismiss it too when the bug is real and the fix you would propose is wrong, or worse than the code. A real bug you are unsure of still blocks; a theoretical one you are certain of does not. Say what you tried to kill and what lived.
7. Say what is good, once, briefly, and only where it is load-bearing. Then rank findings by what you would actually block on.

Done when

• Every finding has a location, a failure scenario and a smallest fix.
• Nothing in the report claims a gate result that this skill did not see.
• The blocking findings are separated from the ones you would merge without.
• Nothing was accepted by this review. It reports; a person or a gate decides, and a review that accepts its own findings is one reader agreeing with itself.

The box

40 minutes of wall time, 120 tool calls — the numbers contract.py owns. The verdict returns in your result; you write no files. When the box closes with work left, return what you have and mark it TIMEBOXED: a partial verdict is a verdict, silence is not.

What this is not

Not a rewrite. If your finding is "I would have built it differently", it is a comment, not a blocker, and it says so.

• "I skimmed the last hunks; the important parts are covered" — a truncated pass reads exactly like a complete one: if the diff does not fit in one pass, say so in the first line of the report.