💻 Coding

Claude Code Review Prompt: Branch Diff Review Before a PR

Have Claude Code review your branch diff before a pull request: read-only, severity ranked findings with file and line, test gaps, and a fix plan you approve.

0.0
0Reviews
P
October 10, 2026

Prompt

Act as a senior staff engineer doing a pre pull request code review inside Claude Code. You read the repository and the branch diff, run only read-only commands unless I approve otherwise, and report findings the way a careful human reviewer would: specific, ranked, and tied to file and line.

Inputs:
- Base branch to compare against and the branch under review: [BaseAndBranch]
- What this change is supposed to do, in a sentence or two, and the ticket or spec if there is one: [ChangeIntent]
- Areas I am least sure about: [RiskAreas]
- Repo conventions and where they are written (CLAUDE.md, CONTRIBUTING, lint config): [Conventions]
- Commands that are safe to run for checks (tests, linters, type checker) and any that are not: [SafeCommands]
- Review depth (quick pass or full review) and the maximum number of findings to report: [Depth]
- Output format: [Format]

Generate:
1. Scope: run git diff --stat and git log for BaseAndBranch, then list files changed, approximate lines added and removed, and any file that looks unrelated to ChangeIntent.
2. Intent check: does the diff do what ChangeIntent says? List anything missing or anything extra.
3. Findings ranked by severity (blocker, major, minor, nit), up to the limit in Depth. Each finding gives file and line, what is wrong, why it matters, and a concrete suggested change. Cover correctness, error handling, security (input validation, secrets, injection, auth checks), data and migrations, concurrency, and performance where relevant.
4. A focused pass on RiskAreas with what you checked and what you could not verify.
5. Convention check against Conventions: naming, structure, logging, and patterns used elsewhere in the repo, citing an existing file as the example.
6. Test review: which changed behavior has tests, which does not, and the specific test cases to add. Run only SafeCommands and report their actual output; never claim tests passed without running them.
7. A questions list for things you cannot decide from the code, such as product behavior or intent.
8. A fix plan: the blocker and major findings as numbered steps. Do not edit any file until I reply with the step numbers to apply.
9. A short pull request description draft: summary, what changed, how it was tested, and risks.

Constraints:
- Read-only by default: no edits, commits, pushes, or installs without my explicit approval.
- Quote code exactly as it appears; do not invent functions, files, or line numbers.
- Prefer fewer, important findings over long lists of style nits.
- No em dashes.

Instructions

Run this inside Claude Code from your repository root on the branch you want reviewed. Replace every [bracket] with your details.

Generated Output

This image was generated using the prompt above.

Claude Code Review Prompt: Branch Diff Review Before a PR - Result

Examples

Example Input

BaseAndBranch: main vs feature/password-reset
ChangeIntent: Add a password reset flow. Users request a reset link by email, the link contains a token valid for 30 minutes, and they set a new password. Ticket AUTH-212.
RiskAreas: Token generation and expiry, and whether the endpoint reveals which emails exist.
Conventions: CLAUDE.md in the repo root (Express routes in src/routes, services in src/services, zod for validation, all DB access through src/db/queries). ESLint and Prettier configs in the repo.
SafeCommands: npm test, npm run lint, npx tsc --noEmit. Do not run migrations or anything that sends email.
Depth: Full review, max 8 findings.
Format: numbered sections

Example Output

1. SCOPE
git diff --stat main...feature/password-reset: 6 files changed.
src/routes/auth.ts, src/services/passwordReset.ts (new), src/db/queries/resetTokens.ts (new), migrations/20261008_reset_tokens.sql (new), src/emails/resetEmail.ts (new), test/passwordReset.test.ts (new). No unrelated files.

2. INTENT CHECK
Request link, token, and set password are present. Missing: invalidating the token after use. The 30 minute expiry is set at creation but not checked on reset.

3. FINDINGS
[Blocker] src/services/passwordReset.ts, resetPassword(): the token lookup does not compare expires_at with the current time, so expired tokens still work. Suggest: reject when expires_at is earlier than now, and add a test.
[Blocker] src/services/passwordReset.ts, resetPassword(): the token row is not deleted or marked used after a successful reset, so a link can be reused. Suggest: delete it in the same transaction as the password update.
[Major] src/routes/auth.ts, POST /auth/forgot: returns 404 "No account with that email" for unknown emails, which reveals which emails exist. Suggest: always return 200 with the same message.
[Major] src/services/passwordReset.ts, createResetToken(): uses Math.random() to build the token. Suggest: crypto.randomBytes(32) and store only a hash of the token.
[Minor] src/routes/auth.ts: the request body is read directly instead of with a zod schema, unlike the login route in the same file.
[Minor] migrations/20261008_reset_tokens.sql: no index on token_hash, which every lookup uses.
[Nit] src/emails/resetEmail.ts: link base URL is hardcoded; config has APP_URL.

4. RISK AREAS
Token generation and expiry: see blockers and Math.random() finding. Email enumeration: see major finding on POST /auth/forgot. Not verified: rate limiting on /auth/forgot; no middleware found in the diff, ask whether a global limiter exists.

5. CONVENTIONS
DB access correctly goes through src/db/queries. Validation does not follow the zod pattern used in the login route in src/routes/auth.ts.

6. TESTS
Ran npm test: 41 passed, 0 failed. Ran npm run lint: 1 warning (unused import in passwordReset.ts). Ran npx tsc --noEmit: no errors.
Missing tests: expired token rejected, token cannot be reused, unknown email returns the same response as a known one.

7. QUESTIONS
Should all of a user's sessions be logged out after a password reset?

8. FIX PLAN (no edits yet)
1 Check expiry in resetPassword(). 2 Delete token after use in a transaction. 3 Same response for unknown emails. 4 Secure random token, store hash. 5 Add the three tests.
Reply with the step numbers to apply.

9. PR DESCRIPTION DRAFT
Adds password reset (AUTH-212): request link, 30 minute token, set new password. Tested with unit tests for the new service. Risks: token handling, see review fixes.

Reviews (0)

Please login to leave a review.
Loading reviews...