Claude Code Prompts for Code Review

AI reviewers fail in a specific way: they review politely. "Looks good, minor suggestion!" is not a review. These prompts force the opposite posture — severity-ordered checklists that stop at the first category with findings, security passes that follow the data instead of the checklist, and readability passes where every nit comes with its one-line rewrite. No praise, no summary. Pick the pass that matches your stage: correctness first, security before launch, readability last.

Review this diff as a skeptical senior engineer who has been paged at 3am because of 'harmless' changes. Check in order, stop at first category with findings: (1) correctness — what breaks at the boundaries: empty, null, huge, concurrent, offline; (2) failure behavior — what happens when the DB/network/dependency is down; (3) security — injection, auth bypass, secrets in logs, tenant leakage; (4) readability — names that lie, dead code. Per finding: file:line, severity (blocker/should-fix/nit), one-line problem, one-line fix. No praise, no summary.

Security review only, this diff. Check every input path: where does user-controllable data enter, and where does it end up (query, template, shell, redirect, file path, log)? For each, name the injection class that applies and whether the existing escaping/validation actually blocks it. Also: auth checks on every new route, tenant isolation on every new query, secrets handling, error messages that leak internals. Output a table: location, risk, evidence, fix. If you find nothing in a category, say 'checked, clean' — do not pad.

This diff is functionally done. Now review it for the next reader only: (1) names that mislead more than they explain; (2) comments that narrate the code instead of explaining why; (3) nesting deeper than 3 levels that could be early-returns; (4) functions doing two jobs; (5) changes unrelated to the stated purpose (should be a separate commit). Nit-level is welcome here — but every suggestion must come with the one-line rewrite.