Claude Code code review for QA is useful when you want one more technical review pass before a pull request reaches teammates. Anthropic’s current Code Review documentation says automated PR review is available in research preview for Team and Enterprise subscriptions, but it also says other plans can still review a diff locally with /code-review. That makes it a practical option for QA engineers and SDETs who want to inspect test changes, catch weak assertions, and improve a branch before human review begins.
This guide turns those official docs into a repeatable workflow. You will choose the right diff scope, run a local review, interpret the findings with a QA lens, rerun deterministic checks, and preserve evidence that the branch is actually safer after the cleanup.
When to use Claude Code code review for QA
Use this workflow when a branch changes Playwright tests, Selenium utilities, API assertions, fixtures, test data builders, or CI test scripts. Local review is most valuable when you already have a real code diff and want help spotting issues such as missing edge cases, duplicated test setup, brittle waits, or unnecessary complexity.
It is not a replacement for running the suite. Anthropic’s docs describe review as a way to analyze the diff and propose fixes, but the final release signal still comes from deterministic test results, CI output, and human review.
What the official docs support right now
The current Anthropic documentation says the local /code-review command reviews your branch’s commits ahead of upstream plus uncommitted changes by default. It can also target a file path, branch name, pull request number, or a ref range such as main...my-feature. The docs also say you can use --comment to post findings as inline PR comments and --fix to apply findings back to the working tree.
One detail matters for QA teams: the same page says local review follows CLAUDE.md but does not read REVIEW.md. If your team keeps test-review rules in REVIEW.md for hosted PR review, copy the most important test standards into CLAUDE.md or restate them in the session before you trust the local pass.
Step 1: Pick the right diff scope
Start with a narrow review target. Reviewing every file in a large branch usually produces noise. For QA work, the best scope is often the changed test package or the exact pull-request diff against the base branch.
If your branch is already based on the correct upstream, the default local review scope is usually enough. If not, pass an explicit ref range so the tool reviews the same code your future pull request will contain.
Copy Example
/code-review
/code-review main...qa-flaky-login-fix
/code-review tests/ui/login.spec.ts
/code-review --fix
Use --fix only after you understand the findings. QA code often contains intentional setup and assertion patterns; blindly applying every cleanup can remove useful test intent.
Step 2: Give Claude the QA context before reviewing
Before running the review, tell Claude what kind of problems matter. The common workflows documentation shows Claude Code is effective when you provide explicit task framing and then verify results. For a test review, that means naming the risk areas directly.
A short instruction like this is enough: review this diff for brittle waits, weak assertions, missing negative coverage, accidental test-only secrets, and changes that could increase flakiness. Ask it to prioritize correctness and maintainability over style.
If your repository already has a CLAUDE.md, add stable guidance such as preferred locator strategy, forbidden fixed delays, required assertion depth, or minimum evidence for changing retry logic. That reduces repeated prompting across branches.
Step 3: Read the findings like a QA reviewer
Do not treat the first review response as a verdict. Treat it as a shortlist of issues to validate. Good findings usually point to a concrete failure mode: a test asserts only status code, a UI assertion ignores visible behavior, or a fixture change leaks shared state across tests.
Sort findings into three buckets:
- Likely correctness risks: missing validation, broken flow assumptions, invalid setup, or a cleanup that changes behavior.
- Flakiness risks: timing assumptions, hidden cross-test coupling, unstable selectors, or assertions that race the UI.
- Optional cleanups: simplification or reuse ideas that can wait if they do not reduce immediate risk.
If a finding does not tie to observable behavior, ask Claude to explain the exact failure scenario and name the file and lines involved. If the explanation stays vague, do not merge a fix only because it sounds plausible.
Step 4: Rerun focused deterministic checks
Anthropic’s testing workflow examples emphasize running and verifying tests after changes. That is the part many teams skip when AI review feels convincing. For QA branches, rerun the smallest deterministic validation set that can prove the suspected issue and the proposed fix.
Examples include rerunning one affected Playwright spec, one API contract test module, or one smoke CI job locally. If the review suggested stronger assertions, make the change and rerun the relevant scenario. If the review suggested deleting a wait or helper, prove the test still passes without increased variance.
Keep the validation bounded. You are not trying to replace full CI locally; you are trying to confirm the review improved the branch rather than merely changing it.
Step 5: Clean up the pull request before teammates see it
Once the focused checks pass, summarize what changed because of the review. A strong QA pull request note might say: local Claude review flagged one weak assertion and one shared-state fixture issue; both were fixed; targeted tests reran; no additional flaky wait changes were accepted without reproduction.
If your team uses hosted Claude Code Review later, remember the docs say hosted review can use REVIEW.md while local review cannot. That means local and hosted findings may differ. Document that difference so nobody assumes the local pass enforced every repo-specific PR rule.
Screenshot checklist
- Terminal output showing the exact
/code-reviewtarget - One finding tied to a test file and clear failure mode
- The diff after you apply a validated fix
- The targeted test rerun result
- The final pull request summary or branch notes
Common mistakes
- Reviewing too much at once: broad diffs dilute useful findings.
- Confusing plausibility with proof: a convincing explanation still needs a deterministic check.
- Relying on REVIEW.md locally: Anthropic’s docs say local review does not read it.
- Using –fix too early: apply fixes only after you understand the proposed change.
- Skipping evidence capture: without a rerun or artifact, the review added opinions, not proof.
Best practices for teams
- Keep reusable QA review rules in
CLAUDE.mdif local review is part of your workflow. - Use local review before opening the PR, then use normal human review and CI afterward.
- Prefer small branches so each finding maps to a specific test risk.
- Record which findings were accepted, rejected, or deferred and why.
- Use targeted reruns for validation, then let the full pipeline act as the final gate.
References
- Anthropic Claude Code: Code Review
- Anthropic Claude Code: Common Workflows
- Anthropic Claude Code: Overview
FAQ
Can I use Claude Code review without the hosted PR review setup?
Yes. Anthropic’s current docs say you can review a diff locally with /code-review without installing the GitHub App.
Does local review read REVIEW.md?
No. The Code Review documentation says local review follows CLAUDE.md but does not read REVIEW.md.
Should QA engineers use –fix automatically?
No. Review the finding first, then rerun a focused deterministic check before accepting the change.
What should I validate after a suggested test fix?
Rerun the smallest reliable test scope that proves the claimed improvement, then rely on CI and human review for the final gate.
Conclusion
Claude Code code review for QA works best as a disciplined pre-PR review layer. Keep the scope tight, give Claude explicit test-risk context, validate each accepted finding with deterministic checks, and carry the cleaned-up branch into normal CI and human review. That approach gets value from the tool without mistaking AI review for final evidence.