Pull Request Self-Review Checklist

Before you open it

0/5

Pull the latest target branch and resolve any conflicts locally firstA PR that's already behind wastes the reviewer's first pass on conflicts that have nothing to do with the change.
Run the full test suite locally, not just the tests you touchedA change can pass its own new tests while quietly breaking something unrelated it never occurred to you to check.
Run the linter and formatter so the diff is clean of style-only noiseStyle fixes mixed into a diff bury the substantive lines a reviewer actually needs to focus on.
Remove debug statements, commented-out code, and stray console logsThese are the fastest tell that a diff wasn't looked over before it was sent, and they erode a reviewer's trust in the rest.
Confirm the branch actually builds and runs, not just that individual files look rightA change can be locally correct in isolation and still fail to build once everything's put together.

0/5

Read the full diff yourself, in the PR tool's view, before anyone else doesThe diff view surfaces accidental changes — a stray formatting pass, a debug flag left on — that never show up in an editor.
Check for unrelated changes that snuck in and split them into a separate PRA focused diff is reviewable in minutes; a diff mixing three concerns takes a reviewer three times as long to trust.
Verify no unrelated files were touched, especially generated files or lockfilesAn accidental lockfile change can silently shift dependency versions for everyone who pulls the branch.
Look for TODO comments you added and either resolve them or explain why they're stayingAn unexplained TODO left in a merged PR usually never gets picked up again.
Double check that hardcoded values (URLs, IDs, feature flags) are the right ones for this environmentA value that's correct locally is often wrong once merged, especially anything pointing at staging.

0/4

Write a description that explains why the change was made, not just what changedThe diff already shows what changed — the reasoning is the part a reviewer, and future you, actually need.
Link the ticket or issue the PR resolvesIt gives anyone reading the PR later the full context without having to ask.
Call out anything you're unsure about or deliberately didn't handleFlagging your own uncertainty focuses the reviewer's attention exactly where it's most useful.
Add before/after screenshots or a short clip for any visible UI changeA visual diff is faster for a reviewer to judge than reading through JSX or CSS and imagining the result.

0/4

Identify what happens if this change is wrong in production, and how it would be noticedNaming the failure mode up front makes reviewers weigh the risk accurately instead of assuming the best case.
Check whether the change needs a feature flag, staged rollout, or an easy rollback pathHigh-risk changes deserve a way to back out quickly that doesn't depend on a fast follow-up deploy.
Note any migration, data change, or one-time script the deploy depends onThese are the changes that can't simply be reverted with git, and reviewers need to know that going in.
Consider who else's code this touches and whether they should be pulled in as a reviewerThe person who owns the adjacent code often catches a risk that isn't visible from the diff alone.