| name | triage-review |
| effort | high |
| description | Fetch unresolved review comments on a GitHub PR (Copilot bot + human reviewers), verify each against the current code, and classify as Address / Skip / Optional / Discuss with a one-line rationale. Use when the user asks which review comments to address, to triage Copilot/reviewer feedback, sort signal from noise on a PR, or decide what makes sense to fix and what not. Don't use to reply to or resolve threads (out of scope — this is read-only), or to generate a fresh review (use /code-review or /review). |
| argument-hint | [PR-number-or-branch] |
Triage Review Comments
Consume the review comments already on a PR — Copilot and human reviewers — and sort them into what's worth fixing and what isn't. This is judgment, not a fresh review: each comment is verified against the current code before a verdict.
Read-only. Never reply to threads, resolve conversations, or post anything. The output is a decision aid for the user.
Distinct from siblings: /code-review and /review generate new findings; this skill evaluates existing reviewer comments.
Workflow
-
Fetch with gh — pull the PR's review comments (default to the current branch's PR). Cover both inline thread comments and top-level review summaries, from Copilot and human reviewers. Keep only unresolved threads — resolution state lives in the GraphQL reviewThreads field (isResolved), not REST pulls/comments, so reach for gh api graphql when you need to filter out resolved/outdated noise. Capture author, path, line, and body for each. No unresolved comments → report that and stop.
-
Verify each against current code — read the file at path:line and confirm the comment still applies. Reviewers (especially bots) comment on stale diffs and miss surrounding context. An outdated: true thread defaults toward Skip unless the concern still holds in the current code. Completion: every comment has been checked against the actual code, not judged from its text alone.
-
Classify each comment using the rubric below. Every verdict carries a one-line rationale grounded in what you saw in step 2.
-
Output the triage table — grouped Address-first (see Output). Completion: every fetched comment appears in the table with a verdict and rationale.
-
Offer to fix — ask whether to implement the Address items. On yes, hand them to /tdd (test-first). Don't auto-implement; don't touch Skip/Optional/Discuss items.
Rubric
| Verdict | When |
|---|
| Address | Verified against current code as a real bug, risk, correctness gap, or clearly valid improvement. |
| Skip | Wrong, false positive, outdated (code already changed), contradicts an established codebase convention, or outside this PR's scope. Rationale must cite the evidence, not just assert it. |
| Optional | Subjective/style/preference with no correctness impact — the user's call. |
| Discuss | Valid concern needing a decision you can't make alone (product tradeoff, breaking change, architectural direction). |
- Verify before judging. A comment's confidence is not evidence — Copilot produces confident false positives. Ground every verdict in the current code.
- Prefer a specific rationale over a category label: "Skip —
user is already null-checked at line 40" beats "Skip — not applicable".
Output
## Triage: PR #<n> — <title> (<count> unresolved)
### Address (<n>)
- **`path:line`** · @author — <comment gist>
→ <rationale>
### Optional (<n>)
- ...
### Discuss (<n>)
- ...
### Skip (<n>)
- **`path:line`** · @author — <comment gist>
→ <why it doesn't apply, citing the code>
Error handling
gh pr view fails → run gh auth status; if not on a PR branch, ask for the PR number.- A commented file was deleted or renamed in the PR → note it and lean toward Skip (the concern likely moved).
- Copilot comment references a line outside the diff → treat as low-signal; verify the surrounding code before trusting it.
