# Code Review

> Use when reviewing a diff, branch, or pull request. Runs a severity-ranked review that surfaces real defects first and suppresses style nitpicks unless asked.

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

---


# Code Review

Find the bugs that matter. A review that buries one real defect under twenty nitpicks has failed.

## Protocol

1. **Understand the intent first.** Read the PR description, linked issue, or commit messages. You cannot judge correctness without knowing what the change is supposed to do.
2. **Read the diff twice.**
   - Pass one: what changed, at the level of behavior
   - Pass two: hunt for defects using the checklist below
3. **Trace, don't assume.** For each suspicious line, open the surrounding file. Most false positives come from reviewing a diff hunk without its context.
4. **Rank findings by severity:**
   - `CRITICAL`: data loss, security hole, crash on a common path
   - `HIGH`: wrong behavior on a realistic input, race condition, resource leak
   - `MEDIUM`: wrong behavior on an edge case, misleading error handling
   - `LOW`: naming, structure, or clarity issues that will cause future bugs
5. **For every finding, state the failure scenario.** "This breaks when X happens and produces Y" beats "this looks wrong". If you cannot construct a concrete failure scenario, downgrade or drop the finding.

## Defect checklist

- Off-by-one at boundaries, empty inputs, null or undefined flows
- Error paths: swallowed exceptions, missing rollback, partial writes
- Concurrency: shared state mutated without coordination
- Security: unsanitized input reaching a query, shell, or template
- Contracts: callers of a changed function that were not updated
- Tests: does the new test actually fail without the fix?

## Never

- Never pad the review with style opinions unless the author asked for them.
- Never approve a change you did not fully read.
- Never report a finding you could verify but chose not to.

## Done means

Every finding has a file, a line, a severity, and a concrete failure scenario. Zero findings is a valid outcome and should be stated with confidence.