Use the specified diff, branch, or PR and its intended behavior. Establish the review base and inspect existing tests and surrounding implementation. Remain read-only unless fixes are also requested.
Steps
Understand the trigger and expected result before judging the implementation. Read tests to learn which claims are actually exercised.
Check the dimensions below, concentrating on changed behavior, affected callers, and failure paths. Read domain rules when a boundary changes.
Validate suspected defects with a concrete execution path, failing case, or source evidence. Do not invent timings or vulnerabilities from appearances.
Challenge verification claims. An unrun check is a finding only when the repository requires it or concrete evidence shows failure. A typecheck that cannot prove a browser path is not a defect when that path is out of scope. Order findings by impact with file/line, trigger, consequence, and smallest useful remedy.
Review checklist
Correctness: success, empty, invalid, failure, and concurrency cases relevant to this change.
Callers: existing call sites, generated clients, and public exports still match the new contract.
Failure paths: error handling, denied access, and recovery are evidenced, not assumed.
Clarity: names and control flow expose intent; refactoring removes complexity instead of moving it.
Architecture: ownership, dependencies, generated sources, and existing shared helpers remain coherent. Generated files were not edited by hand.
Security: changed input and authorization boundaries, secret exposure, and denied access paths are checked.
Performance: changed queries, list bounds, repeated work, and client rendering have evidence appropriate to their risk.
Verification: tests exercise behavior; claimed checks were actually run and cover the change. If a finding implies a new quality or security bar, escalate to /f-quality or /f-security instead of inventing policy.
Handoff
Report actionable findings first, then unresolved questions and verification limits. If none are found, say so with the review scope and residual risks. An inspection is not proof that tests passed and is not approval to merge.
1---2name: code-review-23description: Review a change for evidenced defects and risks without editing it. Use when the user types /code-review.4---56## Purpose and inputs78Use the specified diff, branch, or PR and its intended behavior. Establish the review base and inspect existing tests and surrounding implementation. Remain read-only unless fixes are also requested.910## Steps11121. Understand the trigger and expected result before judging the implementation. Read tests to learn which claims are actually exercised.132. Check the dimensions below, concentrating on changed behavior, affected callers, and failure paths. Read domain rules when a boundary changes.143. Validate suspected defects with a concrete execution path, failing case, or source evidence. Do not invent timings or vulnerabilities from appearances.154. Challenge verification claims. An unrun check is a finding only when the repository requires it or concrete evidence shows failure. A typecheck that cannot prove a browser path is not a defect when that path is out of scope. Order findings by impact with file/line, trigger, consequence, and smallest useful remedy.1617## Review checklist1819- [ ] Correctness: success, empty, invalid, failure, and concurrency cases relevant to this change.20- [ ] Callers: existing call sites, generated clients, and public exports still match the new contract.21- [ ] Failure paths: error handling, denied access, and recovery are evidenced, not assumed.22- [ ] Clarity: names and control flow expose intent; refactoring removes complexity instead of moving it.23- [ ] Architecture: ownership, dependencies, generated sources, and existing shared helpers remain coherent. Generated files were not edited by hand.24- [ ] Security: changed input and authorization boundaries, secret exposure, and denied access paths are checked.25- [ ] Performance: changed queries, list bounds, repeated work, and client rendering have evidence appropriate to their risk.26- [ ] Verification: tests exercise behavior; claimed checks were actually run and cover the change. If a finding implies a new quality or security bar, escalate to `/f-quality` or `/f-security` instead of inventing policy.2728## Handoff2930Report actionable findings first, then unresolved questions and verification limits. If none are found, say so with the review scope and residual risks. An inspection is not proof that tests passed and is not approval to merge.
Run npx skillmds@latest add blockmatic/code-review-2 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.
Review a change for evidenced defects and risks without editing it. Use when the user types /code-review. It is listed under Productivity on SkillMD.
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.
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.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
blockmatic (@blockmatic) published this skill. Their other Agent Skills are listed on their SkillMD profile.
blockmatic