The pull request checklist from open to merge
A pull request checklist is a short list of checks the author, the reviewer, and whoever merges each run before a PR moves forward, so nothing ships half-reviewed and nothing sits half-forgotten.
This page is maintained by GitLoom, a Slack-first pull request notification tool that watches your GitHub repos and sends one quiet daily digest: which PRs are stuck, what shipped, and what your team did this week.
Three passes, three owners
Author checks before the PR opens, reviewer checks while it is open, merge checks before and after it lands. Check items off as you go; nothing is saved, it resets on reload.
Before you open the PR
The goal: a pull request a reviewer can say yes to in one pass. Every minute spent here saves a round trip later.
Read your own diff top to bottom the way a stranger would. Authors catch a surprising share of review comments themselves, before anyone else has to.
Reviewers find fewer defects as diffs grow, and small PRs get picked up faster. If it grew past a screen or three, split it before asking anyone to read it.
"Fix login" tells a reviewer nothing. "Rate-limit login attempts to block credential stuffing" tells them what changed and why it matters.
What changed, why now, how to test it, and anything you are unsure about. Link the issue or ticket so the reviewer does not have to reconstruct the problem.
Cover the new behavior, and for bug fixes, cover the bug. A fix without a regression test tends to come back.
Do not spend a human reviewer’s attention on things a machine catches for free. Open the PR with checks already passing.
Debug prints, commented-out blocks, stray TODOs, secrets or credentials in config. The cleanup pass takes two minutes and spares you the embarrassing comment.
Open the PR conflict-free. A branch that starts behind main only falls further behind while it waits for review.
A PR assigned to everyone is assigned to no one. Pick the person who knows this code, and say so if it is urgent.
During the review
The goal: a fast, clear verdict. Slow or vague reviews are how pull requests start to rot.
Turnaround is the single biggest lever on review quality of life. Even "I can look tomorrow morning" unblocks the author today.
Read the description and the linked issue first. You cannot judge a solution without knowing the problem it solves.
Empty inputs, error paths, concurrency, permissions. The happy path usually works; the unhappy paths are what review is for.
Ask one question of every new test: would it fail if the change were reverted? If not, it is decoration.
Names, structure, and comments outlive the PR. If you had to re-read a block twice, the next person will too. Say so.
Unvalidated input, missing authorization checks, sensitive data in logs. These are cheap to catch in review and expensive to catch in production.
The author should never have to guess what must change versus what is taste. A one-word prefix ("blocking:", "nit:") removes a whole round of back and forth.
Approve, or request changes and say exactly what would flip your answer. A review that trails off leaves the PR in limbo.
Before and after the merge
The goal: approved work actually ships. This is where "done" pull requests most often quietly stall.
Not on the commit from before the last "small fix" push. Check the tick is on the code you are about to merge.
Resolved, answered, or explicitly moved to a follow-up issue. Nothing silently dismissed.
If main moved under you, rebase and let checks run once more. Merging a stale branch is how green CI ships a red build.
Squash the "fix typo" commits and write a merge message that future git blame will thank you for.
An approval is not a merge. Approved-but-unmerged is one of the most common ways finished work sits for days without anyone noticing.
Dead branches pile up, confuse newcomers, and make the next conflict hunt worse. Most hosts offer a checkbox to do it automatically.
Check staging or the deploy, then glance at errors. A merged PR is not done until it is running.
Put it in every pull request
Paste this into .github/PULL_REQUEST_TEMPLATE.md and GitHub pre-fills every new PR with it. The - [ ] lines render as clickable task lists that show progress right in the PR.
## Pull request checklist ### Before you open (author) - [ ] Self-review the whole diff - [ ] Keep it under roughly 400 changed lines - [ ] Write a title that says what and why - [ ] Give context in the description - [ ] Add or update tests - [ ] Run linters and the test suite locally - [ ] Sweep for leftovers - [ ] Rebase on the latest main - [ ] Request a specific reviewer ### During review (reviewer) - [ ] Respond within one business day - [ ] Understand the intent before the code - [ ] Check correctness and edge cases - [ ] Check that the tests test something - [ ] Read for the next reader - [ ] Look for security and data issues - [ ] Mark comments as blocking or nit - [ ] End with a clear verdict ### Before and after merge - [ ] CI is green on the latest commit - [ ] Every conversation is resolved - [ ] The branch is current with main - [ ] Tidy the commit history - [ ] Merge it yourself, promptly - [ ] Delete the branch - [ ] Watch it land
A checklist opens good PRs. It does not merge them.
Every check above happens at a moment when someone is already paying attention. The failure mode of pull requests is different: it is the days when nobody is paying attention. The PR that passed every author check and then waited four days for a first review. The one approved on Thursday and still unmerged the next Wednesday.
That is a visibility problem, not a template problem. GitLoom watches your GitHub repos and posts one quiet digest to Slack on weekday mornings: PRs waiting on a first review, approved but unmerged, blocked by a merge conflict, failing CI, or small and forgotten. If nothing is stuck, it stays silent.
Good morning. 4 pull requests need a nudge across 3 repos:
Waiting on first review: api#482 Add rate limiting to webhook delivery (Priya)
Opened Monday, still no first review. Marcus touched this code last.
Approved, not merged: billing#517 Migrate billing webhooks to v2 (Jonas)
Sara approved it two days ago. One click from shipping.
Merge conflict: web#495 Refactor session storage (Ale)
Conflicts with main since yesterday’s auth merge. Needs a rebase.
Failing CI: api#490 Upgrade the payments SDK (Marcus)
CI has been red since yesterday: two unit tests. Green checks are all that stand between this and merge.
Everything else is moving normally. Nothing else needs you today.
One quiet digest, not forty notifications.
Pull request checklists, answered
What belongs on the list, how to make GitHub enforce it, and what checklists cannot fix.
The checklist covers the opening. GitLoom covers the wait.
One quiet Slack digest each weekday morning with every PR that stalled, and silence when nothing did.
Two minutes to install · 14 days free · Quiet by default