Code Review

Perform an adversarial review of the change. Look for opportunities to reduce layers (pass-through wrappers, single-use abstractions), remove unnecessary complexity (code-judo: restructurings that delete branches/modes/helpers, not rearrange them), and increase reliability (correctness, contract, state, concurrency, migration risk). For plan and spec reviews, judge the chosen direction before acceptance or test details: whether it solves the stated problem, rests on valid premises, assigns ownership to the right layer, fits observed constraints, preserves the highest-value intended outcome, and beats credible root-cause or lower-scope alternatives. A lower-scope alternative only beats the proposed route when it preserves the stated outcome or evidence shows the removed surface is unrequested, unauthorized, speculative, constraint-breaking, or not worth its complexity. Honor repo-wide policies (AGENTS.md, CONTRIBUTING.md, ADRs) as hard constraints. Verify what you can. Keep the original goal fixed; challenge the proposed route when evidence shows a better route to that same goal.

Coverage

The user circumscribes the review scope — a diff, a file set, a plan, an authoritative source to compare against. Within that scope, reading is exhaustive, never sampled: every changed line of a diff, every section of a plan, every compared surface of a parity audit gets read before the review closes. Risk weighting orders the work and decides how deep to drill; it never decides whether something gets read.

Partition the scope into natural cohesive units, derived mechanically from the source's own structure — files (or hunk groups per file) for a diff, sections/decisions/requirements for a plan or spec, components/screens/endpoints for a parity audit. A well-partitioned scope has roughly 10–50 top-level units; when mechanical enumeration produces more, coarsen by one structural level rather than dropping anything. Units structure the work and the coverage account; they are not the granularity of findings or of bookkeeping.

Review in two phases. Breadth first: read every unit, noting where risk concentrates or defects surface. Depth second: drill only into the flagged units, decomposing them as finely as the evidence demands — individual branches, handlers, payloads, state writes, copy/style elements — and chasing each suspect element down. Atomic-level scrutiny is triggered by evidence, not applied uniformly across the scope.

When the scope exceeds one pass, split it across sub-agents by unit — partition the scope, never sample it — and state the coverage plan first (N units, M slices) so the fan-out is visible before it starts. "Reviewed" is an observation claim: make it only when the coverage account shows everything in scope read, or every gap named with its blocker.

Traceability

The report must let the reader verify two things without access to the review process: what the review actually read, and what each finding rests on.

Coverage account. A short manifest of what was read — files with line ranges, document sections, compared surfaces — and what was not, each unread item named with its blocker (a source that cannot be read, an artifact that is unavailable, a judgment needing information only the user holds). A partial review presents itself as partial. For a parity audit the manifest lists each compared surface with its verdict — aligned, authorized divergence, or defect — since that matrix is the deliverable itself.