Use this checklist before approving or merging a pull request.
Scope and intent
- Is the purpose of the change clear from the PR title and description?
- Does the implementation still match the intended scope?
- Is any unrelated cleanup mixed into the change?
Logic and correctness
- Does the behavior make sense for the expected inputs and edge cases?
- Are failure states handled intentionally?
- Is there hidden coupling to another part of the system?
Tests and verification
- Does the PR include the right level of automated coverage?
- Are there manual verification steps when automated coverage is not enough?
- Would I know how to reproduce the fix or feature locally?
Readability and maintainability
- Are names clear enough that the next engineer can follow the change quickly?
- Is the code doing one thing per unit, or is it quietly mixing concerns?
- Are comments used only where they reduce real ambiguity?
Risk and rollout
- What is the most likely failure mode if this change is wrong?
- Is there any migration, config, or deployment dependency?
- Does the change need a feature flag, staged rollout, or monitoring note?
Team communication
- Did the author explain tradeoffs and assumptions?
- If the work touches another team or domain, is that context documented?
- Would a future teammate understand why this approach was chosen?
If your team’s estimation and planning are weak, this checklist works best alongside How to Estimate Tasks Without Sounding Clueless.