Code Review

Perform an adversarial review of the change. Look for opportunities to reduce layers (pass-through wrappers, single-use abstractions), remove 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, and beats credible lower-scope or root-cause alternatives. 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.

Attribution

Distinguish NEW (introduced or made materially worse by this change) from PRE-EXISTING (already true on the base branch). Compare against base — read the unchanged file or check blame, not just the diff hunks. When the change replaces or deletes code, enumerate the guards and preconditions the old surface enforced — not just which capabilities it kept — and confirm each survives; an action that stays present but loses the predicate that gated it is invisible in a structural diff. Report PRE-EXISTING only when the change touches the same surface and it blocks the intended outcome, the change makes it worse, or the user asked for a broader audit. Tag every finding [NEW] or [PRE-EXISTING]; if uncertain, say so rather than defaulting to NEW.

Plan-Direction Gate

Activate this gate when reviewing a plan, spec, proposed implementation approach, migration design, or any request asking whether an approach is right, wrong, best, optimal, or worth doing.

Required evidence before judging plan quality:

• Target outcome and explicit constraints from the prompt, repo evidence, linked issue, or local project rules.
• The plan's chosen strategy and ownership point: data source, state write, shared contract, call boundary, persistence/schema boundary, or presentation layer.
• A checked logic chain from problem → decision point/root cause → proposed change → intended effect.
• Credible alternatives within the same authorized goal, especially earlier fix points, smaller-scope routes, deletion of unnecessary layers, and existing local owners.
• A bounded optimality judgment: best-supported under observed constraints, adequate but suboptimal, wrong/unsupported, or unjudged without named evidence or a user decision.