PR review process
A repeatable workflow for reviewing pull requests that catches bugs, enforces standards, and keeps the team shipping fast.
1. Context first
Read the PR description and linked issue before touching the diff. Understand what problem this code solves and what constraints the author was working under. If the description is thin, ask for a summary before proceeding.
2. High-level scan
Skim the changed files list. Look for red flags: files touched that shouldn't be, massive diffs that should be split, missing tests alongside new logic. Flag structural concerns before diving into line-by-line review.
3. Line-by-line pass
Work through every changed line. Check for correctness, edge cases, error handling, and adherence to project conventions. Leave comments that are specific and actionable — never just “this looks wrong.”
4. Test the happy path
Pull the branch locally. Run the feature. Verify it does what the PR claims. If setup is nontrivial, ask the author for a one-liner to get running. Trust but verify.
5. Break it
Throw edge cases at it: empty inputs, rapid clicks, network failures, concurrent operations. If you find a crash or silent failure, request a fix before approval.
6. Summarize and decide
Write a closing comment that recaps what you reviewed, what you found, and your verdict: approve, request changes, or comment only. Be clear about blocking vs. non-blocking feedback.
Pro tip: Review in the morning when your attention is fresh. Limit review sessions to 60 minutes. After that, defect detection drops significantly.