Does this replace human code review?

No. It replaces the slow first pass, not the reviewer. Claude is fast at surfacing correctness gaps, edge cases, and the 3am operability bug, but it can't own the approve — a human is the author of record on the merge, and a human has the context and accountability the sign-off requires. Use it to get to the hard questions faster, not to skip them.

How do I trust Claude's findings if it can be confidently wrong?

You don't trust them — you verify them. Claude will flag a "bug" that isn't, because it sometimes misreads control flow or misses a guard that already exists. Make it point you at the exact lines that prove each finding is real before you post a word; if it can't show you the code, drop the finding. The verification step is what turns a confident guess into a review comment worth sending.

Can it review against our team's conventions, not just generic best practice?

Yes — that's what CLAUDE.md is for. Put your conventions, error-handling patterns, and house rules in your project's CLAUDE.md (see the project-context playbook) and Claude reviews the diff against your standards instead of a textbook's. Without it you get generic feedback; with it you get a reviewer that knows how your codebase is supposed to look.

Should I run this on my own code before I open the PR?

Yes, and it's one of the highest-value ways to use it. Running the adversarial review on your own branch before you open the PR lets you catch your own worst-case bug in private, fix it quietly, and open a cleaner PR — which means your human reviewer spends their attention on the genuinely hard calls instead of the misses you could have caught yourself.

Review a PR like a skeptical senior — before you approve

when to reach for this

A PR lands in your queue and you've got fifteen minutes and a hundred lines of someone else's reasoning to vet. The obvious failure is the rubber stamp — skim it, trust the tests, approve. Claude makes a sharp first pass cheap: feed it the diff, tell it to assume there's a bug, and let it probe correctness, edge cases, security, and "what pages someone at 3am." The catch — and it's the whole guardrail — is that Claude will assert a non-bug with total confidence, so you verify every finding against the real code before you act on it. It speeds up the review; it doesn't own it. You do.

gather this first

The diff or PR itself — paste it into the chat in Claude Desktop, or open the branch in Desktop so it reads the actual changed files in context, not just the patch.
The intent: a sentence or two on what the change is meant to do. A reviewer who doesn't know the goal can only check syntax; one who knows it can check whether the code meets it.
Your CLAUDE.md (from the project-context playbook) so Claude reviews against your real conventions — your error handling, your patterns, your house rules — not generic best practice.

the workflow

Feed the diff and ask for a skeptical review by dimension

Open the branch in Claude Desktop and paste the diff into the chat. Don't ask "is this okay" — ask for a structured review organized by the dimensions that actually break in production, so nothing important falls through a vague once-over.

you ask

Here's the diff and what it's meant to do: [intent]. Review it like a skeptical senior engineer, organized by dimension — correctness, edge cases, security, and operability (what pages someone at 3am). For each issue give me the file and line, why it's a problem, and the severity. Skip the nitpicks unless they're real bugs.

what you get back A review grouped by dimension with file:line pointers, a reason, and a severity for each finding — a structured read of the diff, not a vague "looks good to me."

Naming the dimensions is what forces coverage. "Review this" gets you a shrug; "check correctness, edge cases, security, and operability" gets you the 3am bug.
Push it to be adversarial — assume there's a bug

A reviewer that wants to approve finds nothing. Flip its stance: tell it to assume a bug exists and hunt for the worst one. The framing is the trick — it surfaces what a polite read glides past.

you ask

Now assume this diff has at least one real bug and your job is to find the worst one. Where would it break under load, bad input, a race, or a partial failure? Walk me to the single most dangerous issue and show me exactly how it goes wrong.

what you get back A concrete worst-case — the input or timing that breaks it, traced through the actual code path — flushed out by the adversarial framing rather than glossed over by a friendly read.

If it comes back with "I found nothing serious," be suspicious — on a non-trivial diff that usually means it didn't look hard enough, not that the code is flawless.
Have it draft line-anchored review comments

Turn the findings into specific, postable comments — anchored to a line, written the way you'd phrase them on the PR — so the output is something you can actually use, not a wall of prose you'd have to re-transcribe.

you ask

Draft the review comments for the real issues — each anchored to a specific file and line, phrased the way I'd post it on the PR: what's wrong, why it matters, and the concrete fix or question. Keep them sharp and specific.

what you get back A set of line-anchored draft comments — concrete, specific, and posting-ready — that you can carry straight into the PR after you've checked them.
Verify every material finding against the code — kill the false positives

This is the step that makes the rest safe. Claude will flag confident "bugs" that aren't — a guard that already exists, a case the framework handles, a misread of the control flow. Check each material finding against the real code before you post a word.

you ask

For each issue you flagged, point me at the exact lines that prove it's real — the code that creates the problem, not a description of it. If you can't show me the lines, say so and we'll drop that finding.

what you get back Each finding either grounded in specific lines you can confirm yourself, or honestly retracted — the false positives killed before they reach the author as a wrong, confidently-worded comment.

This is the guardrail, not optional polish. Posting an unverified finding wastes the author's time and burns your credibility as a reviewer — verify, then comment.
Ask for the test that would have caught the real bug

For each genuine bug that survived verification, ask for the one test that would have caught it. It both proves the bug is real (the test fails on the current code) and gives the author a concrete next step instead of just a complaint.

you ask

For the real bug we confirmed, write the single test that fails on the current code and would pass once it's fixed. I'll attach it to the review so the fix has something to prove against.

what you get back A failing test that pins the confirmed bug — turning "I think this is broken" into "here's the red test that proves it," which is a far stronger review comment than prose alone.

make it your own

Pre-PR self-review: run this whole loop on your own branch before you open the PR — catch your own 3am bug in private, ship a cleaner PR, and spend your reviewer's attention on the hard calls instead of the obvious misses.
Security-focused pass: narrow the lens to one dimension — "review only for security: injection, authz gaps, secrets in the diff, unsafe deserialization" — when the change touches auth, input handling, or anything that crosses a trust boundary.
Turn your checklist into a reusable prompt or skill (Power Track): capture your team's review dimensions and conventions as a /review slash command or a skill so every review starts from the same skeptical, house-specific checklist (see the Features tab).

watch out for

Claude reviews; you approve. It's a first-pass reviewer, never the approver — a human owns the sign-off because a human is the author of record. The faster the first pass, the more it matters that the final call stays yours.
It will assert a non-bug with full confidence. A confidently-worded finding is not a verified one — Claude misreads control flow and flags guards that already exist. Verify every material finding against the real lines before you comment, or you'll send the author chasing a ghost.
Don't let it rubber-stamp. If the review comes back clean on a non-trivial diff, it almost certainly didn't dig — push it to be adversarial and assume a bug, rather than taking "looks good" as a result.
Keep proprietary code in-boundary. The diff may carry customer data, secrets, or NDA'd architecture — keep it in an environment your company approves, and remember the open folder is the boundary Claude reads from.

you'll end up with A sharper review in minutes instead of an hour — the obvious bugs caught, the worst case actively probed, the false positives killed, and the comments drafted and verified — with a human still making the call on the merge.

Questions people ask

Does this replace human code review?: No. It replaces the *slow first pass*, not the reviewer. Claude is fast at surfacing correctness gaps, edge cases, and the 3am operability bug, but it can't own the approve — a human is the author of record on the merge, and a human has the context and accountability the sign-off requires. Use it to get to the hard questions faster, not to skip them.
How do I trust Claude's findings if it can be confidently wrong?: You don't trust them — you verify them. Claude will flag a "bug" that isn't, because it sometimes misreads control flow or misses a guard that already exists. Make it point you at the exact lines that prove each finding is real before you post a word; if it can't show you the code, drop the finding. The verification step is what turns a confident guess into a review comment worth sending.
Can it review against our team's conventions, not just generic best practice?: Yes — that's what `CLAUDE.md` is for. Put your conventions, error-handling patterns, and house rules in your project's `CLAUDE.md` (see the project-context playbook) and Claude reviews the diff against *your* standards instead of a textbook's. Without it you get generic feedback; with it you get a reviewer that knows how your codebase is supposed to look.
Should I run this on my own code before I open the PR?: Yes, and it's one of the highest-value ways to use it. Running the adversarial review on your own branch before you open the PR lets you catch your own worst-case bug in private, fix it quietly, and open a cleaner PR — which means your human reviewer spends their attention on the genuinely hard calls instead of the misses you could have caught yourself.