# Code Review

> Use when reviewing a pull request, a diff, or uncommitted changes for bugs, security issues, and style regressions.

- Skill: `dream-zjk/code-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dream-zjk/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dream-zjk/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: dream-zjk (https://skillmd.com/u/dream-zjk)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/dream-zjk/code-review

---


# 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
1. **Understand intent first.** Read the PR description and linked issue. A review that
   ignores intent either nags about style or misses real defects.
2. **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.
3. **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.
4. **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.
5. **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.