fix-pr-feedback

Fix PR Feedback

Fetch unresolved review feedback on a PR — from any author, including copilot, human reviewers, or other automation — triage each item with the user, validate and apply fixes, run linters and tests, commit (amend or follow-up depending on review state), push, and reply to dismissed comments with threaded replies.

Works for any repo via the gh CLI; derive owner/repo from gh repo view rather than hardcoding.

Scope: both inline review-thread comments (attached to a file/line) and substantive top-level PR conversation comments.

Step 1: Identify the PR

• If $ARGUMENTS is provided, use it. Accept either a PR number or a full URL (https://github.com/{owner}/{repo}/pull/{number} — extract owner/repo/number from the URL).
• Otherwise auto-detect: a. Try gh pr view --json number --jq .number (works when checked out on the PR's branch). b. If that fails, search by branch name: gh pr list --head $(git branch --show-current) --json number --jq '.[0].number'.
• If neither works, ask the user for the PR number.
• Derive {owner}/{repo} from gh repo view --json nameWithOwner --jq .nameWithOwner (or from the URL).
• Store the PR number and owner/repo for all subsequent steps.

Step 2: Verify the correct, current branch

• Get the PR's branch: gh pr view <N> --json headRefName --jq .headRefName
• Compare with git branch --show-current.
• If they differ, warn the user and offer to git checkout <pr-branch> && git pull --ff-only. Do not proceed until on the PR branch — file paths and line numbers in comments only make sense against the PR branch's content.
• Check the branch is current, and rebase if it's behind. Determine the base branch (BASE=$(gh pr view <N> --json baseRefName --jq .baseRefName), usually main), then git fetch origin "$BASE" && git log --oneline HEAD..origin/$BASE. If that shows any commits, the branch is behind — rebase it: git rebase origin/$BASE, resolving conflicts before applying fixes. This repo requires branches be up-to-date with main to merge, so the rebase has to happen eventually anyway — do it now. If the rebase does not complete cleanly (conflicts, or a nonzero exit leaving the repo mid-rebase), stop and surface it to the user — never edit, commit, or push while mid-rebase. Confirm the rebase finished (git status shows no rebase in progress) before continuing. Do not talk yourself out of it because the commented file is new or its lines won't shift: a behind branch can still conflict on shared files you aren't touching for the comments (plugin manifests, version bumps, lockfiles, changelogs), and those conflicts surface only on rebase. Do the rebase before the Step 3 fetch; if you rebase after already fetching, re-run the entire Step 3 fetch — a rebase shifts line/path, isOutdated, and resolution state, so stale data would point fixes at the wrong place. (A rebase rewrites history → the later push needs --force-with-lease. Note: rebasing + force-pushing an approved PR usually dismisses its approvals — re-check reviewDecision in Step 7 afterward, since the PR may no longer be approved.)

Step 3: Fetch unresolved feedback

• Use the GraphQL API to fetch inline review threads with resolution/outdated status:

  gh api graphql -f query='{
    repository(owner: "<owner>", name: "<repo>") {
      pullRequest(number: <N>) {
        reviewThreads(first: 50) {
          nodes {
            isResolved
            isOutdated
            comments(first: 1) {
              nodes { databaseId author { login } body path line }
            }
          }
        }
      }
    }
  }'
  

• Filter to threads where isResolved == false. Do not filter by author — every unresolved thread is in scope. Exclude replies (a thread's first comment is the top-level one).
• Also fetch top-level conversation comments: gh pr view <N> --json comments. Filter out automation noise. Include substantive ones in the triage table with line shown as (top-level). These are replied to via the issue-comments endpoint, not a thread reply (see Step 8).
• Note isOutdated status for context (outdated threads point at changed code — likely stale).
• For each comment, extract databaseId (as id), path, line, isOutdated, author.login, and parse a title + description out of the body:
  • If author.login is cursor[bot] or cursor (bugbot has structured output worth using): title = first ### heading; severity = the **X Severity** pattern; description = text between <!-- DESCRIPTION START --> and <!-- DESCRIPTION END -->. Note any "Triggered by learned rule" footer.
  • Otherwise (human reviewers, other bots): title = first non-empty line of the body (truncated to ~80 chars); description = the full body; severity = N/A.
• Stop only when both sources are empty — no unresolved inline review threads and no substantive top-level conversation comments. Resolved inline threads do not let you skip actionable top-level comments, and vice versa. If both are empty, report "No unresolved review comments on this PR" and stop.

Step 4: Validate first, then present

Before asking the user what to do, do a first pass on each comment as a senior engineer would:

• Read and show the relevant file + surrounding lines for context.
• Check whether the issue still applies in the current code. If the flagged pattern is no longer present (a later commit already addressed it), mark the comment "Already resolved" and exclude it from the actionable options below.
• Form a quick judgment on whether each remaining concern is valid.

Present a summary table to the user:

| # | Author | Title | Severity | File | Line | Outdated? | Status |

The Severity column is filled in only for bugbot comments; otherwise show —. Status is Already resolved or Open.

Step 5: Pick a mode

Present numbered options (use AskUserQuestion) for how to handle the open comments:

1. Provide replies — the user gives replies for specific comment numbers (e.g. "reply to #1 with 'fixed', skip #2"); post as-is after confirmation.
2. Analyze and draft replies — read the code context for each comment, draft replies, and present them for approval before posting (no code changes).
3. Analyze, validate, and fix — analyze whether each concern is valid; if so, apply fixes in the codebase and draft replies summarizing what was done. Present both the code changes and the draft replies for approval before posting.
4. Skip — skip specific comments or all.

The user may also scope by number (e.g. "do option 3 for #1 and #2, skip #3"). Collect decisions into a fix list and a reply/dismiss list.

Step 6: Apply fixes (option 3)

For each item in the fix list:

a. Read the relevant file and lines. b. Analyze the issue and apply the fix. c. Identify which commit in the PR introduced the affected lines (reuse $BASE from Step 2):

• git log "origin/$BASE..HEAD" --follow --format="%H %s" -- <file> to find candidate commits.
• git log "origin/$BASE..HEAD" --oneline for context if needed. d. Track which files were modified and which commits they belong to.

After all fixes are applied, run verification. Match the linter/tests to the file types changed:

• Ruby (.rb): rubocop <files>
• JS / TS (.js, .jsx, .ts, .tsx): the project's lint command (e.g. npx eslint <files>); component tests if applicable.
• Markdown (.md): npx prettier --check <files>
• Other languages: use the repo's configured linter/formatter and test runner; prefer whatever the project already standardizes on.
• Fix any lint/test errors that arise, iterating until clean.

Step 7: Commit and review

• Choose a commit strategy from the PR's review state (gh pr view <N> --json reviewDecision):
  • Not yet approved: amend into the originating commit(s) (from Step 6) to keep history clean.
    • All fixes belong to the current HEAD commit: git add <files> && git commit --amend --no-edit.
    • Fixes belong to an earlier commit, or span several commits: --amend only touches HEAD, so do not use it here — it would fold every staged fix into HEAD and misplace them. Instead, stage and create a fixup per originating commit (git add <files-for-that-commit> && git commit --fixup=<sha>), then fold them in with git rebase --autosquash origin/$BASE (a rewrite → push needs --force-with-lease). Commit each commit's fixes separately so each fixup targets the right <sha>.
  • Already approved: prefer a separate follow-up commit (git add <files> && git commit -m "...") so re-reviewers see exactly what changed since approval, instead of rewriting approved history.
• GATE: Re-run linters on all changed files after committing. Do NOT push until all linters pass cleanly. If a new offense was introduced by the fix, resolve it (refactor, or a targeted disable comment) and re-commit before proceeding.
• GATE: Present a summary of all changes (fixes applied, draft replies) and ask the user to confirm before pushing or replying to any comments. Do NOT push or post replies until the user approves.
• Push: plain git push for a new follow-up commit; git push --force-with-lease if you amended or rebased.
• GATE: Verify the push actually landed before posting any replies. Check the push exit status; if it was rejected (e.g. a stale --force-with-lease lease, or non-fast-forward), stop and surface it — do not proceed to Step 8 and post replies claiming "fixed in <commit>" for a commit that never reached the remote. Confirm git rev-parse HEAD matches the remote (git rev-parse @{u}, or re-check the PR head) before replying.

Step 8: Post replies

After user approval, and after any code changes are pushed (so replies can reference the actual fix commit), reply using the endpoint that matches the comment type:

• Inline review-thread comment: gh api repos/{owner}/{repo}/pulls/{N}/comments/{ID}/replies -X POST -f body="<reply>" — this posts a threaded reply attached to the original comment's file/line. For multi-line bodies or bodies with quotes, use a heredoc:

  gh api repos/{owner}/{repo}/pulls/{N}/comments/{ID}/replies -X POST --input - <<'EOF'
  {"body": "your reply here"}
  EOF
  

• Top-level conversation comment: gh api repos/{owner}/{repo}/issues/{N}/comments -f body="<reply>" — GitHub has no threaded reply for these, so this posts a new top-level comment; @-mention the reviewer so they're notified.
• Never post a single large top-level comment to cover inline feedback. Inline feedback gets per-comment threaded replies.
• For human reviewers, frame the reply as a response to them — acknowledge the suggestion and explain what you did or why you're not taking it. For bugbot, a short reason is fine.
• Verify each reply posted by checking the returned URL/ID.

Output

Summary table:

| # | Author | Title | Action | Commit |

Followed by the PR URL.

Rules

• Never push or post without explicit user confirmation. Always present the planned changes and replies and wait for approval.
• Always reply inline (threaded) for inline comments, never a single top-level comment.
• Gate every linter pass before pushing; iterate until clean.