Code Review Checklist Generator

What this tool does

Most teams use a single generic code-review checklist for every PR. That's a hidden cost: a security PR has different review priorities than a refactor; a Go PR has different idioms to check than a TypeScript PR; a feature PR needs feature-flag and telemetry checks that a bugfix doesn't. A generic 10-item checklist forces reviewers to either skip half the items (because they don't apply) or skim every PR identically (so the items that do matter get less attention).

This generator outputs a checklist tailored to two axes: the language of the change and the type of change. It also lets you scope by depth (quick / standard / deep) and toggle optional dimensions (testing, docs, accessibility, internationalization). Output as Markdown that pastes directly into a GitHub, GitLab, or Bitbucket pull request — the checkboxes render as interactive checkboxes inside the PR.

How to use the output

1. Paste into the PR description. The first reviewer or the author ticks items off as they verify them. Items left unchecked are visible to the next reviewer.
2. Or paste as a review comment. Same effect, but the checklist lives with the review rather than the PR description.
3. Or save as .github/pull_request_template.md in the repo to apply the checklist to every PR automatically. Use this for the high-traffic file types in your repo — the checklist is most valuable when it shows up by default.

The five things every code review should catch

Whatever language and PR type you pick, every good review confirms these five things at minimum. The generator includes them in the baseline for every checklist:

• Correctness. Does the code do what the PR title says it does? Has the author thought about edge cases?
• Tests. Are there tests for the new behavior? Do existing tests still pass? Has anything that's hard to test been made easier to test?
• Readability. Will a teammate understand this code in six months without a meeting? Are names, comments, and structure clear?
• Security. Does the change handle untrusted input safely? Are auth and authz boundaries correct?
• Reversibility. If this breaks in production, can it be rolled back safely? Is there a feature flag or kill switch?

The tailored items the tool adds (TypeScript narrowing, Python type hints, Go context plumbing, SQL index review, etc.) sit on top of those five, not in place of them.

If you're rebuilding your review process this quarter, also see our companion guide to designing technical screens and our other developer tools — including a regex tester, cron builder, and git command finder.