pr-feedback

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:

1. P1 items first, grouped by file when multiple items touch the same file (so edits batch cleanly).
2. Then P2, then Nits.
3. 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.