Handles a rejected PR (changes requested): reads review comments, fixes the code, commits, pushes, and re-requests review. Use when a PR was rejected, has changes requested, review feedback needs to be addressed, or the user says /fix-pr.
Receives a rejected or "changes requested" PR, understands the review feedback, fixes the code accordingly, and re-requests review from the original reviewers.
Determine which PR to fix:
gh pr viewFetch PR state and confirm it has review feedback:
gh pr view <number> --json number,title,state,headRefName,baseRefName,reviewRequests,reviews,url
If the PR is already merged or closed, inform the user and stop.
Ensure we're on the correct branch:
git fetch origin
git checkout <headRefName>
git pull origin <headRefName>
If there are uncommitted local changes, warn the user and ask how to proceed (stash, commit, or abort).
Fetch every piece of feedback — inline comments, review summaries, and conversation threads:
# Review summaries (CHANGES_REQUESTED, COMMENTED, etc.)
gh api repos/{owner}/{repo}/pulls/<number>/reviews --jq '.[] | select(.state == "CHANGES_REQUESTED" or .state == "COMMENTED") | {author: .user.login, state: .state, body: .body}'
# Inline review comments (file, line, body)
gh pr view <number> --json reviewThreads --jq '.reviewThreads[] | select(.isResolved == false) | {path: .comments[0].path, line: .comments[0].line, comments: [.comments[] | {author: .author.login, body: .body}]}'
Also check for general PR comments (not inline):
gh api repos/{owner}/{repo}/issues/<number>/comments --jq '.[] | {author: .user.login, body: .body}'
For each unresolved feedback item, classify it:
| Category | Example | Action |
|---|---|---|
| Code change | "This should use Optional instead of null check" | Edit the file |
| Missing logic | "Handle the case where list is empty" | Add code |
| Remove code | "This is dead code, remove it" | Delete code |
| Test needed | "Add a test for this edge case" | Create/modify test |
| Question | "Why did you choose this approach?" | Respond as PR comment (ask user) |
| Style/naming | "Rename this to follow convention" | Edit the file |
| Architecture | "This should be in a separate service" | May require significant refactor — flag to user |
Present the plan to the user:
## Fix Plan for PR #<number>
### Feedback from @reviewer1:
1. [file.java:42] "Use Optional instead of null check" → **Will fix**: wrap return in Optional
2. [file.java:78] "Add test for empty list" → **Will fix**: add test case
### Feedback from @reviewer2:
3. [Service.java:15] "This should be extracted to a util" → **Needs discussion**: significant refactor, want to proceed?
### Questions (will not auto-fix):
4. [file.java:90] "Why this approach?" → **Need your input** to respond
Proceed with fixes 1-2? (y/n)
Wait for user approval before making changes.
For each approved fix:
Rules for applying fixes:
After all fixes are applied:
# Check what changed
git diff --stat
git diff
# Make sure no files were accidentally modified
git status
Present the summary of changes to the user. If the project has a build/test command, suggest running it.
Stage and commit the fixes with a clear message referencing the PR:
git add <specific-files>
git commit -m "$(cat <<'EOF'