Claude Code /review: Let AI Do Your Code Review

What Is /review

Code review is one of the most important parts of the development workflow — and also one of the most frequently skipped.

The reasons are practical: reviewers are busy, deadlines are tight, PRs pile up. Some teams even develop a tacit “rubber stamp” culture — reviews become a formality.

/review turns Claude Code into your Code Reviewer. It pulls PR details and diffs, then reviews your code like a senior developer across five dimensions: code quality, project conventions, performance, test coverage, and security.

It’s not replacing human reviewers — it’s adding an AI checkpoint before human review.

How to Use /review

Review a Specific PR

/review 123

Claude Code will:

Run gh pr view 123 to get PR details (title, description, author, etc.)
Run gh pr diff 123 to get the full diff
Analyze the changes and output structured review comments

List Open PRs

/review

Without arguments, Claude Code runs gh pr list to show all open PRs in the current repository, then you choose which one to review.

Prerequisites

/review depends on GitHub CLI (gh). Before using it, make sure:

gh is installed: brew install gh (macOS)
You’re logged in: gh auth login
You’re in a Git repository

What /review Examines

/review covers five dimensions:

Dimension	Focus Areas
Code Correctness	Logic correctness, edge case handling, potential bugs
Project Conventions	Adherence to the project’s code style and patterns
Performance Impact	Performance issues like N+1 queries, unnecessary loops
Test Coverage	Whether changes have corresponding tests, test sufficiency
Security	Injection, XSS, sensitive data exposure, and other security risks

Review results are presented in clear sections with bullet points:

PR Overview — what the PR does
Specific Suggestions — what can be improved and how
Potential Risks — issues to watch out for

Real-World Example

Consider a real scenario — your colleague submitted a PR adding user search functionality:

/review 42

Claude Code might output something like:

## PR Overview

PR #42 adds search functionality to the user management page, including a frontend search component and backend API endpoint.

## Code Quality

- The searchUsers function uses string concatenation in SQL queries; switch to parameterized queries to prevent SQL injection
- Search results lack pagination, which may cause performance issues with large datasets

## Project Conventions

- The new API route naming style is inconsistent with existing routes (uses camelCase instead of kebab-case)

## Test Coverage

- Missing tests for search edge cases (empty string, special characters, overly long input)

## Security

- Search input has no length limit or content validation

How /review Works Under the Hood

Looking at the source code, /review is a prompt-type command — it essentially injects a carefully crafted code review prompt into the conversation.

You are an expert code reviewer. Follow these steps:

1. If no PR number is provided, run gh pr list to show open PRs
2. If a PR number is provided, run gh pr view <number> to get PR details
3. Run gh pr diff <number> to get the diff
4. Analyze the changes and provide a thorough review

This means /review doesn’t rely on any special internal mechanism — Claude uses its regular tools (Bash, Read, Grep, etc.) to complete the review. It also means you can follow up during the review, ask Claude to explain a suggestion, or request focus on a specific aspect.

Three Review Commands Compared

Claude Code actually has three review-related commands for different scenarios:

/review — General PR Review

Feature	Details
Reviews	GitHub PRs
Runs	Locally
Dimensions	Code quality, conventions, performance, testing, security
Duration	A few minutes
Cost	Normal token usage
Best For	Daily PR reviews

/ultrareview — Deep Bug Hunter

/ultrareview 123    # Review a specific PR
/ultrareview        # Review current branch

Feature	Details
Reviews	PR or current branch (vs main branch fork point)
Runs	Cloud (remote Claude Code session)
Dimensions	Focused on finding and verifying bugs
Duration	10-20 minutes
Cost	Separate quota; Free/Pro includes free reviews, then Extra Usage billing
Best For	Deep review before major feature launches

/ultrareview is fundamentally different from /review — it launches a “bughunter fleet” in the cloud, with multiple AI Agents analyzing your code in parallel, each focusing on different angles. After finding potential bugs, it verifies them before returning consolidated results.

This command is controlled by a feature flag and may not be visible to all users.

/security-review — Security-Focused Review

/security-review

Feature	Details
Reviews	Current branch (vs origin/HEAD)
Runs	Locally
Dimensions	Pure security perspective
Duration	A few minutes
Cost	Normal token usage
Best For	Pre-deployment security checks

/security-review is laser-focused on security issues only:

Input Validation: SQL injection, command injection, XXE, template injection, path traversal
Auth/AuthZ: Authentication bypass, privilege escalation, session management
Secrets Management: Hardcoded secrets, weak encryption, key leakage
Code Execution: RCE, deserialization, eval injection, XSS
Data Exposure: Sensitive data leaks, log exposure

It has strict false-positive filtering — only vulnerabilities with confidence scores of 8/10 or above are reported. Each vulnerability includes severity level (HIGH/MEDIUM/LOW), description, exploit scenario, and fix recommendation.

/security-review doesn’t require the gh CLI — it uses git diff directly.

How to Choose Between the Three

Daily PR review              →  /review 123
Deep check for major features →  /ultrareview 123
Pre-deployment security scan  →  /security-review

They’re not mutually exclusive — use them in combination. For example, before a major feature launch:

Run /review for a general review pass
Run /security-review for a dedicated security scan
For critical features, use /ultrareview for deep bug hunting

Practical Tips

Tip 1: Follow Up After Review

The review results from /review aren’t the end. You can continue the conversation:

"Can you elaborate on the SQL injection issue? Show me a fix example"
"Beyond the issues you mentioned, is the overall architecture of this PR sound?"
"Format the review comments as PR comments I can post"

Tip 2: Focused Review

If you only care about a specific aspect, specify it in the arguments:

/review 123 focus on performance
/review 123 only look at security issues

/review appends your additional instructions to the review prompt.

Tip 3: Combine with /diff

If you haven’t created a PR yet, use /diff to see the current session’s changes, then ask Claude to review manually:

Review the changes I just made, especially from a security perspective

Tip 4: Automate the Review Flow

Combine with /hooks to automatically trigger reviews at specific moments. For example, remind yourself to review before a session ends:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '{\"systemMessage\": \"Reminder: if this session has code changes, consider running /review or /security-review\"}'"
          }
        ]
      }
    ]
  }
}

Final Thoughts

The value of code review is undeniable, but the biggest barrier to getting reviews done is time cost.

/review brings that cost close to zero — a few minutes for a review covering five dimensions. It’s not perfect and can’t replace the judgment of a domain-experienced human reviewer, but it can:

Filter out obvious issues before human review
Remind you of tests and security concerns you might have overlooked
Give you quick feedback when no one is available to review

Use AI as your first-round reviewer, and let human reviewers focus on higher-level architecture and business logic decisions. That’s what human-AI collaboration should look like.