review

Multi-Model Code Review

Cross-provider review of uncommitted changes. The premise: any single model has consistent blind spots, so a parallel quartet (three Anthropic specialists plus Codex / GPT-5) catches more real bugs than three Anthropics alone. Empirically, codex caught a real correctness bug on PR #470 (sharing bulkTargetForAgent between scale_check and work_query paths) that all three Anthropic reviewers missed.

Phase 1: Identify Changes

Run git diff (or git diff HEAD if there are staged changes) to see what changed. If there are no git changes, review the most recently modified files that the user mentioned or that you edited earlier in this conversation.

If the diff is large, write it to /tmp/review-diff.txt once and reference that path in each agent prompt, agents can read the file directly instead of receiving the diff inline.

Phase 2: Launch Four Reviewers in Parallel

Send a single message with four Agent tool calls so they run concurrently.

Agent 1: Code Reuse (general-purpose)

Look for existing utilities and helpers that the new code duplicates. Common locations: utility directories, shared modules, files adjacent to the changed ones, and the language's standard library. For each new function, search the codebase for an existing one that does the same thing. Flag inline logic that could use an existing utility, hand-rolled string manipulation, manual path handling, custom environment checks, ad-hoc type guards, ad-hoc subprocess calls.

Agent 2: Code Quality (general-purpose)

Hacky patterns to flag:

• Redundant state: state that duplicates existing state, cached values that could be derived, observers that could be direct calls
• Parameter sprawl: new parameters added to a function instead of generalizing or restructuring existing ones
• Copy-paste with slight variation: near-duplicate code blocks that should be unified
• Leaky abstractions: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries
• Stringly-typed code: raw strings where constants, enums, or branded types already exist
• Unnecessary comments: comments narrating what the code does (well-named identifiers already do that) or referencing the task, keep only non-obvious WHY (hidden constraints, subtle invariants, workarounds)
• Boundary violations: directories or modules with architectural rules (search for boundary_test.go, arch-test, ESLint no-restricted-imports, etc.) that the change might violate
• Slop & erosion (rules/reference/anti-slop.md): single-implementer interfaces / single-entry registries / factories returning a constant (overengineering), caching of constants or parallelism for tiny collections (premature optimization), narration comments and echo docstrings (documentation noise), success-booleans / generic error messages / retries that swallow failures (error obscuring), silent fallbacks and auto-correction (hidden behavior), and unrequested features or no-op validation (spec deviation). Weight toward code that extends an existing module — apply the erosion test: would this look like this if written from scratch with today's requirements?