How to Review Code with Claude Code: From Generic Prompts to Repo-Aware Reviews

Claude Code writes code fast. It can also review code — but most developers use it wrong for review. They paste a diff into a chat, ask "is this OK?", and get a generic answer that misses the issues that actually matter in their repository. This guide shows how to get real, repository-aware code reviews out of Claude Code, and where a tool like CodeCrab automates the parts you would otherwise repeat by hand.

Can Claude Code review Pull Requests?

Yes — and it is good at it, because it runs locally with access to your whole codebase, not just the diff. Unlike a cloud review bot, Claude Code can follow callers, read the tests, check neighbouring modules and compare the change against how your project is actually built. The catch: out of the box it knows nothing about your project's rules. Everything below is about closing that gap.

Why a generic prompt fails on real repositories

The most common approach — pasting a diff and asking for a review — produces feedback that is technically correct and practically useless. It catches syntax issues and obvious bugs, but it cannot know:

• Your architecture rules. For example: "never touch the database from a controller" or "all side effects go through the event bus".
• Your conventions. Naming, error handling, logging, how you structure tests, which libraries are banned.
• Your history. The bug that shipped twice already, the migration that is mid-flight, the endpoint that must stay backwards compatible.

Without that context, the model reviews an idealized codebase instead of yours. The findings read well and miss the one thing a senior teammate would have caught instantly.

Step 1: Encode your rules as a review skill

Claude Code supports skills: reusable instruction files that shape how it approaches a task. A review skill is where your team's knowledge lives. A good one includes:

• Architecture boundaries — which layers may call which, and what is forbidden.
• Security checklist — authorization checks on every new endpoint, tenant filters on every query, no secrets in logs.
• Testing expectations — what must be covered, and which patterns your suite already provides.
• An output contract — a fixed markdown shape for findings, so results are comparable across reviews.

That last point matters more than it seems. When the model always answers in the same structure — verdict, findings with file, line, severity and a suggested fix — you can scan results in seconds and tools can parse them. CodeCrab uses exactly this idea: see our documentation on local skills and the output format.

Step 2: Give it the right scope

Review the diff, but let the model read around it. The most valuable findings come from outside the changed lines: a caller that now breaks, a test that no longer covers the new branch, a convention the change quietly violates. Prompts that work well:

• "Review the changes on this branch against main. Follow the review skill. Check callers of every modified function."
• "Review PR #123. Read the PR description and the comment thread first — the intent matters as much as the diff."

Step 3: Review before the Pull Request exists

The cheapest bug is the one that never reaches a PR. Run the review on your local changes before you push, fix what it finds while the context is fresh, and open a cleaner PR that your teammates can approve faster. We cover the full workflow in Pre-Push Code Review.

Step 4: Keep the engineer in control

The model investigates and suggests. You validate and decide. Treat every finding like a comment from a fast but junior reviewer: often right, occasionally confident and wrong. Never let a tool post to a Pull Request or merge without your approval — that judgment is the job.

Where CodeCrab fits

Everything above works by hand, but it is repetitive: fetching the PR, assembling the context, applying the skill, formatting the findings. CodeCrab is a desktop app that automates exactly that loop on your own machine:

• It pulls the PR or your local changes via the GitHub CLI, using your own credentials.
• It applies your per-repository profile and review skills to Claude Code automatically.
• It parses the structured output and shows each finding next to the exact line in the diff.
• Nothing leaves your laptop — no code retention, no invasive GitHub permissions.

Read how the pieces fit together in Code review that fits your workflow, or why local-first matters for private codebases in our next article.

KEEP READING

• Local-First AI Code Review: Why Enterprise Codebases Can't Rely on Cloud Review Bots

  Cloud review bots copy your diffs to vendor servers and ask for org-wide permissions. Here is how local AI code review and self-hosted PR review really differ, and what to verify before trusting either.

• AI Can Write Your Code. But Who Reviews It? The New PR Bottleneck

  AI made writing code cheap, but reviewing AI-generated code is now the bottleneck. Learn why PR queues grow, why rubber-stamping is risky, and how to review before the Pull Request.

• Code review that fits your workflow: local skills and repository-aware agents

  CodeCrab combines your existing local review skills with per-repository profiles and specialized agents, so you can review PRs and pre-push changes with the full codebase in context.

• PR Code Reviews: how CodeCrab unblocks your team in the AI era

  AI writes more code than ever, so review queues are the new bottleneck. Here is how CodeCrab reviews Pull Requests locally, with repo-specific skills and full engineer control.

• My PRs — Feedback: turn vague review comments into a clear fix

  Generic or unclear feedback on your Pull Request stalls you for days. CodeCrab investigates every comment with full local code context and hands you a ready-to-run fix prompt.

• Pre-Push Code Review: catch bugs before the Pull Request even exists

  The cheapest bug is the one that never reaches a PR. CodeCrab reviews your local changes with your repo's own profile and skills, so you push higher-quality code the first time.