01
What this skill does
Use this skill when a user asks for `/code-review`, a PR review, diff review, branch review, staged-change review, or safety check before merge. It reviews the relevant scope as a reviewer, prioritizes correctness, behavioral regressions, security, contracts, and missing tests, then writes a Markdown report with severity-ordered findings, test gaps, coverage notes, and a recommendation.
02
When to use it
- 01Reviewing PRs, branch diffs, staged changes, working trees, focused files, or pasted code.
- 02Surfacing correctness bugs, release-blocking regressions, security issues, and missing tests.
- 03Producing a reusable review artifact with findings, coverage gaps, and residual risk.
03
How it works
- 01
Identify the review scope and baseline, preferring the smallest reasonable scope when the user does not name one.
- 02
Read the diff plus relevant tests, fixtures, schemas, config, docs, and call sites needed to understand impact.
- 03
Trace changed data and control flow far enough to verify user-visible, persisted, security, or integration effects.
- 04
Build a review coverage ledger for changed review-relevant areas.
- 05
Check whether tests cover the risky changed behavior.
- 06
Write a Markdown report with recommendation, findings, test gaps, coverage ledger, and evidence appendix.
04
What you get back
- 01A Markdown code-review report.
- 02A short terminal summary.
- 03A complete findings index, test gaps, and review coverage ledger.
05
Important boundaries
- 01Do not make code changes during review unless the user explicitly asks for fixes.
- 02Do not stage, commit, push, or mutate Git state.
- 03Do not lead with style or broad refactor preferences unless they create concrete review risk.
- 04Use `regression-review` or `hack-review` instead when the user asks for those specialized gates.
06