review-code

Review Code

Overview

Code review is the discipline of judging whether a change improves the health of the codebase — not whether it is perfect. An undirected reviewer does one of two failure modes: it rubber-stamps (misses real defects) or it nit-blocks (treats every preference as mandatory and never lets the change land). This skill prevents both by giving the review a governing principle, a fixed set of dimensions to inspect in value order, a parseable severity taxonomy, and a loop with an explicit stop condition.

This is the inline development-loop reviewer — it runs after you write a non-trivial change and before you commit. It is engine-agnostic: the reviewer can be a model (invoked via a role alias), a human, or a cloud tool. Because a model-backed reviewer has effectively unlimited throughput, it is the right engine for the inner loop — run it on every non-trivial change without spending a rate-limited cloud quota.

The cloud PR gate (CodeRabbit, via the rabbit-code-review skill) is a separate, later gate reserved for the pull request — do not spend it inside the inner loop. This skill covers everything up to the commit; the ship gate covers the PR.

Distilled from Google's Engineering Practices ("The Standard of Code Review", "What to look for"), the Conventional Comments spec, and the local severity→fix loop.

When to Use

• After writing a non-trivial change, before committing it (the inner loop)
• On an explicit request: "review this", "critique this diff", "is this change sound"
• Reviewing a subagent's or another author's diff before integrating it
• As a checkpoint in an implementation loop, once a task's code is written

When NOT to use:

• Shipping a PR — that is the cloud gate (rabbit-code-review), run once, at the PR
• A one-line or mechanical change (rename, import tweak) — review overhead > benefit
• In-flight, before the code exists — that is doubt-driven-review (per-decision, not per-diff)
• Diagnosing a failure — that is systematic-debugging