pr-respond

name: pr-respond description: Fetch pull request feedback, digest it and react appropriately. Use this when the user asks to "respond to PR feedback" or "respond to feedback on PR "#123" or similar.

Address PR Feedback

Fetch and address review comments on the current pull request.

Instructions

Step 1: Identify the PR

First, check if there's a PR for the current branch:

gh pr view --json number,url,title,state,reviewDecision,author

If no PR exists, inform the user and stop.

Step 2: Fetch Review Comments

Get all review comments (comments on specific lines of code):

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --jq '.[] | {id, path, line, original_line, diff_hunk, body, user: .user.login, created_at, in_reply_to_id}'

Get the owner/repo from:

gh repo view --json nameWithOwner --jq '.nameWithOwner'

Also fetch general PR comments (not on specific lines):

gh pr view --json comments --jq '.comments[] | {author: .author.login, body: .body, createdAt: .createdAt}'

And fetch review summaries:

gh pr view --json reviews --jq '.reviews[] | {author: .author.login, state: .state, body: .body}'

Step 3: Analyze and Categorize Comments

Group comments into:

1. Actionable code changes - specific requests to modify code
2. Questions - reviewer asking for clarification
3. Suggestions - optional improvements
4. Already resolved - comments that have been addressed in subsequent commits
5. Conversation threads - identify parent/reply relationships via in_reply_to_id

Focus on root comments that haven't been replied to with a resolution.

Step 4: Address Each Comment

For each actionable comment:

1. Navigate to the file and line mentioned in path and line/original_line
2. Read the surrounding context using diff_hunk to understand what the reviewer saw
3. Implement the requested change
4. Track what was changed for the summary

For questions:

1. If answerable by looking at the code, prepare a response
2. If it requires a code change for clarity, make that change
3. Note questions that need the PR author's input

Step 5: Summarize

Provide a summary in this format:

## PR Feedback Summary

**PR:** #<number> - <title>
**Review Status:** <reviewDecision>

### Changes Made
- [ ] <file>:<line> - <what was done> (requested by @<reviewer>)
- [ ] <file>:<line> - <what was done> (requested by @<reviewer>)

### Questions to Answer
- @<reviewer> asked: "<question>" on <file>:<line>
  Suggested response: <response>

### Not Addressed
- <reason why a comment wasn't addressed>

### Next Steps
- [ ] Push changes: `git push`
- [ ] Reply to reviewer comments if needed
- [ ] Re-request review: `gh pr edit --add-reviewer <reviewer>`

Notes

• The line field refers to the line number in the new version of the file; original_line refers to the old version
• The diff_hunk provides context around the commented line, useful when line numbers have shifted
• Comments with in_reply_to_id are replies in a thread - focus on the root comment
• If reviewDecision is "APPROVED", there may still be minor comments worth addressing
• Use gh pr checks to verify CI is passing after changes