dream-zjk Code Review
When to use
- A teammate (or you) opened a pull request and wants a thorough review.
- You produced a large diff and want a second pass before committing.
- CI is green but you suspect logic or edge-case bugs.
Workflow
- Understand intent first. Read the PR description and linked issue. A review that ignores intent either nags about style or misses real defects.
- Read the diff in context. Pull the changed files and read the surrounding functions, not just the hunks. Most bugs hide at the boundaries of a change.
- Classify findings by severity:
- Blocker: crashes, data loss, security hole, broken contract.
- Major: wrong logic, missing edge case, race condition.
- Minor: style, naming, dead code, unclear comment.
- Verify, don't assume. If a change looks wrong, trace the call sites or run the relevant test. Write your comment as a question if you are unsure.
- Summarize. Open with a one-line verdict (Approve / Request changes / Comment) and list blockers first.
Constraints
- Do not rewrite the author's code for them in the review — suggest the change.
- Respect the project's existing style; flag deviations only when they matter.
- Never approve if there is an unaddressed blocker, even for trivial diffs.
Definition of done
- Every blocker has a concrete, actionable comment.
- Style nits are grouped and clearly marked as non-blocking.
- The verdict matches the content of the review.