How do I install the Code Review skill?

Run npx skillmds@latest add rokurokulab/code-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Code Review safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Code Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Code Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Code Review?

rokurokulab (@rokurokulab) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Code Review by rokurokulab — Agent Skill

Name: Code Review
Author: rokurokulab

Code Review

Review a diff (staged, branch, or PR) for correctness, hidden state changes, missing tests, and convention drift. Use this when the user asks for a review, second opinion, or sanity check on changes they're about to commit or merge.

rokurokulab f4ac293 2.3 KB Updated Sep 17, 2026

File contents

code-review

A lightweight peer-review pass. Aims for the kind of comments a thoughtful colleague would leave — not exhaustive linting (the linter already does that) and not full-redesign feedback (out of scope).

When to invoke

User says "review this", "any issues with this change?", "second opinion before I merge"
User asks you to look at git diff, a PR URL, or a specific file/range
Don't auto-invoke on every Edit — too noisy

What to do

Read the change. Get the diff from git diff, git diff --cached, git diff <base>...HEAD, or gh pr diff <num>. If a PR URL was given, also read the PR description for declared intent.
Read 1–2 nearby files to understand local convention (naming, error-handling style, log format).
Pass the change through this checklist (skip categories that don't apply):
- Correctness: Does it do what the message claims? Edge cases? Off-by-one, nil/None, empty input, concurrent access.
- Hidden state changes: Touches global state, env vars, file system, network outside its declared scope?
- Tests: New behavior without a test? Removed behavior with a now-dead test?
- Backward compat: Public API broken without a major bump or deprecation note?
- Convention drift: Departs from AGENTS.md rules or local patterns without justification?
- Comment hygiene: Comments explain what (redundant) instead of why (useful)?
- Naming: Names readable a year from now? Abbreviations that won't be obvious?
- Errors: Swallowed errors? Lost context in re-raise? Generic error type for actionable failure?

Output format

Group findings into Must fix (correctness, security, broken tests) and Consider (style, naming, cleanups). Include file:line references. End with a one-sentence overall take ("Looks good apart from the two must-fix items" / "Suggest reworking the error handling, then re-review").

Don't pad with praise. If there's nothing significant to flag, say so in one line and stop.

---name: code-reviewdescription: Review a diff (staged, branch, or PR) for correctness, hidden state changes, missing tests, and convention drift. Use this when the user asks for a review, second opinion, or sanity check on changes they're about to commit or merge.---# code-reviewA lightweight peer-review pass. Aims for the kind of comments a thoughtful colleague would leave — not exhaustive linting (the linter already does that) and not full-redesign feedback (out of scope).## When to invoke- User says "review this", "any issues with this change?", "second opinion before I merge"- User asks you to look at `git diff`, a PR URL, or a specific file/range- Don't auto-invoke on every Edit — too noisy## What to do1. **Read the change.** Get the diff from `git diff`, `git diff --cached`, `git diff <base>...HEAD`, or `gh pr diff <num>`. If a PR URL was given, also read the PR description for declared intent.2. **Read 1–2 nearby files** to understand local convention (naming, error-handling style, log format).3. **Pass the change through this checklist** (skip categories that don't apply): - **Correctness**: Does it do what the message claims? Edge cases? Off-by-one, nil/None, empty input, concurrent access. - **Hidden state changes**: Touches global state, env vars, file system, network outside its declared scope? - **Tests**: New behavior without a test? Removed behavior with a now-dead test? - **Backward compat**: Public API broken without a major bump or deprecation note? - **Convention drift**: Departs from `AGENTS.md` rules or local patterns without justification? - **Comment hygiene**: Comments explain *what* (redundant) instead of *why* (useful)? - **Naming**: Names readable a year from now? Abbreviations that won't be obvious? - **Errors**: Swallowed errors? Lost context in re-raise? Generic error type for actionable failure?## Output formatGroup findings into **Must fix** (correctness, security, broken tests) and **Consider** (style, naming, cleanups). Include file:line references. End with a one-sentence overall take ("Looks good apart from the two must-fix items" / "Suggest reworking the error handling, then re-review").Don't pad with praise. If there's nothing significant to flag, say so in one line and stop.

Frequently asked questions