How do I install the Pr Review Triage skill?

Run npx skillmds@latest add caidanw/pr-review-triage 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.

Is Pr Review Triage safe to use?

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.

Which AI agents work with Pr Review Triage?

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.

Is Pr Review Triage free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Pr Review Triage?

caidanw (@caidanw) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pr Review Triage by caidanw — Agent Skill

Name: Pr Review Triage
Author: caidanw

Pr Review Triage

Pull PR review comments and triage them — separate substantive feedback from bikeshedding, stale comments, misreads, AI slop, and other noise. Use this skill whenever the user asks to "review my PR comments", "triage feedback", "go through my PR", or wants help deciding what to address vs push back on. Make sure to use this skill anytime the user mentions PR comments or code review feedback, even if they don't explicitly say "triage". Pulls comments via the `gh` CLI, classifies each, and proposes an action with a draft response. Do NOT use for writing PR descriptions, reviewing someone else's PR, or applying the changes — this skill triages and drafts only.

caidanw Updated Sep 17, 2026

File contents

Pull review comments on a PR and triage each one. Figure out what's substantive, what's bikeshedding, and what's noise.

Get the comments

Default source: GitHub via the gh CLI.

If the user gives a PR number or URL, use it. Otherwise list their open PRs and ask which one.

gh pr view <number-or-url> --json reviews,reviewThreads,comments
gh api repos/{owner}/{repo}/pulls/{number}/comments

Pull both review-level comments and inline thread comments. For each, capture: author, body, file + line (if inline), thread resolution status, and the commit SHA the comment was made against. Where possible, note whether the code at that line has changed since the comment was posted.

Classify each comment

Apply labels. Multiple can apply.

Substantive

bug — real correctness, security, or data-integrity issue
design — concrete maintainability/readability point with specific reasoning
domain — surfaces context the author may be missing (constraint, prior decision, downstream impact)

Noise

bikeshed — style/naming/formatting preference, especially where a linter or formatter would settle it
stale — code at that line has changed since the comment; may no longer apply
misread — reviewer misunderstood what the code does
vague — "feels off", "have you considered", no concrete issue
ai-slop — pattern-matched suggestion that ignores context (often verbose, hedged, generic, or restates the diff)
scope-creep — asks for changes outside the PR's stated goal
unfounded — performance/security concern with no measurement or threat model

A comment is noise unless it survives this question: if I made the change they're asking for, would the code be meaningfully better, or just different?

The classification is a draft, not a verdict. The user knows their reviewer, codebase, and team norms — defer to their judgment when they push back.

Triage action

For each comment, recommend one:

Address — make the change
Push back — explain why not
Defer — file an issue, out of scope for this PR
Clarify — ask the reviewer for the missing context (concrete example, threat model, measurement)
Ignore — already resolved or stale; mark resolved without responding

Output

Per comment:

Reviewer + location (file:line or "review-level")
Comment quote (trimmed if long)
Labels
Recommended action + one-line reasoning
If push back or clarify: draft response — direct, no apologetic preamble, no "great point!", no "you're absolutely right"

Group by recommended action so the user can work Address items first, then send drafts.

End with a tally: e.g. "12 comments → 4 address, 5 push back, 2 defer, 1 ignore."

Do not apply code changes or post responses. This skill triages and drafts only.

---name: pr-review-triagedescription: Pull PR review comments and triage them — separate substantive feedback from bikeshedding, stale comments, misreads, AI slop, and other noise. Use this skill whenever the user asks to "review my PR comments", "triage feedback", "go through my PR", or wants help deciding what to address vs push back on. Make sure to use this skill anytime the user mentions PR comments or code review feedback, even if they don't explicitly say "triage". Pulls comments via the `gh` CLI, classifies each, and proposes an action with a draft response. Do NOT use for writing PR descriptions, reviewing someone else's PR, or applying the changes — this skill triages and drafts only.---Pull review comments on a PR and triage each one. Figure out what's substantive, what's bikeshedding, and what's noise.## Get the commentsDefault source: GitHub via the `gh` CLI.If the user gives a PR number or URL, use it. Otherwise list their open PRs and ask which one.```bashgh pr view <number-or-url> --json reviews,reviewThreads,commentsgh api repos/{owner}/{repo}/pulls/{number}/comments```Pull both review-level comments and inline thread comments. For each, capture: author, body, file + line (if inline), thread resolution status, and the commit SHA the comment was made against. Where possible, note whether the code at that line has changed since the comment was posted.## Classify each commentApply labels. Multiple can apply.**Substantive**- `bug` — real correctness, security, or data-integrity issue- `design` — concrete maintainability/readability point with specific reasoning- `domain` — surfaces context the author may be missing (constraint, prior decision, downstream impact)**Noise**- `bikeshed` — style/naming/formatting preference, especially where a linter or formatter would settle it- `stale` — code at that line has changed since the comment; may no longer apply- `misread` — reviewer misunderstood what the code does- `vague` — "feels off", "have you considered", no concrete issue- `ai-slop` — pattern-matched suggestion that ignores context (often verbose, hedged, generic, or restates the diff)- `scope-creep` — asks for changes outside the PR's stated goal- `unfounded` — performance/security concern with no measurement or threat modelA comment is noise unless it survives this question: *if I made the change they're asking for, would the code be meaningfully better, or just different?*The classification is a draft, not a verdict. The user knows their reviewer, codebase, and team norms — defer to their judgment when they push back.## Triage actionFor each comment, recommend one:- **Address** — make the change- **Push back** — explain why not- **Defer** — file an issue, out of scope for this PR- **Clarify** — ask the reviewer for the missing context (concrete example, threat model, measurement)- **Ignore** — already resolved or stale; mark resolved without responding## OutputPer comment:- Reviewer + location (`file:line` or "review-level")- Comment quote (trimmed if long)- Labels- Recommended action + one-line reasoning- If push back or clarify: draft response — direct, no apologetic preamble, no "great point!", no "you're absolutely right"Group by recommended action so the user can work Address items first, then send drafts.End with a tally: e.g. "12 comments → 4 address, 5 push back, 2 defer, 1 ignore."Do not apply code changes or post responses. This skill triages and drafts only.

Frequently asked questions