From Michael Holley's Dev Workflows
Read all reviews, review comments, and conversation comments on a GitHub PR by number via the gh CLI, then group the feedback into categories and prioritize it into an action list. Use when the user wants to triage, summarize, or get an action plan for PR feedback.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev-workflows:triage-pr-feedbackThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Turn the scattered feedback on a pull request into a single prioritized action list. Read **all** feedback streams on the PR, group each entry into a clear category, prioritize, and present a report that tells the user what to address first. This is a **triage report only** — do not post replies and do not change code. End by surfacing the critical and high-priority items.
Turn the scattered feedback on a pull request into a single prioritized action list. Read all feedback streams on the PR, group each entry into a clear category, prioritize, and present a report that tells the user what to address first. This is a triage report only — do not post replies and do not change code. End by surfacing the critical and high-priority items.
This is distinct from review-with-intent (which validates a diff against a stated goal). Here the input is the humans' feedback, not the code's correctness.
Expected from the user:
123gh is installed and authenticatedFollow this order:
owner/repo (gh repo view --json nameWithOwner -q .nameWithOwner).suggestion blocks.GitHub splits PR feedback across streams that gh pr view alone does not fully expose. Pull each:
# PR metadata + review summaries (state: APPROVED / CHANGES_REQUESTED / COMMENTED)
gh pr view <number> --json number,title,state,isDraft,author,reviews,body
# Inline review comments (code line comments, incl. ```suggestion blocks)
gh api repos/{owner}/{repo}/pulls/<number>/comments --paginate
# General conversation comments (not attached to code)
gh api repos/{owner}/{repo}/issues/<number>/comments --paginate
Resolved/outdated detection:
"position": null is outdated (its line no longer exists in the diff).gh api graphql -f query='query($owner:String!,$repo:String!,$pr:Int!){
repository(owner:$owner,name:$repo){ pullRequest(number:$pr){
reviewThreads(first:100){ nodes{ isResolved isOutdated
comments(first:1){ nodes{ body author{login} } } } } } } }' \
-F owner=<owner> -F repo=<repo> -F pr=<number>
Group each actionable entry into exactly one:
Reported separately, excluded from the action list:
When a comment fits two categories, pick the higher-impact one. A CHANGES_REQUESTED review with no specifics still counts as a critical signal.
Within a priority, rank by: repeated by multiple reviewers > maintainer/code-owner author > recency.
Present, in this order:
#<number> <title> · state · draft? · review verdicts (e.g. "2 approved, 1 changes-requested").file:line (if inline) · author · one-line summary · quoted suggestion if present.Quote reviewers' own words for the summary; do not invent feedback. If a stream is empty, say so rather than omitting it.
gh pr view --comments omits much inline review detail — always hit the /pulls/.../comments API.--paginate, or later comments are silently lost.<owner>/<repo> is the base repo; confirm if the remote is a fork.npx claudepluginhub michaelholley/cc-plugins --plugin dev-workflowsCreates bite-sized, testable implementation plans from specs or requirements, with file structure and task decomposition. Activates before coding multi-step tasks.