Best Code Review Skills for Claude Code and Codex

The best Claude Code review skill is the one that matches how you want review to happen: a fresh reviewer after each task, a checklist you run on a diff, or a loop that stays on a pull request until it is clean. The directory has dozens of skills under code review and pull requests. This guide compares fourteen of them by review style, whether they use subagents, what they need and how they are licensed.

Skills are plain folders, so Codex and Claude Code can both load them, but a few picks assume subagents, the GitHub CLI or Python. Confirm those exist in your setup, and see the Codex page for where that agent loads skills from.

Code review skills compared at a glance

Every skill above passed the directory's automated SKILL.md check. That is a pattern match, not an audit, so read the files before installing.

Reviewer-subagent skills for Claude Code

These skills hand the diff to a separate reviewer so the author does not mark its own work. Anthropic's documentation explains why this helps: a subagent starts in its own context window and returns a summary.

Requesting code review

Requesting code review dispatches a general-purpose subagent using a code-reviewer template. You pass a description, the requirements, and BASE and HEAD commit hashes. Findings come back as Critical, Important or Minor. The reviewer gets only that scoped context, never the session history.

• Best for: reviewing each finished task or a branch before merge.
• Requirements: git, and an agent that can launch subagents.
• Trade-off: it is a short skill that expects you to supply the plan or requirements to compare against.

O2 review loop

O2 loop splits work into an orchestrator, a coder subagent and a fresh reviewer process each round, up to five rounds. It commits only local WIP commits and never pushes. The reviewer runs through Codex CLI or a sandboxed Claude, per its description.

• Best for: larger changes where you want a written spec and repeated independent review.
• Requirements: a git repository with worktree support and a reachable review backend.
• Trade-off: it is licensed AGPL-3.0, and the loop has several confirmation points, so it suits planned work more than quick fixes.

Cherry Studio PR review

Cherry Studio PR review reviews branches, pull requests and commits against that project's architecture and naming rules. It is report-only unless you add a fix or submit modifier, and for large diffs it uses a reviewer and verifier flow when independent subagents exist.

• Best for: studying how a project turns its own conventions into a review skill.
• Requirements: access to the branch or pull request, plus the project's own rules.
• Trade-off: it is written for one codebase and licensed AGPL-3.0, so treat it as a template.

For a whole workflow built on this idea, see subagent-driven development and our guide to Claude Code subagents.

Checklist and methodology skills

These add structure to the review but run in the main conversation.

Code review excellence

Code review excellence frames review as knowledge sharing. It moves through context gathering, a high-level pass, a line-by-line pass and a summary, and defines blocking, important, nit, suggestion and praise labels. It includes language notes for Python and TypeScript.

• Best for: teams that want comments that teach, not just reject.
• Requirements: none; it references an optional analyzer script.
• Trade-off: it is a longer document, so it uses more context than a checklist.

Code review checklist

Code review checklist covers security, correctness, performance, maintainability and testing, and ends with a fixed report that has a merge-readiness verdict. The skill is named code-review, which matters because of the Claude Code naming rule noted in the FAQ.

• Best for: a consistent, short review of any diff.
• Requirements: none.
• Trade-off: it is generic, with security ranked first even when your change is a refactor.

Code review specialist

Code review specialist reviews for security, performance, quality and maintainability, with a checklist, a finding template and two Python scripts that compute complexity metrics.

• Best for: reviews that need numbers, such as complexity before and after.
• Requirements: Python for the scripts.
• Trade-off: the metrics are only as useful as the files you point them at.

Over-engineering review

Ponytail review looks only for unnecessary complexity. Each finding is one numbered line with a location, a tag such as delete, stdlib, reuse, yagni or shrink, and a replacement, and the report ends with a net line count.

• Best for: a second pass after an agent has written a lot of code.
• Requirements: none.
• Trade-off: correctness, security and performance are explicitly out of scope, so run another review as well.

Pull request automation skills

PR babysitter

PR babysitter keeps watching a pull request, fixing review comments, diagnosing CI failures and retrying likely flaky checks up to three times. It does not post replies to human review threads automatically and stops only when the PR merges, closes or needs you. It lives under a .codex skills folder and is written for Codex.

• Best for: unattended follow-through on a PR you have already opened.
• Requirements: an authenticated gh CLI and Python 3.
• Trade-off: it commits and pushes to the PR branch, so give it a branch you are happy for it to edit.

GitHub review iteration

GitHub review iteration is an orchestrator that triages review threads into actions with one subagent, implements them with another, and repeats until nothing actionable remains. It depends on sibling skills for fetching review state and implementing actions, so install the folders together.

• Best for: PRs with many bot and human comments.
• Requirements: a GitHub pull request URL and the companion skill folders.
• Trade-off: more moving parts than a single-file skill.

Receiving code review

Receiving code review is the counterpart for the author's side. It tells the agent to verify feedback against the codebase, ask about unclear items before touching anything, and push back with technical reasons when a suggestion is wrong.

• Best for: acting on comments from reviewers or automated tools.
• Requirements: none.
• Trade-off: it rules out effusive agreement, which some teams may find blunt.

PR finalize

PR finalize checks that a pull request's title and description match what the code does, then reviews the code against project practices. It is analysis only: it forbids approving, requesting changes or commenting on the PR.

• Best for: a pre-merge sanity check, and as a model for report-only behavior.
• Requirements: a way to read the pull request, such as the gh CLI; its code checks are specific to Microsoft's Garnet project.
• Trade-off: you would rewrite the project rules for your own repository.

CLI-backed and project-specific review skills

Open Code Review wraps the ocr command-line tool, installed with npm. It reviews workspace changes, a commit or a branch comparison and returns line-level comments with a category and severity. It needs an LLM provider configured first, and applies fixes only when you ask for review and fix. Requirements are Node and a model endpoint; the trade-off is that the review quality depends on the model you configure.

Backend code review shows a strict evidence-first approach: every finding must tie to an observable failure, a broken contract, a security boundary or a data integrity risk, ranked P0 to P3. It is scoped to one project's api folder. GitHub reports its licence as NOASSERTION, meaning no recognized licence identifier, so check the repository's licence file before reuse.

Which Claude Code review skill fits your workflow?

• Independent review per task: requesting code review, with subagent-driven development if you want the full loop.
• A quick standard review of any diff: the checklist skill, or code review excellence if comment tone matters.
• Trimming agent-written code: the over-engineering review.
• Hands-off pull request upkeep: the PR babysitter or GitHub review iteration.
• Report-only review you can trust not to post: PR finalize or Cherry Studio PR review, as models to adapt.
• Your own rules: copy the backend or Cherry Studio structure and replace the project rules.

Combining two is normal. A checklist skill and the receiving-feedback skill do not overlap, and a reviewer subagent pairs well with the over-engineering pass. Browse the full code review topic for more, and see the Claude Code install options to add any of these.