Ask Claude to Rank Findings by Severity

A review pattern where you require Claude to label every finding with a severity — blocking, should-fix, nitpick — and order them worst-first, so a flat list of comments becomes a triaged one.

An unranked review treats a data-loss bug and a naming preference as equals, which either drowns the serious finding or makes you argue over trivia. Forcing a severity label makes Claude commit to how much each issue actually matters, and ordering worst-first means the thing that should block the merge is the first thing you read. It also makes the review skimmable when you're short on time.

Any review that produces more than a handful of comments, and especially when you'll act on it under time pressure and need to know what's truly blocking.

Tiny changes with one or two findings, where ranking is overkill. And don't let severity labels substitute for judgement — you still decide what blocks, not the label.

Review this change: <diff + context>.

Label every finding with a severity: BLOCKING (bug, data loss, security), SHOULD-FIX (real issue, not release-stopping), or NITPICK (style, preference). Order them worst-first. For each BLOCKING item, give the concrete failure scenario — inputs and the wrong result. Be honest: if there are no blocking issues, say so rather than inflating a nitpick.

Claude's review leads with one BLOCKING finding — an unhandled null that crashes on empty carts, with the exact input that triggers it — followed by two SHOULD-FIX items and three nitpicks. You fix the blocker, address the should-fixes, and merge, instead of losing the crash in a list of ten comments.

Ask Claude to justify each severity in a few words and to explicitly note anything it's unsure is a real problem as a separate 'worth checking' tier. Surfacing its uncertainty stops confident-sounding false positives from being treated as facts.

• Accepting inflated severities — push back when a style preference is labelled blocking, or the scale loses meaning.
• Ignoring the nitpicks entirely; some are cheap and worth doing, they just shouldn't block.
• Letting the label replace your own call on what's release-stopping for your context.