Claude Code Review Skill: A Reusable Review Checklist

A Claude Code review skill is a saved set of instructions that tells Claude Code how to review a change: what evidence to gather, what correctness checks to apply, which regression risks to flag, and how to present its findings. You install it once and reuse it across pull requests instead of restating the criteria each time.

The value of a skill over a one-off prompt is consistency. When the same rubric applies to every review, defects that slip past once can become lessons that update the skill. Tools like fenbs keep the approved rubric and those lessons together, so the next Claude Code session starts with the current version rather than a stale copy.

What a review skill should cover

A useful review skill covers four areas. Evidence means understanding the change before evaluating it: what the diff actually does, what tests exist, and what the stated intent is. Correctness means checking whether the logic achieves the stated goal without obvious bugs or edge cases the author missed.

Regression risk means identifying code paths the change touches that could break something working before. Actionable findings means producing output the author can use: specific locations, the reason something is a concern, and a clear suggestion rather than a vague complaint.

A review skill should also say what it will not do. It will not approve changes or sign off on correctness — that decision stays with a person. It will not ignore a declared scope: if you pass a single file, it reviews that file, not the entire codebase. Stating these limits in the skill prevents Claude Code from overstepping.

A reusable review skill template

Copy the skill below into a file at .claude/skills/code-review.md in your repository, or install it through Claude Code's skill management interface. Adjust the checklist items to match your team's standards before using it on real code.

# Code Review

## Purpose
Review the supplied diff or file list and produce a structured report. Do not approve
or sign off on the change. Flag concerns; a person decides whether to merge.

## Evidence step (run first)
1. Read every changed file in full. Do not summarise before reading.
2. Identify the stated purpose from the commit message or task note supplied.
3. List existing tests that cover changed functions. Note any changed function
   with no test coverage.

## Correctness checks
- Does the change do what the stated purpose says?
- Are error paths and null inputs handled?
- Do loop bounds, index offsets and type casts look correct?
- Are any new API calls using the right parameters per their current docs?

## Regression risk
- Which existing call sites pass through changed functions?
- Which tests would catch a regression in those paths?
- Are there side effects (file writes, database updates, external calls) that
  existing tests do not exercise?

## Findings format
For each concern:
  - File and line number
  - The issue in one sentence
  - Suggested fix or the question the author should answer

Group by: Critical (likely bug) / Warning (possible bug or clarity issue) /
Suggestion (improvement, not a block).

If no concerns are found, say so briefly rather than inventing minor points.

## Scope limit
Review only the files supplied. Do not expand the review to unreferenced files.
Do not run, build, or deploy. Do not commit.

How to install and run the skill

Save the file to .claude/skills/code-review.md and commit it to your repository. Claude Code will list it in the skill picker the next time you open a session in that project. You can also install skills through Claude Code's account-level skill interface for use across projects — check Claude Code's skills documentation↗ (opens in a new tab) for the paths that apply to your setup.

To run a review, activate the skill and provide the input: a diff, a file list, or a pull request description. The skill's evidence step asks Claude Code to read the full files before forming an opinion, which reduces findings based on incomplete context.

Test the skill on a recent merged change where you already know the outcome. Does it identify the issues that were caught in the real review? Does it flag false positives that slow the author down? The first run is calibration, not production use. For other skill formats, see Claude skills examples.

Improving the skill over time

A review skill improves when the team records what it missed. If a defect passes review and reaches production, add a checklist item that would have caught it. If a finding category consistently produces false positives, tighten the language so Claude Code applies that check more narrowly.

Treat each update as a deliberate decision: what changed, why, and who approved it. A skill that drifts through undocumented edits is harder to trust than one with a clear revision history. Keep a note of the defect that prompted each addition so the reasoning is available when someone questions whether a check is necessary.

How to do this with fenbs

1. Create a free account, free for one person with no credit card, and add the project the skill belongs to.
2. Save the approved review skill text in Skills and prompts in fenbs, with the date it was approved and any known gaps.
3. When a defect escapes review, add a lesson in Lessons learned: what slipped past, what check would have caught it, and what was changed in the skill.
4. Connect Claude Code to fenbs through Integrations and ask it to read the current review checklist from Skills and prompts before starting a review session.
5. Record decisions about scope or sign-off limits in Decisions and rules so later sessions do not overstep.

fenbs stores the rubric and lessons; it does not run the review or integrate with your pull request tool. The skill file in the repository is the active instruction set Claude Code reads. Use fenbs for the reasoning behind the skill, the record of what changed and why, and the lessons that make the next version better.

The review skill is a starting point, not a finished standard. Your codebase has patterns that a generic checklist cannot anticipate. After running the skill on a dozen real changes, you will have a clear picture of what it catches well and where it misses. Those observations are the most useful input for the next revision.

Keep the scope of the skill narrow by design. A skill that tries to check security, performance, documentation and style in a single pass produces long output that is harder to act on than a shorter, focused report. Consider separate skills for different concerns and activate the right one for the task at hand.

For related reading, see the code review checklist guide and how to install Claude Code. The AI prompts topic hub has related instruction patterns.