Claude Code Guide
docsworkflows1 min read

Review Your Branch Before Pushing

Two hours heads-down? Before you push, give Claude Code your diff for a second opinion. It reads the whole branch and surfaces what you missed.

Shadman RahmanShadman RahmanPrincipal PM
2 minutes Claude Code Claude (any)By Shadman Rahman

how it works

  1. 01 / 06

    You think you're done.

    Two hours of focused work. Thirty lines of diff. It compiles.

  2. 02 / 06

    You ask Claude to look at it before you push.

    Two minutes of someone else's eyes. Free.

  3. 03 / 06

    Claude reads the full diff against main.

    Every changed file, every removed line, every signature change.

  4. 04 / 06

    Claude flags what you missed.

    A leftover console.log. An edge case you skipped. A function whose callers didn't get updated.

  5. 05 / 06

    You fix what's worth fixing.

    Some flags you accept. Some you push back on. Quick.

  6. 06 / 06

    Clean push.

    No 'fix typo' commit five minutes after the PR opens.

The prompt

Use this right before you push. Not after.

Try this prompt
Review my branch before I push. Diff against main and read the changed files. Look for: - Obvious bugs or missed edge cases (null/undefined paths, off-by-one, async race conditions) - Anything that changed signature or contract where the callers might not be updated - Debug statements, console.logs, commented-out code, or TODOs left in - Tests that are missing for new behavior Be specific. Cite line numbers, not vague concerns. If the branch looks clean, tell me that and stop. Don't invent problems.

What you get back

From Claude

Read the branch (8 files, 142 lines added, 31 removed). Three things worth your attention, one nit.

Worth fixing

  1. services/order/checkout.ts:88 — you handle payment.status === "succeeded" but not "requires_action". Stripe returns that for 3DS flows. Will silently fail for any EU card needing SCA.

  2. services/order/checkout.ts:142 — you renamed processRefund to issueRefund but api/webhooks/stripe.ts:67 still calls the old name. TypeScript caught it for me but only because I read both files. If callers are dynamic anywhere, this breaks at runtime.

  3. lib/email/templates.ts:23 — leftover console.log("EMAIL DEBUG", payload). I assume that's not meant to ship.

Nit, your call

utils/format.ts:14 — new formatCurrency helper has no test. The logic looks right by inspection but currency formatting has nasty locale edge cases (CHF, JPY without decimals). Worth a one-line test.

Nothing else jumped out. The Stripe webhook simplification looks intentional and clean. Push when you're ready.

Variations

Same shape, small twists.

Before requesting PR review
I'm about to request review on this PR. Here's the description I'm planning to use: Diff against main, read the changed files, and tell me whether the PR description matches what the code actually does. Flag anything I claimed in the description that the diff doesn't back up, or anything the diff does that I forgot to mention. Then check for the usual stuff: missed edge cases, leftover debug code, callers not updated.

Click a violet field and type your own details, then copy.

For a database migration
I'm about to run this migration on staging. Read the migration file and any code that references the affected tables. Tell me: - Is this reversible, and if not is that intentional - Will it lock a hot table for an unreasonable amount of time - Does any application code still reference columns or tables this drops or renames - Is the down migration actually correct Be paranoid. I'd rather you flag a non-issue than miss a real one for a migration.
Quick security check
Before I push, do a fast security pass on this diff against main. Check for: - Secrets, tokens, or API keys committed by mistake - User input that flows into a query, shell command, or file path without escaping - New endpoints that don't check auth - Logs that include sensitive data (passwords, tokens, full request bodies) If nothing pops, say so plainly. Don't manufacture a finding.

Tips and gotchas

Give it the PR description if you have one. Context changes what counts as missing. A "fix typo" PR shouldn't get the full edge-case treatment.

Demand line numbers. "There might be a race condition somewhere" is noise. "Race condition at checkout.ts:88 because X" is signal.

Don't ask it to write the missing tests in this pass. Review first, fix second. Mixing the two phases makes the review messier and the fixes sloppier.

Ready to try?

Copy and paste
Review my branch before I push. Diff against main and read the changed files. Look for: - Obvious bugs or missed edge cases (null/undefined paths, off-by-one, async race conditions) - Anything that changed signature or contract where the callers might not be updated - Debug statements, console.logs, commented-out code, or TODOs left in - Tests that are missing for new behavior Be specific. Cite line numbers, not vague concerns. If the branch looks clean, tell me that and stop. Don't invent problems.
Found this useful?Star claudecode-guide on GitHub

New guides, when they ship

One email, roughly weekly. CLAUDE.md templates, workflows I actually use, and the cut-for-length stuff that does not make the public guides. One-click unsubscribe.

Or read Product Field Notes, the Substack

On this page

The promptWhat you get backVariationsTips and gotchasReady to try?