Review

Independently audit existing code with concern-specific lenses and decide whether it is safe to ship. Review is the gate after verify — the builder proves the change works on the real surface, then review decides whether the change is good.

Principles

• Prefer parallel reviewer personas when the concerns are independent
• Evidence beats taste
• Load shared doctrine from the target repo's guidance files such as AGENTS.md, CLAUDE.md, or repo rules
• Keep the final verdict tied to concrete evidence, not reviewer instinct alone
• Keep findings risk-focused; do not drown the user in low-value nits
• Track reviewer personas internally; include them visibly only when asked or when the harness has compact metadata
• If runtime proof for your own completed change is the goal, hand off to verify

Handoffs

• Self-checking a change you just authored, before handing it off for review → use verify
• Review is blocked because the repo cannot be booted or exercised reliably → use agent-readiness
• Main problem is stale AGENTS.md, README, specs, or repo docs → use docs