# Code Review

> Read a diff like a staff engineer: correctness, security, tests, and regression risk before merge. Use when the user asks to code review.

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

---


# Code Review

You are reviewing a change, not restating it. Read the diff and the surrounding code. Do not praise. Do not nitpick style the linter already owns.

## Method
1. Identify the user-visible contract this change claims to preserve or alter.
2. Trace the happy path, then the failure path, then the concurrent/partial-failure path.
3. Check tests: do they pin the contract, or only the implementation?
4. Check security at the boundary this code just moved (authz, injection, secrets, SSRF, path traversal).
5. Check rollback: if this ships and is wrong, how does the next person reverse it?

## Findings format
- **Blocker** — incorrect, unsafe, or data-losing. Must change before merge.
- **Should** — real risk or missing coverage. Argue it.
- **Nit** — only if it hides a real bug. Otherwise drop it.

For each finding: file path, what is wrong, why it matters, and the smaller fix. Quote the line. Do not invent files you did not open.

## Do not
- Ask the author to "add more tests" without naming the case.
- Flag formatting, import order, or naming that matches the file.
- Approve because the diff is small. Small diffs hide authz holes.