Pr Fix

PR Review, Fix, and Document

Review a pull request end-to-end: identify issues, post them as a GitHub comment, apply the fixes, push, and document what was changed.

Input: "$ARGUMENTS"

Workflow

1. Identify the PR

• If a PR URL or number is provided, use it
• Otherwise detect from current branch: gh pr view --json number,url,headRefName,baseRefName,state
• If the PR is closed, draft, or merged — stop and tell the user
• If no PR found — stop and tell the user

2. Gather Context

• Get the diff: gh pr diff <number>
• Get changed files: gh pr diff <number> --name-only
• Read CLAUDE.md files in the repo root and in directories containing changed files
• Get PR metadata: gh pr view <number> --json body,title

3. Review the Changes

Read each changed file and identify:

• Bugs — logic errors, off-by-ones, null/undefined handling, race conditions
• Cross-file correctness — when the diff references a type, function, or property defined in another file, follow the import and verify it actually exists and has the expected shape. Don't trust that obj.field is valid just because the syntax looks right — read the type/interface definition.
• CLAUDE.md violations — project convention breaches
• Security issues — injection, auth gaps, data exposure
• Broken error handling — only at system boundaries, not defensive over-validation

Critical: trace references across file boundaries. The diff only shows what changed, but bugs often live at the seam between changed and unchanged code. For every property access, function call, or type usage in the diff that comes from an import, verify the contract in the source file. This is especially important for:

• Accessing properties on types/interfaces defined elsewhere
• Calling functions with changed signatures
• Using enums or constants from other modules

Think like a senior engineer. Skip nitpicks, style preferences, and anything a linter or type checker would catch. Only flag things you'd actually block a PR for.

Score each issue 0–100 confidence. Drop anything below 80.

4. Post the Review

Post as a PR comment via gh pr comment <number> --body "...":

### Code Review

Found N issues:

1. **[Brief description]** — `file.ts:L42-L48`
   [Why this is a problem and what should change]

2. ...

🤖 Reviewed by Claude Code

If zero issues found, post:

### Code Review

No issues found. Checked for bugs, security, and CLAUDE.md compliance.

🤖 Reviewed by Claude Code

Then stop — nothing to fix.

If --dry-run was passed, stop here. Do not apply fixes.

5. Apply the Fixes

For each issue:

• Read the relevant file
• Apply the fix using the Edit tool
• Keep fixes minimal and targeted — fix the issue, don't refactor surrounding code
• If a fix is ambiguous or could break things, skip it and note it as "needs human review" in step 7

6. Commit and Push

• Stage only the files you modified: git add <specific files>
• Commit with a message summarizing the fixes (follow the repo's CLAUDE.md commit format if one exists)
• Push to the PR branch: git push
• Never force-push. Never amend.

7. Document What Was Fixed

Post a follow-up PR comment via gh pr comment <number> --body "...":

### Fixes Applied

Applied N fixes from code review:

1. **[What was fixed]** — `file.ts:L42`
   - **Problem:** [what was wrong]
   - **Fix:** [what was changed and why]

2. ...

[If any issues were skipped:]
### Needs Human Review
- [Issue description] — skipped because [reason]

Commit: <sha>

🤖 Fixed by Claude Code

Rules

• Never force-push or amend existing commits
• Read any file needed to verify correctness (imports, type definitions, callers), but only modify files within the PR's changed-file scope unless a fix requires touching an adjacent file (e.g., adding a missing field to a type definition)
• If the repo has a CLAUDE.md commit format, follow it
• Ambiguous fixes get skipped and documented, not guessed at