Code Review Gates

Self-review checklist, PR review protocol, and review-response protocol for Claude Code. Covers all three sides of the review loop: before sending (self-review), when reviewing others, and when receiving feedback on your own diff.

What it installs

Artifact	Path (in your project)	Purpose
Skill	`.agents/skills/code-review/`	Self-review checklist, Ship/Show/Ask, PR template, reviewer protocol, review-response protocol
Rule	`.claude/rules/git-workflow.md`	Always-loaded pointer — routes Claude to the skill before any commit or PR
Agent	`.claude/agents/code-reviewer.md`	Subagent for isolated review of a diff/PR in a fresh context — use when the main conversation already saw the code being reviewed, or the diff is too large to load in main context

How it works

The rule loads on every Claude Code session. It tells Claude to consult the code-review skill before creating branches, committing, or opening PRs. No explicit /code-review invocation required — Claude runs it as part of the pre-commit workflow.

The skill gives Claude a structured protocol:

Self-review gate — 7-point checklist run against git diff --staged before committing
Ship / Show / Ask — decides the right review track for each change
PR description template — what + why + how to verify
Reviewer protocol — what to block on, what not to block on, comment tone conventions
Review-response protocol — READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT when feedback comes back; accept / push back / defer framework; no performative agreement; one fix at a time with per-fix verification

Self-review checklist (summary)

Before every commit or PR, Claude checks:

Correctness — solves the stated problem, error paths handled
Tests — new behavior has a failing-then-passing test
Security — input validation, no secrets in code, auth boundaries correct
Design — simplest solution, no premature abstractions, functions ≤ 20 lines
Naming — readable in 6 months without context
Side effects — no resource leaks, no stray console.log/debugger/TODO
Diff size — > 400 lines suggests splitting

Ship / Show / Ask

Track	When	Action
Ship	Typo, trivial chore, no logic change	Merge directly
Show	New feature, accepted design	Open PR, merge immediately, notify team
Ask	Novel approach, breaking change, security-sensitive	Open PR, wait for approval

Pairs well with

branch-strategy — branch naming and PR size conventions (also installs git-workflow.md rule)
git-conventional — commit message format
tdd — ensures tests exist before self-review gate runs