How to review a pull request and catch real issues
PR reviews keep your codebase healthy. They catch bugs early, spread knowledge, and keep standards consistent.
This checklist helps you review faster without missing the important stuff.
1. Start with the context
- Read the PR description. If it doesn’t explain the change, ask for it.
- Check the linked issue or goal. Review against that goal, not against personal preference.
- Look at the scope. If the PR mixes unrelated changes, ask to split it.
2. Do a quick pass first
You want a high-level picture before you go line-by-line.
- What files changed, and why?
- Does the change fit the existing architecture?
- Are there changes that affect infrastructure, deploys, or config?
3. Review for correctness
- Does it do what the PR says it does?
- What happens in empty, loading, and error states?
- What happens when data is missing or malformed?
- Are edge cases handled, or silently ignored?
4. Review for maintainability
Ask: will you understand this in two years?
- Are names specific and consistent?
- Can you simplify the logic without hiding behavior?
- Does the change add a new pattern? If yes, explain why it exists and when to use it.
5. Check tests for signal, not quantity
- Do the tests fail when the code breaks?
- Do they avoid brittle assertions?
- Do they cover the user flow, not only internal details?
6. Security and permissions
- Did this change touch auth, roles, or permissions?
- Are you validating inputs on the server when it matters?
- Are you logging sensitive data by accident?
7. Frontend accessibility
If the PR changes UI:
- Can you use it with a keyboard?
- Is focus visible and predictable?
- Are ARIA roles correct when needed?
- Is contrast readable?
8. Write comments that help
Avoid vague comments like “this is confusing.”
- State the problem.
- Explain why it matters.
- Suggest a concrete fix, or ask a clear question.
9. End with the human part
If someone did something well, say it. Clear praise teaches the team what “good” looks like.