pr-comment-workflow

name	pr-comment-workflow
description	Pull GitHub PR review threads and conversation comments via the gh CLI, triage them into verified fixes, implement changes, push updates, and optionally resolve review threads or minimise outdated comments; also poll every 4 minutes (sleep 240) up to 3 times for new feedback.
tags	["github","gh","pr","review","comments","feedback","triage","pull","Request"]

GH PR Comment Workflow

Overview

Work a PR comment workflow loop end-to-end: ask for a PR number, fetch review feedback using gh, validate the issues raised, apply fixes, push updates, then re-check for new comments on a 4‑minute cadence (up to 3 checks total).

Workflow

0) Ask for inputs

• Ask which PR number to work on (and confirm the repo if multiple are in play).
• Ask whether to attempt auto-resolving threads/minimising comments after fixes (default: ask before mutating GitHub state).

1) Prep and checkout

• Ensure gh is authenticated: gh auth status.
• Ensure a clean working tree (or stash): git status --porcelain.
• Checkout the PR branch: gh pr checkout <PR_NUMBER>.
• Check for merge conflicts: gh pr view <PR_NUMBER> --json mergeable,mergeStateStatus. If the PR has merge conflicts, flag this to the user before starting — bot feedback on conflicting files may be stale or irrelevant. Some bots (e.g. CodeRabbit) report conflicting files in their summary comment.

2) Pull feedback

1. issue/PR conversation comments
2. inline review comments
3. review bodies

• Use the bundled helper (preferred; includes thread IDs for resolving):
  • From this repo: scripts/gh_pr_feedback.py --pr <PR_NUMBER> --output /tmp/pr-<PR_NUMBER>-feedback.json --actionable-only
  • If installed as a skill: scripts/gh_pr_feedback.py --pr <PR_NUMBER> --output /tmp/pr-<PR_NUMBER>-feedback.json --actionable-only
  • The helper payload includes:
    • reviewThreads (inline review comments with thread/path context)
    • reviews (top-level review bodies/states)
    • issueComments (top-level PR conversation comments)
  • To fetch only new feedback since the last push to the PR branch: add --since-pr-head (or pass the pushed commit with --since-sha <SHA>).
• Extract nitpicks (these are often hidden inside review body text and missed by the main feedback script):
  • scripts/gh_pr_nitpicks.py --pr <PR_NUMBER> — extracts nitpick items from review bodies
  • Or from an existing feedback file: scripts/gh_pr_nitpicks.py --from-file /tmp/pr-<PR_NUMBER>-feedback.json
  • Filter to a specific bot: --author coderabbitai
  • JSON output: --json or --output /tmp/pr-<PR_NUMBER>-nitpicks.json
  • Returns structured items with file, line range, title, body, and any suggested diffs
• Or, for a quick unstructured view: gh pr view <PR_NUMBER> --comments.

If you need raw API views, fetch all three channels explicitly.

Common reviewer bot logins to look for (not exhaustive — check what's actually on the PR):

• coderabbitai (CodeRabbit)
• gemini-code-assist (Gemini)
• claude-code / anthropic-bot (Claude)
• codex / openai-codex (Codex)
• copilot / github-copilot (Copilot)
• Human reviewers — don't filter these out; include all feedback by default.

Adapt the select() filter below to match whichever reviewers are present on the PR, or omit the filter entirely to capture everything:

• Inline review comments with file context:
  • gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments --paginate --jq '.[] | {id:.id,user:.user.login,path:.path,line:.line,body:.body}'
• Top-level PR conversation comments:
  • gh api repos/<OWNER>/<REPO>/issues/<PR_NUMBER>/comments --paginate --jq '.[] | {id:.id,user:.user.login,updated_at:.updated_at,body:.body}'
• Top-level review bodies:
  • gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/reviews --paginate --jq '.[] | {id:.id,user:.user.login,state:.state,submitted_at:.submitted_at,body:.body}'

To filter to specific bots, add a select(): e.g. select(.user.login=="coderabbitai" or .user.login=="gemini-code-assist").

Keep an in-memory set of handled_thread_ids and handled_comment_ids so the polling rounds only act on new/unhandled feedback.

3) Triage, verify, and fix

Parse bot-specific structures

Bot reviews contain feedback in different places and formats — don't just scan inline thread comments:

• Review bodies: CodeRabbit puts nitpicks and "actionable" summaries in the review body text, often inside collapsible <details> blocks. These are separate from the inline thread comments and easy to miss. CodeRabbit nitpicks are never posted as inline comments — they only appear in the review body under 🧹 Nitpick comments (N) headers. Use scripts/gh_pr_nitpicks.py to extract them as structured items. Gemini puts severity badges and prose in review bodies too.
• Suggestion blocks: Both bots embed ```suggestion blocks (GitHub committable suggestions). These can often be applied directly. CodeRabbit marks some as "committable suggestion" with 📝 headers. Implement the suggestion's intent — don't just blindly apply the diff if the surrounding code has changed.
• AI agent prompts: CodeRabbit includes 🤖 Prompt for AI Agents sections with copy-paste instructions per comment. These are useful summaries of what to do.
• Severity labels: Bots label severity differently. Gemini uses SVG badge images (critical, medium, low). CodeRabbit uses emoji markers (🟡 Minor, 🟠 Major, 🔴 Critical). Prioritise critical/major items first, but still address minor items and nits.

Triage each item

• For each actionable item, restate the issue precisely and verify it (reproduce, inspect code, run existing checks/tests if present).
• Nits and nitpicks: Don't skip items labelled as "nit", "nitpick", or similar. These are still valid feedback — address them alongside other fixes unless explicitly told to ignore them.
• Already-responded items: Check whether the PR author has already replied to a comment (dismissing it, marking it out of scope, or noting it's tracked elsewhere). Don't re-fix what the author intentionally declined — but do flag if a dismissal looks like it missed a genuine bug.
• Duplicate / re-raised comments: Bots may re-post essentially the same feedback after a new push (e.g. Gemini re-raises unresolved items even if already dismissed). Deduplicate by file+line+intent before acting. Track these in handled_thread_ids to avoid redundant work.
• Apply the smallest safe fix that addresses root cause; avoid unrelated refactors.
• Track which thread/comment IDs you addressed in this push so you can resolve/minimise them before triggering a new bot review.
• Commit and push to the PR branch (or a new branch if you cannot push to the PR head; ask if unsure).

4) Reply, resolve, and/or minimise (do this right after pushing)

• Before requesting a new bot review, clean up the threads you just addressed so they don’t stay open / get re-reported.
• Prefer leaving a short reply on each addressed thread/comment that references what changed (and commit SHA if useful).
• For review threads: resolve the thread via GraphQL (if you have permissions):
  • scripts/gh_pr_moderate.py resolve-thread <THREAD_ID>
• For PR conversation comments (non-review-thread): optionally minimise as OUTDATED or RESOLVED (ask first):
  • scripts/gh_pr_moderate.py minimize-comment <COMMENT_NODE_ID> --classifier OUTDATED

If resolving/minimising fails, do not fight it—leave the reply and continue.

5) Request a fresh bot review

• After resolving/minimising the addressed feedback, trigger a re-review from whichever bots are active on the PR. Common trigger commands (check which bots are present first):
  • Gemini: gh pr comment <PR_NUMBER> --body "/gemini review"
  • CodeRabbit: gh pr comment <PR_NUMBER> --body "@coderabbitai review"
  • Other bots may re-review automatically on push, or have their own trigger syntax — check the bot's initial comment for instructions.

6) Poll loop (sleep 240) up to 3 checks total

• After the first fix/push pass, do:
  1. sleep 240
  2. re-fetch feedback (prefer: gh_pr_feedback.py --since-pr-head --actionable-only --output ..., or --since-sha <JUST_PUSHED_SHA>)
  3. address any new/unhandled items, push, and optionally resolve/minimise
  4. repeat once more (so: initial pass + 2 re-checks = 3 total)
• After the third check, ask for further instructions (continue polling, stop, or tackle additional scope).