Claude Code Review Skill: What to Install and How to Write Your Own
By Neo Zino - builder of ClockedCode10 min readA Claude Code review skill is a SKILL.md that reviews your diff. Compare the built-in /code-review, two official plugins, and a 20-line skill you write.
Made with DispatchSEO
On this page
You probably do not need to install a review skill first, because Claude Code already ships one called /code-review. Run it on a branch and it reviews your commits ahead of upstream plus uncommitted changes. Install an official plugin when you want more reviewers, and write your own SKILL.md when you want your team's checklist instead of a generic one.
TL;DR: Try the bundled
/code-reviewfirst. Add the officialcode-reviewplugin for a multi-agent pass on pull requests. Write a 20-line skill when you have rules the generic reviews miss. Use a hook for anything that must be checked every time.
Five ways to get a review
- /code-review (bundled)Your terminal, any planAlready installed. /review is an alias.
- code-review pluginYour terminal, needs gh4 parallel agents, drops findings under 80 confidence
- pr-review-toolkit pluginYour terminal6 single-purpose agents, asked for in plain words
- Managed Code ReviewAnthropic cloud, Team and EnterpriseAverages $15-25 per review, billed separately
- Your own SKILL.mdYour terminalYour checklist, about 20 lines
What does the built-in /code-review already do for you?
Per Anthropic's code review docs, /code-review is a bundled skill and /review is an alias of it. With no arguments it covers your branch's commits ahead of its upstream plus any uncommitted changes. You can aim it elsewhere with a file path, a PR number, a branch name, or a range like main...my-feature.
/code-review
/code-review main...my-feature
/code-review high
/code-review --fix
A few details from the docs that the skill directories skip:
- It runs as a background subagent with its own context window, so the findings arrive in your conversation without filling it. That is how it behaves from v2.1.218; earlier versions ran it inline.
--fixapplies the findings to your working tree.--commentposts them on a GitHub PR as inline comments.- A level of
lowthroughmaxtrades coverage for confidence. Atlowit reports only what it is most sure about. - It follows your
CLAUDE.md, but it does not readREVIEW.md. That file is for the managed cloud review. - A background review applies
--fixedits outside your session's checkpoints, so/rewinddoes not undo them. Use git to revert.
That is already a capable reviewer. Most pages ranking for this query are directories of third-party skills, and none of them mention that the first review skill is the one you already have.
Which review option fits which job?
| Option | Where it runs | Good at | Cost or catch |
|---|---|---|---|
/code-review (bundled) | Your terminal | Checking a branch before you push | Generic rules, not yours |
code-review plugin | Your terminal | PR review with 4 parallel agents | Needs gh installed and authenticated |
pr-review-toolkit plugin | Your terminal | Narrow checks: tests, comments, types, silent failures | Triggered by asking in plain words |
| Managed Code Review | Anthropic's cloud | Automatic PR comments for a team | Team or Enterprise plan, averages $15-25 per review |
Your own SKILL.md | Your terminal | Your team's checklist | You maintain it |
The official code-review plugin, per its README in the anthropics/claude-code repo, launches four review agents in parallel: two check CLAUDE.md compliance, one scans for obvious bugs, and one reads git blame and history for context. Every issue gets its own confidence score, and anything under 80 on the 0-100 scale is dropped. It skips closed, draft, trivial, and already-reviewed PRs, so a missing comment does not always mean a clean PR. Install it the way the plugins guide describes for official plugins:
claude plugin install code-review@claude-plugins-official
The pr-review-toolkit plugin ships six single-purpose agents: comment-analyzer, pr-test-analyzer, silent-failure-hunter, type-design-analyzer, code-reviewer, and code-simplifier. Its README documents no slash commands, only natural-language requests such as "Check for silent failures" or "Are there any critical test gaps?" I would install it for one agent, silent-failure-hunter, and ignore the rest until a bug class keeps slipping through.
I am deliberately not ranking community review skills here. I did not install or run any of them, and a directory listing is not evidence that a skill works. The official options above are the ones whose behavior I could check against Anthropic's own docs.
How do you write your own review skill in 20 lines?
Write one when the generic reviewers miss rules specific to your repo: "every new API route has an integration test", "no raw SQL outside db/". Here is the one I would start from. Save it as .claude/skills/review-diff/SKILL.md:
---
name: review-diff
description: Review the current branch diff for bugs, missing tests, and risky changes. Use before opening a pull request or when asked to review my changes.
disable-model-invocation: true
allowed-tools: Read Grep Glob
---
## Changed files
!`git diff main...HEAD --stat`
## Diff
!`git diff main...HEAD`
## How to review
1. Read the diff above. Open a full file only when a hunk cannot be judged alone.
2. Report only problems you can point to: a wrong condition, an unhandled error,
a missing test for new behavior, a secret, a destructive command.
3. Format each finding as `file:line - problem - suggested fix`.
4. Skip style, naming, and anything lint or CI already enforces.
5. If you find nothing, say "No blocking issues" and stop.
review-diff - 20 lines, 766 bytes
- description (144 characters)Always in context. Says what it does and when to use it. Capped at 1,536 characters.
- disable-model-invocation: trueOnly you can start it. Its description leaves Claude's context.
- allowed-tools: Read Grep GlobPre-approves read-only tools for that turn. Does not block other tools.
- !`git diff main...HEAD`Runs before Claude sees the file. The diff replaces the line.
- 5 numbered review rulesWhat to report, in what format, and when to stop.
Then run /review-diff in a session on a feature branch. Swap main for your default branch. If you have not written a skill before, the skills guide covers the file layout and where skills can live.
Rule 5 matters more than it looks. A reviewer told to find problems will invent some, and an explicit "No blocking issues" exit is the cheapest false-positive filter I know. Rule 4 does the same job from the other side, by keeping the review off ground your linter already covers.
What does Claude actually receive when the skill runs?
The !`command` lines run before Claude sees the file, and their output replaces the placeholder. I created this skill in a scratch git repo with one commit on main and one change on a feat branch, then ran the two commands from the file in that repo. This is what would have been injected:
$ git diff main...HEAD --stat | tail -2
f.txt | 1 +
1 file changed, 1 insertion(+)
$ git diff main...HEAD
diff --git a/f.txt b/f.txt
index 7898192..422c2b7 100644
--- a/f.txt
+++ b/f.txt
@@ -1 +1,2 @@
a
+b
The skill file measured 20 lines and 766 bytes, and the description 144 characters, well under the 1,536-character cap the docs set for a skill's description. I ran those commands in a shell, not through Claude Code, because this environment had no logged-in session. Treat it as proof of what gets injected, not of what the model says about it.
The practical consequences from the docs are worth knowing before you grow the skill:
- A failed command (non-zero exit) aborts the whole skill invocation. If your default branch is
masterand the skill saysmain, you get an error instead of a review. - A large diff is injected whole. For a long-running branch, a
--statline plus an instruction to open files on demand costs far less than pasting everything. - Keep
SKILL.mdunder 500 lines. Move long checklists into supporting files in the skill directory.
Should review run inline, forked, or as a subagent?
By default a skill runs in your current conversation. Adding context: fork to the frontmatter runs it in a separate subagent context instead, which is how the bundled /code-review behaves. The agent field picks the type (general-purpose by default, or Explore, Plan, or one of your own).
Same skill, two run modes
- Sees your whole conversation
- Review text lands in your context
- Good for a quick check of what you just wrote
- Starts without your conversation history
- Review runs in its own context window
- Instructions must stand alone
I fork reviews of anything bigger than a few files, because a long diff pasted into the main conversation is context you pay for in every later turn. The catch from the docs: a forked skill does not see your conversation, so "review what we just discussed" returns nothing useful. Write the instructions as if the reader knows only the diff.
If you want a standing reviewer with its own system prompt and tool limits, that is a subagent rather than a skill. The docs frame the split simply: a skill is a reusable procedure, a subagent is a specialized worker that can use skills as reference material. The subagents generator builds the file if you want that route.
How do you control when the review fires?
Three settings decide who starts the review:
| You want | Set |
|---|---|
| Only you can start it | disable-model-invocation: true in the skill |
| Claude may start it when you ask in plain words | Leave the default |
| Block the bundled review entirely | A Skill(review) deny rule, or disableBundledSkills |
Name collisions are the trap. Calling your skill code-review replaces the bundled /code-review, but /review still runs the built-in. If you wanted a full replacement, you now have two reviewers answering to two names. Pick a distinct name like review-diff unless you mean to override.
To stop Claude and scheduled tasks from launching the bundled review while keeping it available for you to type, the docs give a skillOverrides entry in settings.json:
{
"skillOverrides": {
"code-review": "user-invocable-only"
}
}
When a review skill is the wrong tool
A skill is a prompt, so it is probabilistic. If a check must run every time, such as "block commits that contain a secret", use a hook, which runs as a shell command whatever the model decides. A review skill also cannot replace a human on risky changes, and the official plugin README says as much: its output is a starting point for human review.
Skip the custom skill if you have fewer than a handful of repo-specific rules. The bundled review plus a decent CLAUDE.md covers more than people expect, and the rules guide shows how to write those lines. Every extra skill also adds a description to context, so the curated skills list argues for keeping the set small.
FAQ
What is a Claude Code review skill?
A review skill is a SKILL.md file in .claude/skills/skill-name/ that tells Claude how to review code: what to report, in what format, and what to skip. You run it as a slash command, and it can pull in your diff with a shell command before Claude reads it.
Is there a built-in code review skill in Claude Code?
Yes. /code-review is a bundled skill, and /review is an alias for it. It reviews your branch's commits ahead of upstream plus uncommitted changes, or a target you pass, such as a PR number, a branch, or a ref range like main...my-feature.
How do I write my own code review skill?
Create .claude/skills/review-diff/SKILL.md with a description, a shell line that runs git diff main...HEAD to inject the diff, and a short numbered list of what to report. Set disable-model-invocation: true if you want only yourself to start it.
Should a review skill run as a subagent?
Often yes. Add context: fork to the frontmatter and the review runs in its own context window without your conversation history. The catch is that the skill must then stand alone, because the forked agent cannot see what you discussed earlier.
Does a custom review skill replace /code-review?
Only if you name it code-review. A project or personal skill with that name replaces the bundled /code-review, but the /review alias still runs the built-in. Any other name, such as review-diff, sits beside the built-in.
Pick the smallest thing that catches your bugs
Run the bundled review for a week, note what it misses, and put exactly those misses into a 20-line skill. ClockedCode ships a curated set of skills and a tuned CLAUDE.md built on the same keep-it-small idea.