Pr Fix

PR Fix

Prerequisites

• gh CLI authenticated and available
• The repo must be cloned locally
• Working tree should be clean (no uncommitted changes) before starting

Workflow

Step 1: Identify the PR

If the user provides a PR number, use it. Otherwise, detect the current branch and find the open PR:

gh pr list --head "$(git branch --show-current)" --json number,title,url --jq '.[0]'

Step 2: Checkout the PR branch

Ensure you are on the correct branch. If not already on it, check it out:

gh pr checkout <NUMBER>

Step 3: Fetch all review comments

Fetch both inline review comments and general PR conversation comments:

# Inline code review comments (attached to specific lines)
gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate

# General PR-level comments (conversation thread)
gh api repos/{owner}/{repo}/issues/{number}/comments --paginate

# PR review summaries (review bodies submitted with approve/request changes)
gh api repos/{owner}/{repo}/pulls/{number}/reviews --paginate

Filter out comments prefixed with [cursor-auto-review] — those are machine-generated and should be ignored.

Step 4: Evaluate each comment

For every review comment, decide how to handle it:

1. Fix it — the issue is clear and the fix is straightforward. Apply the fix locally. Choose the best solution, not necessarily what the reviewer literally suggested. If you see a better approach, use it.
2. Skip it — the suggestion doesn't make sense, is wrong, or would make the code worse. Note why in the report.
3. Flag it — the issue is unclear, the right fix is ambiguous, or the comment is too vague to act on. Do NOT attempt a fix. Flag it for the user's attention.

Guidelines:

• Not all suggestions need to be implemented. Reviewers can be wrong or vague.
• When a reviewer raises a valid point but proposes a bad solution, fix the underlying issue your way.
• When the issue itself is unclear, flag it — don't guess.
• Do NOT add code comments that don't need to be there. Every code change should look like a developer wrote it, not a bot.

Step 5: Apply fixes locally

Make changes directly to the local files. Do NOT:

• git commit
• git push
• Create new branches
• Run any git operations that modify history

The user will review and commit when ready.

Step 6: Generate the report

Write a report to pr-fix-report.md in the repo root. Format:

# PR Fix Report — PR #<NUMBER>

## Needs Attention

These comments require your review — either the issue was unclear, I chose a different approach than suggested, or I decided not to fix.

| # | File | Comment | Action | Why |
|---|------|---------|--------|-----|
| 1 | `path/to/file.go:42` | Reviewer said X | **Flagged** — unclear what the intended behavior should be | |
| 2 | `path/to/file.go:88` | Reviewer suggested Y | **Fixed differently** — used Z instead because ... | |
| 3 | `path/to/other.go:15` | Reviewer asked for W | **Skipped** — suggestion would break ... | |

## Fixed

| # | File | Comment | What I did |
|---|------|---------|------------|
| 4 | `path/to/file.go:20` | Missing nil check | Added nil check before dereference |
| 5 | `path/to/util.go:55` | Unused error return | Now returns and handles the error |

## Skipped (no action needed)

| # | File | Comment | Why |
|---|------|---------|-----|
| 6 | `path/to/file.go:10` | Style preference | Not a functional issue |

Rules for the report:

• "Needs Attention" section comes first — these are the items the user must look at
• One line per comment. Keep descriptions to one sentence.
• Include the file path and line number from the review comment
• Include a brief quote or paraphrase of the reviewer's comment
• For "Fixed differently" items, briefly explain what you did instead and why