Code Review Checklist Generator

A checklist turns review from vibes into a process

Most code review happens on instinct - a reviewer skims the diff, notices what jumps out, and approves. Instinct catches obvious problems and misses the systematic ones: the missing null check, the unparameterized query, the endpoint that forgot an authorization check. A checklist fixes this by making review comprehensive instead of opportunistic. It ensures the same things get checked every time, regardless of how tired the reviewer is or how much they trust the author.

This generator builds a checklist tuned to your actual context - the language, whether tests are included, and whether the change is security-sensitive, performance-sensitive, or touches a public API. A checklist for a security-sensitive TypeScript endpoint should look nothing like one for a language-agnostic refactor. The tool also gives you a live interactive version you can tick through as you review, and a 'review prompt' mode that turns the whole thing into an instruction you can hand to Claude Code.

What every review should check, regardless of stack

• Correctness - does the change actually do what the PR description claims, including the edge cases?
• Clarity - could a new reader follow the intent without asking the author what it means?
• Scope - is the change small and focused enough to review in one sitting, or is it three changes in a trenchcoat?
• No leftovers - dead code, commented-out blocks, and stray debug output are all noise that should not merge.
• Error handling - failure paths are handled deliberately, not left to crash or silently swallow.

Security review is where checklists earn their keep

Security bugs are exactly the kind of systematic issue that human instinct misses and a checklist catches. The high-frequency ones are boring and repeatable: unvalidated input, string-built SQL, unescaped output, a secret committed to the repo, an endpoint that checks authentication but forgets authorization. One item deserves special emphasis - any endpoint that holds or spends a paid API key is a spend-exposure surface and must never ship without authentication, rate limiting, and a locked origin allowlist. A single unauthenticated proxy with a funded key and open CORS is an open faucet to the entire internet, and it can drain a budget overnight.

Performance and public-API items are situational

Not every change needs a performance pass or an API-compatibility pass, which is why they are toggles. Turn on performance review when the change touches a hot path or something that runs at scale - that is where N+1 queries, needless allocations, and unbounded loads actually matter. Turn on public-API review when the change touches a signature, schema, or contract that other code depends on - that is where a silent breaking change becomes someone else's outage. Applying these checks to every trivial change just trains reviewers to ignore the checklist, so scope them to when they earn attention.

Using the checklist as a Claude Code review prompt

The 'review prompt' mode is the highest-leverage feature here. It prepends an instruction that tells Claude Code to go through the checklist item by item against a diff and reply pass, fail, or n/a with a one-line reason for each, failures first. This gives you a fast, structured first-pass review before a human ever looks at the code - the model catches the mechanical issues (missing error checks, unparameterized queries, stray debug output) so the human reviewer can spend their attention on design and intent, which is where human judgment actually adds value.

1. Generate the checklist with the toggles that match your change, then switch to 'Review prompt' mode.
2. Paste the prompt into Claude Code followed by the diff (git diff or the PR patch).
3. Read the failures first - fix the real ones, dismiss the false positives with a note.
4. Hand the human-reviewed diff off with the checklist attached so the next reviewer sees what was already checked.

Keep the checklist a tool, not a bureaucracy

A checklist is a floor, not a ceiling. It guarantees the systematic issues get checked; it does not replace judgment about design, architecture, or whether the change is even a good idea. The failure mode is treating the checklist as the whole job - ticking every box and approving a change that passes every item but solves the wrong problem. Use the checklist to clear the mechanical concerns fast, then spend your freed-up attention on the questions no checklist can answer: is this the right approach, and will we be glad we did it this way in six months?