| name | review-code |
| description | Code-review pipeline as one skill. Subcommands review the current branch diff and report bugs as structured findings (review, the default), reproduce and validate each finding to filter false positives (repro), plan + apply fixes after user approval (fix), and process the review comments a reviewer left on your PR (comments). Use when the user says "review code", "review my changes", "code review", "reproduce the findings", "validate the review", "fix the findings", "plan fixes", "process the PR comments", "address the review comments", or "/review-code". |
| argument-hint | [review | repro | fix | comments] [args] |
Code Review — One Skill
Run the full code-review pipeline as /review-code [sub] [args]. Bundles
the three steps — review the diff, reproduce the findings, fix what's
confirmed — into a single skill with subcommands, so the install is one
unit instead of three sibling skills.
Usage: /review-code [subcommand] [args]
$ARGUMENTS is parsed by the dispatcher below. Read the matched subcommand's
reference file and follow it exactly.
Subcommands
| Subcommand | Reference | What it does |
|---|
review [base-branch] | references/review.md | Review the branch diff (committed + uncommitted) against the merge base and report bugs as a numbered list of inline-style findings. Default subcommand. |
repro | references/repro.md | Validate each finding by executing code — failing test, probe run, tool run — and issue a verdict per finding (Confirmed / False positive / Out of scope / Cannot determine). Never fixes anything. |
fix | references/fix.md | Plan the smallest fix for each confirmed finding, stop at an explicit approval gate, then apply and verify. Never edits before the user signs off. |
comments [PR#] | references/comments.md | Fetch the review comments a reviewer left on your PR, categorize them into a task list, then implement / discuss / decline each, reply on the thread, and push. The inbound counterpart to review. |
Dispatcher
Parse the first whitespace-separated token of $ARGUMENTS:
-
First token is a known subcommand keyword (review, repro,
fix, comments) → read references/<keyword>.md, then follow its
workflow with the remaining $ARGUMENTS (everything after the first
token) as that subcommand's arguments.
-
First token starts with - (e.g. --help, -h) → print the
subcommand table above and stop.
-
First token is anything else, OR $ARGUMENTS is empty → default to
review. Read references/review.md, then follow its workflow with
the full $ARGUMENTS string as its arguments.
This means /review-code ≡ /review-code review, and
/review-code against develop reviews against develop — no need to
type the review keyword.
-
Triggered by natural language (no explicit /review-code) → map
the user's intent to a subcommand using the trigger phrases in each
reference's "When to use" section (e.g. "review my changes" →
review, "are these bugs real" → repro, "fix the findings" →
fix, "address the comments on my PR" → comments). If the intent is
ambiguous between two subcommands, ask.
The pipeline
The three subcommands form an ordered pipeline; each consumes the
previous step's output:
review → numbered findings
repro → per-finding verdicts + reproduction artifacts
fix → approved plan → applied + verified fixes
- Finding numbers are preserved 1:1 across all three steps.
repro validates only — it never fixes.fix skipped-step rule: invoked without a prior repro, it asks
whether to run repro first; if declined, every finding is treated as
unvalidated ("Confirmed (traced only)") and the plan says so.fix never edits code before the user explicitly approves the plan.
comments sits outside this linear pipeline — it's the inbound counterpart.
Where review → repro → fix produces and acts on findings about a local
diff, comments consumes the findings a human reviewer already left on your
PR. It reuses the same discipline (repro to validate a doubtful reviewer
claim, fix's plan-then-approve gate for non-trivial changes) but starts from
GitHub comments rather than a git diff.
