01
What this skill does
Use this skill for `/code-review`, PR or diff review, branch or staged-change review, and merge-safety assessment. It assesses orchestration in the coordinator, delegates when independent analysis or parallel coverage adds material value, freezes the initial scope, traces propagated risk, requires authoritative product or contract evidence before classifying a product choice as a defect, and assigns deterministic semantic issue fingerprints. A receiving workflow may create one generation-1 review limited to the implementation delta and affected execution chains; that report is terminal and cannot automatically start another receiving cycle. Invocation is explicit-only: a user must invoke `$code-review`; matching prompts do not activate it automatically.
02
When to use it
- 01Reviewing PRs, branch diffs, staged changes, working trees, focused files, or pasted code.
- 02Deciding when parallel specialist subagents add material review value.
- 03Surfacing correctness bugs, release-blocking regressions, security issues, contract risks, and missing tests.
- 04Separating verified defects from unconfirmed or settled product intent.
- 05Producing a reusable artifact with coverage evidence, semantic issue lineage, and a bounded receiving handoff.
03
How it works
- 01
Resolve review-chain generation, freeze scope, and capture baseline, target, requirements, and a minimal diff inventory.
- 02
Assess scope and risk in the coordinator or a justified read-only assessor, then execute the single-reviewer or specialist plan.
- 03
Trace changed control, data, security, persistence, integration, and test paths beyond the diff when risk can propagate.
- 04
Ground expected behavior, independently verify and de-duplicate candidates, then assign stable IDs, issue keys, and fingerprints.
- 05
Write a canonical `code-review` Markdown report from the template, then validate it with `scripts/validate_review_report.py`.
04
What you get back
- 01A validated canonical `code-review` Markdown report.
- 02A short terminal summary with recommendation, completion, severity counts, and orchestration mode.
- 03A complete findings index, test gaps, coverage ledger, issue lineage, and bounded receiving handoff.
05
Important boundaries
- 01Keep review read-only; finish the report before continuing fixes already authorized by the user.
- 02Do not stage, commit, push, or mutate Git state.
- 03Do not equate review depth with agent count; launch specialists only when justified by scope and risk.
- 04Do not copy subagent conclusions into the report without independent coordinator synthesis.
- 05Do not classify an unconfirmed product choice as a defect; use an approval-affecting Question.
- 06Do not automatically consume a generation-1 post-review; return its findings to the user or product owner.
- 07Use `regression-review` or `hack-review` instead when the user asks for those specialized gates.
06