| name | pr-feedback |
| description | This skill should be used when the user wants to triage a pull request's review feedback and CI status — retrieving inline review comments, review summaries, conversation comments, and failing status checks, then classifying each item as P1 / P2 / Nit and proposing an ordered action plan. Triggers on "review PR feedback", "check PR comments", "what's blocking my PR", "classify review comments", "PR CI failures", "triage PR", or a bare PR number/URL. |
| argument-hint | [pr-number-or-url] |
PR Feedback Triage
Retrieve review feedback and status checks for a pull request, classify each item by priority, and propose an ordered action plan. Triage is read-only — do not edit files, post replies, or re-run CI. Once the user picks which items to act on, hand off to the pr-respond skill, which applies the agreed changes and posts responses (reply + reaction + resolve). Never re-run CI.
1. Resolve the PR
- If the argument is a PR number or URL, use it.
- Otherwise, detect from the current branch:
gh pr view --json number,url,headRefName,baseRefName,state.
- State the resolved PR (
#<n> — <url>) so the user can confirm.
2. Fetch feedback and checks
Run these in parallel (single message, multiple tool calls). Cap any log output aggressively.
-
Inline review comments (threaded): gh pr view has no reviewThreads JSON field — it errors with Unknown JSON field. This is where bot findings (Cursor Bugbot, naboo-ai-reviews, etc.) live, so fetch them via GraphQL. The same query also returns the node id (needed by pr-respond to resolve a thread) and each first comment's databaseId (needed for reply/reaction endpoints):
gh api graphql -f query='query($owner:String!,$repo:String!,$pr:Int!){
repository(owner:$owner,name:$repo){ pullRequest(number:$pr){
reviewThreads(first:100){ nodes{ id isResolved isOutdated path line
comments(first:1){ nodes{ databaseId author{login __typename} body } } } } } }
}' -F owner=OWNER -F repo=REPO -F pr=<n>
Keep id, isResolved, isOutdated, path, line, and comments[].databaseId/author/body. author.__typename gives the human-vs-bot signal for the report's Author field.
-
Review summaries: gh pr view <n> --json reviews — state (APPROVED / CHANGES_REQUESTED / COMMENTED), author, body.
-
Conversation comments: gh api repos/{owner}/{repo}/issues/<n>/comments (owner/repo from step 1).
-
Status checks: gh pr checks <n>. For each FAIL, fetch a short log tail: gh run view --log-failed --job <job-id> | tail -n 50.
Skip threads where isResolved or isOutdated is true, unless a later comment flags a regression.
3. Classify each item as P1 / P2 / Nit
- P1 — blocking: failing required checks; correctness / security bugs; reviewer submitted CHANGES_REQUESTED on this item; missing tests for new behavior.
- P2 — important, non-blocking: design concerns, maintainability, perf tradeoffs, ambiguous behavior, reviewer questions that need an answer before merge.
- Nit: naming, formatting, phrasing, optional refactors, style preferences. Clues: comment starts with
nit:, optional:, consider, suggestion:, or is purely taste.
When in doubt, prefer the higher priority and note the uncertainty.
4. Emit the report
Group by priority (P1 → P2 → Nit). One entry per item:
- Priority — P1 / P2 / Nit
- Source — review-comment | review-summary | conversation | check
- Where —
path/to/file.ts:42 or check name
- Author — 👤
<login> (human) or 🤖 <login> (bot). Mark 🤖 when author.__typename is Bot, the login ends in [bot], or it's a known bot account (naboo-ai-reviews, cursor/Bugbot); otherwise 👤. This is a label only — bot items are still reported and triaged, never filtered out.
- Quote — ≤2 lines from the comment or check failure
- Why — one sentence on the classification
- Disposition — fix (apply the change) | reply (answer, no change) | decline (won't fix) | defer (track for later)
5. Action plan
After the report, emit an ordered plan:
- P1 items first, grouped by file when multiple items touch the same file (so edits batch cleanly).
- Then P2, then Nits.
- Close with 1–3 sentences summarizing overall health (e.g. "2 P1 CI failures + 1 P1 review comment, 3 P2s, 5 nits").
End with: "Tell me which items to act on, or say 'apply all P1' / 'apply all' to proceed." Once the user picks items, invoke the pr-respond skill to act on each per its disposition.
Selecting an item means act on it per its disposition — fix items get the code change, decline/reply items get a reply only. "apply all" does not force a fix on a decline item; pr-respond flags any such mismatch for confirmation.
