Stop guessing what to check in a PR — 51 items that actually matter (free, interactive, MIT)
Projekta2A free interactive code review checklist with 51 items, 8 categories, a live Review Readiness score, PR templates, and guides for beginners and seniors. MIT licensed, no account required.
Code review is one of the few engineering practices where experience doesn't automatically make you better.
You can have ten years of reviewing PRs and still leave inconsistent feedback, miss security issues in auth code, or write comments that start arguments instead of conversations. The difference between a good reviewer and a great one isn't talent — it's a system.
Most teams don't have one. They have a vague shared understanding of "what good looks like," which means juniors are guessing, seniors are repeating themselves, and every PR review is a slightly different experience depending on who picks it up.
I built PR Review Canvas to fix that for my own workflow. It's a free, MIT-licensed code review kit with a 51-item interactive checklist, PR templates, guides for different experience levels, and annotated examples. No account, no install, no tracking.
Here's what's in it and how to use it.
The problem with most code review checklists
Search "code review checklist" and you'll find two kinds of results: a Gist with twelve bullet points written in 2018 and never updated, or a 5000-word article that covers everything so abstractly it helps nobody.
Neither solves the real problem, which isn't that developers don't know that they should check security. It's that they don't know what specifically to look for when checking security on a Tuesday afternoon when they have three other PRs in the queue.
A useful checklist does two things: it tells you what to look for, and it tells you why that thing matters. Without the why, a checklist is just a bureaucratic checkbox exercise that slows you down without improving the review.
Every item in PR Review Canvas has a reason attached. Not a vague "best practice" justification — a specific, honest explanation of what goes wrong when you skip it.
What's in the kit
The live interactive checklist is at projekta2.github.io/pr-review-canvas — open it now in another tab. No install. No account. Works offline after the first load.
Beyond the checklist, the repository contains:
- PR description templates (basic and advanced with risk/rollback sections)
- Reviewer guides for beginners, seniors, giving feedback, and receiving feedback
- Annotated examples of a good PR, a bad PR, and a full review transcript
- An anti-patterns reference — the 12 ways code review silently goes wrong
- Ready-to-paste templates for Notion, Obsidian, Linear, Jira, and GitHub Projects
MIT licensed. Fork it, adapt it, use it commercially.
The 8 categories — and why they're in this order
The structure isn't arbitrary. The categories map to the sequence an experienced reviewer's brain actually runs through:
| # | Category | What it covers |
|---|---|---|
| 1 | Context & Purpose | Does the PR explain what changed and why? |
| 2 | Architecture & Design | Does it fit the existing system? |
| 3 | Code Quality | Is the code clean, readable, and correct? |
| 4 | Testing | Are the right things tested? |
| 5 | Performance & Security | Any obvious risks at scale or security holes? |
| 6 | Documentation | Is the knowledge preserved? |
| 7 | Standards Compliance | Does it follow the team's conventions? |
| 8 | Final Considerations | Would you approve this at 3am? |
You start at the top because you can't evaluate architecture before understanding what the PR is trying to do. You can't judge code quality before knowing where it belongs in the system. The order isn't enforced — you can jump around — but it's there for a reason.
A few items I find most useful in practice:
From Context & Purpose: "You understand the problem this PR solves before reading the code." — Sounds obvious. It isn't. Reviewers frequently start reading code without understanding the problem, then judge the solution on aesthetics rather than fit.
From Performance & Security: "New endpoints respect existing authorization rules." — Bypassing a permission check is how privilege escalation happens. This is the item that catches things that pass CI but shouldn't pass code review.
From Final Considerations: "You'd be comfortable being paged about this code at 3am." — This is the gut-check that cuts through everything else. If you'd be nervous about this code in production, that nervousness is a signal worth listening to.
The Review Readiness score
The circular gauge in the sidebar updates in real time as you check items. It goes from 0% to 100% as you work through the 51 items.
What the score means — and what it doesn't:
The score is a prompt, not a gate. A PR with 40% readiness isn't necessarily bad — some categories simply don't apply. A security fix doesn't need documentation updates. A typo fix doesn't need performance analysis.
Use it to notice what you haven't looked at, not to block merges on a number. The category mini-bars in the navigation make it easy to see which areas you've covered and which you've skipped entirely.
Progress is saved in localStorage. Close the tab and come back — your progress is still there. Nothing leaves your browser.
How to use it — three modes
As an individual reviewer
Bookmark projekta2.github.io/pr-review-canvas and open it alongside your next PR. Run through the categories that apply. When you're done, use "Copy summary" to paste your progress as a review comment — it generates a plain-text checklist of what you checked and what you skipped.
For a fully offline copy with zero external dependencies, download checklists/interactive-checklist.html directly and open it from your file system.
As a team
- Fork the repository
- Open
checklists/pr-review-checklist-template.md— the blank, editable version - Remove items that don't apply to your stack; add items specific to your codebase
- Copy
templates/pr-template.mdinto.github/PULL_REQUEST_TEMPLATE.md— every PR starts from the same baseline
The value of a shared checklist isn't the checklist itself. It's that when a senior engineer leaves a comment saying "this doesn't handle the empty state," they can point to a specific item in the shared reference instead of re-explaining their reasoning from scratch. The checklist externalizes the knowledge that would otherwise live only in the senior engineer's head.
As a junior developer
Read guides/for-beginners.md before your first review. It's written for the exact moment after you've been assigned a PR and have no idea where to start. Then use the interactive checklist on a real PR — even if you can only check 15 of the 51 items, those 15 are better than nothing.
The 12 anti-patterns worth knowing
resources/code-review-antipatterns.md is the document I'd have wanted most as a junior reviewer. It covers the recurring ways code review goes wrong on both sides of the diff.
Context: PR Review Canvas grew from the same review fatigue that led me to build PR Focus Pro — a Chrome extension that triages and summarizes GitHub PRs with AI, BYOK, one-time payment.
🔌 Install PR Focus Pro from Chrome Web Store
A few that come up most often in teams:
Rubber stamping — approving a PR without actually reading it. Usually happens when the queue is long and the PR is from a senior engineer. The senior's seniority doesn't make the code correct.
Scope creep in review — using a code review to relitigate architectural decisions that were already made. A PR review is for the code in the diff, not for the design document from six months ago.
The nitpick spiral — spending 80% of review time on formatting and naming, then approving logic that has a race condition. Linters exist for a reason. Use them and save your review time for what they can't catch.
Asymmetric feedback — giving harsh written feedback that you'd never say in a conversation. Text strips tone. The phrases that feel neutral when you write them feel aggressive when the author reads them at 5pm on a Friday.
What I learned building it
The "why" matters more than the item. Early versions were just a list. Adding one sentence of reasoning per item made reviewers stop and think "does this reason apply to this PR?" instead of mechanically ticking boxes. That shift in behavior was the whole point.
The anti-patterns document gets shared more than the checklist. Offline capability was more requested than I expected too — one HTML file with no network dependency turned out to be a real need in enterprise environments. But the anti-patterns list is the thing people forward to teammates after a bad review. It names what happens in every team but nobody says out loud, which makes it more shareable than a structured checklist ever will be.
Try it
Open the interactive checklist →
No install. No account. No tracking. Open it, check things off, export your notes.
If you find it useful, a star on GitHub helps other developers find it.
If you want to contribute — a new checklist item, a translation, a template for a tool that's missing — the good first issues are labeled and ready. First external contributor gets a feature in Build Logs.
If you review PRs regularly and want to exchange a real review with another developer, the Summer Review Swap is open through July — post your PR, review one in return.
What's the code review anti-pattern you see most often in your team? The rubber stamp and the nitpick spiral are the ones I hear about most — curious whether that's universal or whether it varies by team size.