Fix PR Reviews

Fetch PR comments — If a PR exists, fetch all review data:

# Get PR review comments (inline code comments)
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --paginate

# Get PR reviews (top-level review bodies)
gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews --paginate

# Get general issue comments on the PR
gh api repos/{owner}/{repo}/issues/{pr_number}/comments --paginate

Filter for review content — From the fetched comments, keep only those that look like code reviews. Include a comment if it matches ANY of:

• Mentions a file path (e.g., src/foo.ts, components/bar.tsx)
• Contains code blocks or inline code references
• Mentions line numbers
• Uses review language (bug, issue, fix, error, should, missing, incorrect, vulnerability, race condition, unused, leak, etc.)
• Contains a GitHub suggestion block (```suggestion)
• Comes from a known AI reviewer bot or user account
• Is part of a PR review (not just a casual conversational comment)

Exclude comments that are clearly non-review (e.g., "LGTM", "thanks!", merge coordination, CI status discussions).

Collect local review files — If the user provided review files, read them too.

Build a unified issue list — Extract every distinct finding across PR comments and local files. Deduplicate: if multiple sources flag the same issue (same file + same concern), merge them into one entry. Preserve the strongest/clearest description. Track the source of each finding (PR comment URL or local file name).

Triage each finding — Classify every finding into one of:

• Fix — Valid bug, logic error, security issue, or correctness problem. Apply the fix.
• Skip — Ignore if any of these apply:
  • Nit or style-only (naming preferences, formatting, comment wording)
  • Not actually valid (misunderstanding of the code, already handled, false positive)
  • Overly defensive (adds complexity for scenarios that realistically won't occur — e.g., redundant null checks on values guaranteed by the framework, error handling for impossible states, excessive input validation on internal-only code paths)

When in doubt, lean toward skipping. The goal is to fix real bugs, not gold-plate the code.

Fix valid issues — For each "Fix" finding:

• Read the relevant source file if not already read
• Apply the minimal change that addresses the issue
• Do not refactor surrounding code or add unrelated improvements

Report summary — After all fixes, output a brief summary:

## Review fixes applied

### Sources
- PR #<number>: <count> comments fetched, <count> review findings extracted
- <local-file>: <count> findings extracted
- Deduplicated to <total> unique findings

### Fixed
- <file:line> — <one-line description> (source: <PR comment URL or file>)

### Skipped (not valid / nit / overly defensive)
- <one-line description> — <reason skipped>

Commit and push — After all fixes are applied:

• Stage all changed files: git add the specific files that were modified.
• Commit with a descriptive message summarizing the fixes, e.g.: fix: address PR review findings followed by a short list of what was fixed.
• Push to the current branch: git push. This updates the existing PR automatically.
• If the push fails (e.g., remote is ahead), pull with rebase first (git pull --rebase) then push again.