Workflows
Review Your Branch Before Pushing
You've been heads-down for two hours. Before you push, give Claude Code your diff and ask for a second opinion. It reads the whole branch and surfaces what you missed.
On this page (5 sections)
How it works
Step 1 of 6
You think you're done.
Two hours of focused work. Thirty lines of diff. It compiles.
Step 2 of 6
You ask Claude to look at it before you push.
Two minutes of someone else's eyes. Free.
Step 3 of 6
Claude reads the full diff against main.
Every changed file, every removed line, every signature change.
Step 4 of 6
Claude flags what you missed.
A leftover console.log. An edge case you skipped. A function whose callers didn't get updated.
Step 5 of 6
You fix what's worth fixing.
Some flags you accept. Some you push back on. Quick.
Step 6 of 6
Clean push.
No 'fix typo' commit five minutes after the PR opens.
The prompt
Use this right before you push. Not after.
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
Read the branch (8 files, 142 lines added, 31 removed). Three things worth your attention, one nit.
Worth fixing
-
services/order/checkout.ts:88— you handlepayment.status === "succeeded"but not"requires_action". Stripe returns that for 3DS flows. Will silently fail for any EU card needing SCA. -
services/order/checkout.ts:142— you renamedprocessRefundtoissueRefundbutapi/webhooks/stripe.ts:67still 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. -
lib/email/templates.ts:23— leftoverconsole.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.
I'm about to request review on this PR. Here's the description I'm planning to use: [paste PR description] 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.
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.
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?
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.
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 follow on Substack