# Code Review

> Use to review a pull request or a diff. Produces severity-tagged comments ([blocker], [suggestion], [nit]), one summary verdict, and a security pass. Reads adjacent files to verify claims and never hand-waves "looks good."

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

---


# code-review

A useful review answers four questions:

1. **Does it work?** Does the change actually do what the PR description says?
2. **Is it safe?** Any security, data-loss, or backwards-compat risk?
3. **Is it maintainable?** Will the next person to read this in 6 months understand it?
4. **Is it the smallest change that solves the problem?**

## Method

1. Read the PR description. Note the stated goal.
2. Read the diff in full.
3. Read adjacent files for any function/class touched (callers, tests, types).
4. Run the tests if you can. If you can't, say so.
5. Group findings by severity.

## Severity tags

- **[blocker]** — must be fixed before merge. Bug, security issue, breaks tests, breaks API.
- **[suggestion]** — should probably be fixed. Smell, missing test, unclear name.
- **[nit]** — purely cosmetic. Author can ignore.
- **[question]** — you genuinely don't understand and need an answer to finish reviewing.

## Security pass — always do these

- Are user inputs validated at the boundary?
- Are secrets out of the diff (no hardcoded keys)?
- Are SQL queries parameterized?
- Are auth checks present on new endpoints?
- Are file paths normalized (no path traversal)?
- Are dependencies pinned and from a trusted source?

## Output format

```
## Verdict
<approve | request changes | comment>

## Summary
<2-3 sentences: what the PR does, what's good, what's blocking.>

## Findings

### [blocker] <file:line>
<what's wrong>
<suggested fix>

### [suggestion] <file:line>
<what could be better>

### [nit] <file:line>
<cosmetic>

### [question] <file:line>
<what you don't understand>

## Security pass
- [x] inputs validated
- [x] no secrets
- [x] queries parameterized
- [ ] auth checks — see [blocker] above
- [x] paths safe
- [x] deps clean

## Tests
- [x] PR includes a test for the new behavior
- [x] tests pass locally / in CI
```

## Hard rules

- Never approve a PR you didn't read. Never approve a PR with a failing CI.
- Never tag something `[blocker]` without proposing a concrete fix.
- Be kind. Critique the code, not the coder.