Code review

Review a diff like a careful teammate: correctness first, then security, then clarity.

Install in Claude Code

Create a folder whose name matches the skill name field (code-review/). Save the text below as SKILL.md inside it. Personal skills go in ~/.claude/skills/code-review/. Project skills go in .claude/skills/code-review/. Claude Code discovers them from the filesystem.

Upload on claude.ai

Zip the skill folder (the zip should contain the folder, which contains SKILL.md) and upload it in Claude’s Skills settings. Anthropic’s current platform docs list custom uploads on Pro, Max, Ultra, Team, and Enterprise plans when code execution is enabled. Check the Claude Help Center for the latest plan details. Read the files before you turn a skill on.

Use with the Claude API

Custom API Skills are uploaded through the Skills API and referenced with the code execution tool. Skills do not sync automatically from Claude Code or claude.ai — install this folder again on the surface where you need it. See Anthropic’s Agent Skills overview.

---
name: code-review
description: Reviews source code and diffs for correctness, security, regressions, and clarity, then reports findings by severity. Use when the user asks for a code review, PR review, critique of a patch, or help inspecting changed files.
---

# Code review

## Goal
Review the provided code or diff the way a careful teammate would. Optimize for catching real defects, not for leaving a long comment.

## Review order
1. **Understand intent.** Restate what the change is trying to do in 2–4 sentences. If intent is unclear, ask before inventing an architecture story.
2. **Correctness.** Trace happy path and likely edge cases. Look for broken invariants, off-by-one errors, race conditions, wrong types, and silent exception handling.
3. **Security and data safety.** Flag injection, authz gaps, secret leakage, unsafe deserialization, path traversal, and unvalidated user input. Mention a risk only if the code path makes it plausible.
4. **Reliability.** Note missing error handling, retries that can double-charge or duplicate work, and tests that do not cover the new behavior.
5. **Clarity.** Comment on naming, dead code, and confusing control flow only when they will slow the next reader. Skip pure style nits unless the user asked for style review or the file already follows a documented style.

## Output format
```markdown
## Review summary
[What the change does, and whether you would approve, request changes, or need more context.]

## Findings
### Blockers
- [file:line or symbol] Problem. Why it matters. A concrete fix.

### Should fix
- [file:line or symbol] Problem. Why it matters. A concrete fix.

### Suggestions
- Optional improvement, with a reason.

## Questions
- Anything you cannot verify from the diff alone.

## What looks good
- 2–4 specific strengths so the author knows what to keep.
```

## Rules
- Do not invent files, APIs, or test results you did not see.
- If only a snippet was provided, review that snippet and state the limit of what you can guarantee.
- Prefer one precise finding over three overlapping ones.
- When suggesting a fix, keep it as small as the bug. Do not propose an unrelated refactor.
- Never request that secrets, production data, or credentials be pasted into the chat.

You may copy and adapt this free skill for personal or commercial use. If you republish it, please credit Skillory with a link. Audit any skill — including this one — before enabling it in an environment with access to private data.

Related skills

Claude Engineering SKILL.md

Changelog writer

Turn commits and merged PRs into a readable changelog grouped the way users scan it.

Open skill →

Claude Engineering SKILL.md

Git commit messages

Write conventional commit messages from a staged diff, without fluff or invented ticket IDs.

Open skill →

Claude Productivity SKILL.md

Meeting notes

Turn messy transcripts and rough notes into minutes with decisions, owners, and due dates.

Open skill →