Code review

Find reachable code defects with enough evidence to act. Match the review to the result the user requested. Keep ordinary reviews light. Keep merge-gate conclusions strict.

Mode choice → interaction-modes.md. Surface binding → sources.md. Finding bar and filing breadth → evidence-and-filing.md. User-facing reports → output-format.md. Strict merge gate → merge-readiness.md.

Extended design vocabulary is available in codebase-design.md. Strict quality gates may cite engineering-principles.md. State how far each finding's load-bearing fact was proven using evidence-ladder.md. The core workflow remains complete without it or another skill.

Entry gate

• The user names a diff, working tree, staged changes, commit, branch, pull request, path, snapshot, paste, or prior finding.
• Derive the lens from the request. Do not limit it to a fixed list.
• If a merge-gate request lacks a branch or pull-request identity and scope, ask for them before reviewing.
• If an ordinary review names no surface, use a non-empty current worktree. If it is empty, ask for a surface.
• If the surface is a branch, look up its open pull request (GitHub MCP list_pull_requests with head, or gh pr view <branch>). An open PR makes it a PR review for delivery.