Best Claude Code Skills for Code Review in 2026: 7 Skills Compared

code-review reviews everything that changed since a fixed point you give it: a commit, a branch, a tag or main. It compares against the merge-base (git diff <fixed-point>...HEAD) and checks that the ref resolves and the diff isn't empty before doing anything else.

The review runs on two axes, each in its own subagent so they don't pollute each other's context. Standards checks the diff against every file in the repo that documents how code should be written, with CODING_STANDARDS.md or CONTRIBUTING.md always included, plus a fixed baseline of twelve code smells from Fowler's Refactoring (Feature Envy, Shotgun Surgery, Speculative Generality and others). The repo's own rules always win over the baseline, and smells are reported as judgement calls, never hard violations. Spec looks for the originating issue in commit messages, a path you pass, or a spec file under docs/, specs/ or .scratch/, then reports what's missing, what wasn't asked for and what looks wrong.

The two reports come back side by side, deliberately not merged or reranked. The skill's reasoning: code can follow every standard and still build the wrong thing, or build the right thing and break every convention. One caveat: it expects an issue tracker to be configured and tells you to run /setup-matt-pocock-skills if it isn't, so it works best alongside the rest of the repository.

caveman-review comes from Caveman, a project built around making agents say less. The skill applies that to code review: one line per finding, in the format L<line>: <problem>. <fix>., with an optional severity prefix (🔴 bug, 🟡 risk, 🔵 nit, ❓ q).

Most of the skill is a list of what to drop: "I noticed that…", hedging, compliments on every comment, and restating what the line already does. What it keeps is exact line numbers, symbol names in backticks and a concrete fix. Its own example turns a four-sentence comment about a missing null check into L42: 🔴 bug: user can be null after .find(). Add guard before .email.

It knows when not to be terse. Security findings, architectural disagreements and reviews for someone new to the codebase get a normal paragraph. It's also strict about its scope: it writes comments ready to paste into a PR, and doesn't fix code, approve, request changes or run linters. That makes it a format, not a review method. It doesn't tell the agent what to look for.

requesting-code-review is part of Superpowers, Jesse Vincent's development methodology for coding agents. Its idea is simple: the agent that wrote the code shouldn't review it. Instead, it dispatches a reviewer subagent with precisely written context and "never your session's history".

The skill takes a base and a head commit, a short description of what was built and the plan or requirements, and fills them into a prompt template in code-reviewer.md. That template is where most of the substance is. The reviewer treats the spec as a vision document, so a reasonable user's expectation counts as a requirement even when the spec is silent. It has to list every behavior it set aside as out of scope instead of dropping it quietly, and its review is read-only: no touching the working tree, the index or HEAD.

Superpowers makes review mandatory after each task in subagent-driven development, after a major feature and before merging to main. Findings come back as Critical, Important or Minor, and the skill says to fix the first two before moving on. It's built for an agent reviewing its own output, not for reviewing a teammate's pull request.

receiving-code-review covers the other half of the job: what the agent does once feedback arrives. Its core rule is "verify before implementing", and it bans "You're absolutely right!", "Great point!" and, more strictly, any thank-you at all. The fix itself shows that the feedback was heard.

It gives the agent a six-step pattern: read the whole review, restate each item, check it against the codebase, decide whether it's right for this codebase, respond, then implement one item at a time and test each. If any item is unclear, the agent stops and asks before implementing anything, because the items may be related. For feedback from external reviewers, it adds a checklist (does this break existing behavior, is there a reason for the current code, does the reviewer have the full context?) and a YAGNI check: if a reviewer asks to implement something "properly", grep for real usage first.

It also handles the social part honestly. It tells the agent when to push back, how to do it with technical reasoning, and how to admit it was wrong in one line. It doesn't review anything itself.

code-review-and-quality is the most thorough document on this list, at about 400 lines. It reviews every change on five axes: correctness, readability and simplicity, architecture, security and performance. Its approval standard is borrowed from good human review: approve a change when it clearly improves code health, even if it isn't how you'd have written it.

Beyond the checklist, it covers things the other skills leave out. Change sizing: about 100 changed lines is good, about 300 is acceptable for one logical change, about 1,000 should be split, with four ways to split it. Severity labels so authors know what's required (no prefix), blocking (Critical), optional (Nit, Consider) or informational (FYI). A "review the tests first" step, and a multi-model pattern where one model writes, another reviews and a human makes the final call.

The trade-off is length. It's written as much for people as for agents, and its description triggers before merging "any change". On a small repo, that's more process than you may want for every diff.

review-pr is built for automated pipelines, not chat. It expects a checked-out PR branch, an annotated diff in pr_diff.txt and the description in pr_description.txt, and writes its whole output to review.json for a workflow to publish. It's explicitly forbidden from posting to GitHub itself.

The output is strict. Each comment starts with 🚨 CRITICAL, ⚠️ IMPORTANT, 💡 SUGGESTION or 🧹 NIT, and nits are only allowed with a concrete suggestion block. Inline comments must point at a line that appears in the annotated diff. The skill spends a whole section on getting GitHub suggestion blocks right, down to matching bracket depth. Before the verdict, it audits every comment and test the diff adds against the repository's own guidelines. A bundled script, scripts/validate_review_json.py, checks the result before anything is returned.

It's also designed to be extended. It looks for a companion review-pr-local skill in your repo for house conventions, and uses security-review-pr or check-impl-against-spec skills when they exist. Outside a pipeline that produces those input files, it's awkward to use by hand. Because it ships Python scripts, the Skillpack CLI lists them as executables when you install it.

This skill is named code-review in its SKILL.md, the same as Matt Pocock's. We list it as coderabbit-code-review here only to tell the two apart. It's the official way to run CodeRabbit's review from inside your agent: the agent calls the CodeRabbit CLI with --agent for machine-readable output, reads the findings and their severities (critical, major, minor, trivial, info), and turns them into a task list.

It supports the review scopes you'd expect: committed or uncommitted changes, untracked files, a base branch or commit, or a single directory. For "implement and review" requests, it describes a loop: build the feature, run the review, fix critical and major findings, re-run to verify, then stop rather than loop forever.

It's the only skill here that depends on an outside service. The CLI must be installed and signed in, and the skill says plainly that it sends code diffs to the CodeRabbit API, so it tells the agent to check the scope for secrets before running. It's also careful with credentials: the agent never starts a login or touches tokens itself.