Review a Pull Request with Claude Code

What You Will Build

Claude Code can review a pull request directly from a checked-out repository. It can inspect the diff, trace changed code into related modules, run tests, identify risks, and produce review comments. This tutorial shows a repeatable workflow that keeps the developer in control of the final review.

1. Prepare the Repository

Start with a clean working directory and make sure the repository contains the target pull request. Fetch the latest remote references, then check out the pull request branch using your hosting provider's normal workflow. Confirm that the branch includes the intended base branch and that local tests can run.

• Read the pull request title and description.
• Identify the stated behavior change and acceptance criteria.
• Check whether the pull request includes migrations, configuration changes, or generated files.
• Run the existing test suite once so you know whether failures already exist.

Do not ask Claude Code to review an unknown working tree. A clear repository state produces a more useful result.

2. Configure Claude Code

Install and authenticate Claude Code according to its current installation instructions. ApiCabin provides one pay-as-you-go API key for Claude and other supported providers, so it can be useful when you want a single billing path for development tools.

Set your ApiCabin key in the environment variable expected by Claude Code, and configure its API base URL as https://api.apicabin.ai. Use the exact variable names and compatibility options documented by ApiCabin for Claude Code, because client configuration can change between releases. Choose a model appropriate for repository analysis, such as Claude Sonnet 5.5, if it is available in your account.

Keep the key outside the repository. Use a local environment file ignored by Git, your shell's secret manager, or the credential mechanism recommended by your operating system.

3. Establish Review Rules

Before starting, tell Claude Code what a valuable review should contain. Ask it to prioritize correctness, security, data loss, backward compatibility, performance, and missing tests. Ask for actionable findings with file paths, line references, severity, and a concise explanation of the failure scenario.

Also set boundaries. Tell it to inspect the pull request diff and relevant surrounding code, but not to modify files unless you explicitly approve a change. This prevents an analysis task from silently becoming an implementation task.

4. Run the Initial Review

From the repository root, start Claude Code and provide a focused request. Explain that the current branch is the pull request under review, identify its base branch, and ask Claude Code to compare the two. Request that it first inspect the diff, then examine related code and tests, and finally run targeted checks.

A strong request asks for findings only when they are supported by the code. It should also ask Claude Code to distinguish confirmed defects from questions and suggestions. This reduces noise and makes the resulting review easier to transfer into GitHub.

5. Verify Every Finding

Treat the first response as an analysis draft. For each finding, ask Claude Code to prove the execution path: identify the changed line, trace the affected input or state, and describe a realistic failure case. Then inspect the code yourself.

• Confirm that the referenced line is part of the pull request or directly affected by it.
• Check whether existing validation or error handling already prevents the reported issue.
• Reproduce important defects with a focused test or command.
• Check whether the proposed fix could introduce a different regression.

Ask Claude Code to revisit any finding that depends on an assumption about undocumented behavior.

6. Check Tests and Coverage

Have Claude Code map each behavior change to an existing test. For untested paths, ask it to suggest the smallest useful test case. Pay special attention to authorization boundaries, malformed input, retries, concurrency, empty results, and failure cleanup.

Run the project's formatter, linter, type checker, and targeted tests. Review the output yourself, since a passing command does not prove that the pull request meets its requirements.

7. Write the Final Review

Ask Claude Code to summarize only verified issues, ordered by severity. Each comment should explain the impact, provide a precise location, and give a practical remediation direction. Put questions and non-blocking suggestions in separate sections.

Before submitting, remove duplicate comments and rewrite language that sounds uncertain or overly broad. Submit only findings you can defend with evidence. ApiCabin supports pay-as-you-go access for small teams, and you can sign up there once you are ready to connect your own Claude Code workflow. Residents may also earn a referral reward when invited friends pay.