How do I install the Code Review skill?

Run npx skillmds@latest add rca32/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?

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

Code Review by rca32 — Agent Skill

Name: Code Review
Author: rca32

Code Review

Review a PR, branch, commit range, or working-tree change for actionable defects and missing behavior. Use for code and pre-push review. Return findings without editing code; not a general implementation or bug-hunt workflow.

rca32 9a1abdf 2 files · 2.8 KB Updated Sep 17, 2026

File contents

Find defects that matter

Review the requested change in the context of its intended behavior. Prioritize correctness and consequences for users over stylistic preferences or finding counts.

Resolve the review target from the request and repository state. Include staged and unstaged changes for working-tree review, and all intended commits for a delivery review. Establish the actual base rather than assuming a branch name. Ask only if plausible targets cannot be distinguished.

Read the diff and enough surrounding code, callers, tests, and contracts to understand its effects. Follow an unchanged dependency when it can reveal a defect in the change. Generated output may need consistency checks even when its source is the main review target. There is no mandatory whole-system checklist or fixed investigation depth.

Choose tests or small read-only checks that resolve material uncertainty. Reuse valid results. Delegate independent review questions when useful, without duplicating inspection or requiring a reviewer fleet.

Evidence and scope

A finding needs a reachable scenario, concrete evidence, impact, and a useful correction. Distinguish confirmed defects from questions and unsupported possibilities; a clean review is an acceptable result.

Check the risks the change introduces: for example access boundaries, data correctness, failure/retry behavior, compatibility, resource use, and missing regression coverage. Do not assume a universal implementation fix from a bug category; verify the project's actual contract.

Identify which findings are introduced by the change, exposed by it, or pre-existing and unrelated. Report unrelated severe issues separately without expanding the requested review into an audit. Assess remaining uncertainty honestly.

Return the review

Lead with actionable findings ordered by consequence. Include severity, location, triggering condition, and impact; keep enough evidence for the author to verify them. Use the repository's severity convention if present. Briefly state the scope and validation limits. Do not add praise, placeholder findings, or speculative work just to fill a template.

Review only: no source edits, commits, external comments, or tracker updates without separate instructions. A requested saved report uses the user's path or repository convention. If unavailable, choose a descriptive task-specific path under docs/ without overwriting another report.

---name: code-reviewdescription: Review a PR, branch, commit range, or working-tree change for actionable defects and missing behavior. Use for code and pre-push review. Return findings without editing code; not a general implementation or bug-hunt workflow.---# Find defects that matterReview the requested change in the context of its intended behavior. Prioritize correctness and consequences for users over stylistic preferences or finding counts.Resolve the review target from the request and repository state. Include staged and unstaged changes for working-tree review, and all intended commits for a delivery review. Establish the actual base rather than assuming a branch name. Ask only if plausible targets cannot be distinguished.Read the diff and enough surrounding code, callers, tests, and contracts to understand its effects. Follow an unchanged dependency when it can reveal a defect in the change. Generated output may need consistency checks even when its source is the main review target. There is no mandatory whole-system checklist or fixed investigation depth.Choose tests or small read-only checks that resolve material uncertainty. Reuse valid results. Delegate independent review questions when useful, without duplicating inspection or requiring a reviewer fleet.## Evidence and scopeA finding needs a reachable scenario, concrete evidence, impact, and a useful correction. Distinguish confirmed defects from questions and unsupported possibilities; a clean review is an acceptable result.Check the risks the change introduces: for example access boundaries, data correctness, failure/retry behavior, compatibility, resource use, and missing regression coverage. Do not assume a universal implementation fix from a bug category; verify the project's actual contract.Identify which findings are introduced by the change, exposed by it, or pre-existing and unrelated. Report unrelated severe issues separately without expanding the requested review into an audit. Assess remaining uncertainty honestly.## Return the reviewLead with actionable findings ordered by consequence. Include severity, location, triggering condition, and impact; keep enough evidence for the author to verify them. Use the repository's severity convention if present. Briefly state the scope and validation limits. Do not add praise, placeholder findings, or speculative work just to fill a template.Review only: no source edits, commits, external comments, or tracker updates without separate instructions. A requested saved report uses the user's path or repository convention. If unavailable, choose a descriptive task-specific path under `docs/` without overwriting another report.

Frequently asked questions