/fix-pr-reviews

name: fix-pr-reviews
description: Fetches feedback from a GitHub PR — review-thread comments, ad-hoc PR comments (including those posted as a review's body without a thread), and bot/advisory review submissions — and fixes all of them as they appear (comments before CI). Bot comment-length nits apply verbatim; comments requiring a genuine human decision are NOT auto-fixed and are escalated to the user with options grounded in existing patterns and best practices. After each fix batch, runs pre-commit validation and submits, then waits for CI only when no actionable feedback remains. Loops until all feedback is resolved AND all CI checks have completed. Use when asked to fix PR comments, address review feedback, address PR-level bot reviews (e.g. workweave-bot advisory nits), babysit a PR to merge-ready, or handle review comments.

Fix PR Feedback (Loop Until Done)

Automates fixing PR feedback on a GitHub PR — review threads, ad-hoc PR comments, and bot/advisory reviews (e.g. `workweave-bot` COMMENTED-state reviews with nit lists) — then validating fixes, submitting them, **and continuously looping** until the PR is merge-ready: all feedback resolved, all reviewers done, and all CI checks complete.

**Three sources of feedback — treat all three as first-class:**

1. **Review-thread comments** (`reviewThreads` in GraphQL) — line-anchored feedback attached to a code review. 2. **Issue comments on the PR** (`gh api repos/.../pulls/.../comments`) — ad-hoc PR comments not attached to any review. These include comments posted as a review's body text (visible as the review's `body` field but with `comments: null`/zero threads) — do not skip them just because they are not in `reviewThreads`. 3. **Bot/advisory reviews** with no per-line threads but a populated review body — e.g. `workweave-bot` posting `COMMENTED` reviews that list 6-10 nit-level comment-length suggestions across multiple files. The review body's contents are themselves actionable items even though no GraphQL reviewThread exists.

Fetch all three every iteration. Do not skip the issue-comments and review-body sources just because `reviewThreads` returned items.

**Priority: feedback first, CI second.** Never sit in a CI wait while unresolved feedback exists. As soon as polling surfaces a new item, stop waiting and fix it before resuming CI.

**Do not auto-fix decisions that belong to a human.** Some items don't have one objectively correct resolution — they involve a product/architecture/scope trade-off, multiple defensible approaches, or intent only the author knows. **Never guess on these.** Classify them as **Escalate**: pause that item, surface it to the user with concrete options grounded in the existing codebase patterns and best practices, and let the human choose before you touch the code.

**Bot nit rules — still Fix category, treat as authoritative:** When a bot (e.g. `workweave-bot`, `greptile-apps[bot]`, `cubic`) suggests a concrete code-replacement via a fenced ```suggestion``` block, apply the suggested replacement verbatim. Do not paraphrase, do not push back, do not skip because "the existing wording is fine." The bot's replacement is the authoritative version of "concise." For free-form bot feedback without a `suggestion` block, triage it like any other comment: Fix if straightforward, Escalate if it requires a judgment call.

Prerequisites

• GitHub CLI authenticated: `gh auth status`
• On the PR branch locally, or provide PR number

Important: Commit Workflow

Follow this exact order when committing changes.

1. **Lint/format autofix** — run autofix on changed files so lint changes are included in the commit 2. **Stage specific files** — `git add <specific files>` (only files you changed + lint autofix) 3. **Commit** — `git commit -m "message"` 4. **Push** — `git push`

Priority Order

1. **Comments first** — any unresolved, non-outdated review thread (Fix or Decline) is handled **immediately**. Do not enter a passive CI wait while actionable threads exist. 2. **Escalate genuine human decisions** — threads that need a human judgment call (Escalate category) are **never** auto-fixed. Collect them and present to the user with options; do not block the rest of the loop waiting on them unless they are the only thing left. 3. **CI second** — only when there are **zero** actionable threads, wait for the current head SHA's CI to dispatch and finish. 4. **During CI wait** — poll for new comments in parallel. If polling detects **any** new unresolved thread, **abort the CI wait** and go fix comments (back to step 1). Auto-reviewers often post while CI runs.

High-Level Loop

┌──────────────────────────────────────────────────────────────┐
│ 0. Identify PR and align local branch with pr.headRefName    │
│ 1. Fetch fresh state (threads + reviews + checks for SHA)    │
│ 2. If DONE conditions met → exit                             │
│ 3. If actionable unresolved threads exist →                  │
│    a. Triage threads → Fix / Decline / Skip / Escalate       │
│    b. Fix each Fix thread → reply to declines                │
│    c. Escalate threads: ASK the user, wait for decision      │
│    d. Run pre-commit validation (NEVER skip; see Step 4)     │
│    e. Resolve threads → commit → push                        │
│    f. Go to step 1 (do NOT wait for CI yet)                  │
│ 4. Else (no actionable threads):                             │
│    a. WAIT for head SHA CI to dispatch + finish (Step 6)     │
│       — interrupt if polling finds new threads → step 1      │
│    b. Go to step 1                                           │
└──────────────────────────────────────────────────────────────┘

DONE conditions (ALL must hold against the LATEST head SHA)

The loop exits only when **every** condition is true on the same poll, *after CI has actually dispatched for the current head SHA*:

1. **No unresolved review threads** — every `reviewThread` has `isResolved: true` or `isOutdated: true