code-review

Code review is risk mitigation, not gatekeeping — catching what the author couldn't see, and occasionally sharing a better pattern when it genuinely helps.

Two-sided protocol. Reviewers load it to raise findings; authors load it to answer them. Both sides read the whole file — a contested finding converges only when both agree what [blocker] means and what closes one. Everything through Review Summary Format is shared; Answering Findings is author-side.

Review Context

Before reviewing, establish context:

• Scope: Default to staged files (git diff --cached --name-only, then git diff --cached --stat, then targeted path diffs). For PRs or commits, inspect changed files and stats before reading targeted hunks. Only broaden if explicitly asked.
• Local working tree: For local reviews, triage unstaged and untracked files before review. If related but not staged, surface this explicitly and include only if the review target is "pending changes"; if unrelated, ignore; if unclear, ask before including.
• Initial scope: Before reading the diff, record in one line what the change set out to do — take it from the author's stated intent when supplied (Pairing: Change Summary; multi-agent: task description and done-when; PRs: description and linked ticket), derive it only when it is not, and clarify with the author when it is unclear. This is the anchor for every later round: it bounds which behavior is required, not which code is inspected. Every submitted line is still reviewed for P0-P2 defects. Work beyond the initial scope is scope creep, not thoroughness — review it, then flag it [overreach].
• Timing: Is now the right time for this functionality? Half-baked or premature additions warrant a [question].
• Approach: Round 1 only. Is the approach sound, not merely correct — would another team take this shape, and was the first workable rung of CORE's Minimality Ladder taken? Raise an alternative only when it is named and its benefit demonstrable (have-you-considered); "I'd have done it differently" is not a finding. [question] when exploratory, [concern] when materially cheaper and still cheap to switch. After round 1 the approach is settled — reopening it is relitigation.
• Absence: Review what should be here and is not. Take the baseline from the author's declarations (Pairing: Change Summary success criteria, doc impact, test impact; multi-agent: done-when) and check each against the diff. Diff-first reading optimizes for what is present; absence has to be sought deliberately. Where no declarations exist, say so — it caps confidence.
• Diff-first: Read bounded diff context before source files. Prefer name-only/stat first, then targeted path or hunk diffs. Only read source when a finding needs surrounding context. Never pre-read the entire codebase.
• Sources: State what you have read before drawing conclusions, per CORE Rule 5, and extend it as you read. The summary line reports this list; it does not create it. A conclusion reached before its source was read is not grounded by reading that source afterwards.
• Size: Beyond 800 lines, 20 files, 80K chars total, or 20K chars in one file — large diffs hide bugs. Consider suggesting a split (PR) or incremental commits (pending); avoid unbounded full-diff reads, classify files and inspect targeted paths or hunks, and verify critical findings against source before tagging [blocker] or [concern].
• Reviewer limits: If reviewing outside your expertise, say so. Make assumptions explicit.