Pull Request Checklist: Before You Open a PR
A checklist to go through before you open or mark a pull request ready for review. It is built on Google's published guidance for authors and GitHub's pull request documentation, and each check says how much it matters and exactly how to confirm it, from the size of the change to tests, the description, release safety and responding to review.
8
Sefism · Oct 2026
37
Sefism · Oct 2026
8
Sefism · Oct 2026
Stacks and tools
Sefism · Oct 2026
Checklist
Web Development
Sefism
19 min read
Intermediate
Free
What this checklist is
A checklist to go through before you open or mark a pull request ready for review. It is built on Google's published guidance for authors and GitHub's pull request documentation, and each check says how much it matters and exactly how to confirm it, from the size of the change to tests, the description, release safety and responding to review.
It has 8 chapters and 37 checks, each with how to verify it and how much it matters. For developers opening pull requests.
Chapter by chapter
1. Scope and size (4 checks)
Small, focused pull requests are reviewed faster and more carefully. These checks make sure the change does one thing and is a size a reviewer can handle.
2. Code is ready for other eyes (5 checks)
These checks make sure the reviewer sees finished code that builds, passes the automated checks and contains nothing you would not want merged.
3. Tests (4 checks)
Google's guidance says logic changes should come with new or updated tests in the same change. These checks make sure the tests exist, prove something and do not quietly skip anything.
4. Self review (4 checks)
GitHub recommends reviewing your own pull request before anyone else does. These checks are what to look for when you read your own diff.
5. Title and description (6 checks)
The description is the reviewer's starting point and the permanent record of why the change exists. These checks make it do both jobs.
6. Release safety (5 checks)
Some changes are risky not because the code is wrong but because of how they reach production. These checks cover migrations, breaking changes, configuration and documentation.
7. Branch, commits and requesting review (5 checks)
The last checks before you hit the button: a branch that is current, commits that make sense, green CI and the right reviewers.
8. During review (4 checks)
The checklist does not end when you request review. These checks keep the conversation moving and the result clean.
How it works on Sefism
The checklist is one page: each check has a severity (must, should or nice to have) and a concrete way to verify it, and members can tick checks off as they go. The opening chapters are open to everyone. Adding it to your account uses credits, opens every chapter and keeps your progress.
Every claim is checked against the sources listed on the page (8 cited).
Ready to start?
Opens on Sefism in a new tab.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.