pr-feedback

name	pr-feedback
description	Address reviewer feedback on GitHub pull requests by making targeted fixes or explaining disagreements. Use when responding to PR comments.

PR Feedback Handler

Address reviewer feedback on GitHub pull requests by making targeted fixes or explaining disagreements.

CRITICAL: You MUST Reply to Each Comment on GitHub

DO NOT just make fixes locally and push. For EVERY comment you process, you MUST:

1. If you agree: Make a minimal commit, then reply to the comment on GitHub with the commit link
2. If you disagree: Reply to the comment on GitHub explaining why
3. EVERY reply MUST end with: *Comment generated by Claude Code*

If you do not leave replies on GitHub, reviewers will not know their feedback was addressed!

Instructions

When this skill is invoked, follow these steps:

Step 1: Get PR Number

If no PR number is provided, get the current branch's PR:

gh pr view --json number -q '.number'

Step 2: Retrieve All Review Comments

Fetch all review comments (both human and AI reviewers):

# Get PR review comments (inline code comments)
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --jq '.[] | {id, user: .user.login, body, path, line: .original_line, commit_id: .original_commit_id, in_reply_to_id, url: .html_url}'

# Get PR review threads with their resolution status
gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews --jq '.[] | {id, user: .user.login, state, body}'

# Get issue-style comments on the PR
gh api repos/{owner}/{repo}/issues/{pr_number}/comments --jq '.[] | {id, user: .user.login, body, url: .html_url}'

Step 3: Categorize and Batch Comments

Before processing, categorize all comments into two groups:

Group A: Simple, Independent Comments (Use Subagents)

• Typo fixes, variable renames, missing docstrings
• Style/formatting issues
• Simple bug fixes with obvious solutions
• Comments on unrelated files or sections
• Comments that don't require clarifying questions

For Group A: Use the Task tool with subagent_type=general-purpose to address multiple comments in parallel. Each subagent handles one comment independently, makes the fix, commits, and replies.

Example:

Task tool with prompt: "Address PR comment #{id} on {file}: '{comment_text}'. Make the fix, commit with message referencing the comment, and reply to comment #{id} on GitHub with the commit link. End reply with '*Comment generated by Claude Code*'"

Launch multiple subagents in parallel for independent comments to maximize efficiency.

Group B: Complex, Interconnected Comments (Main Context)

• Algorithm or architecture discussions
• Comments that relate to each other (same component, shared logic)
• Comments requiring clarifying questions to the reviewer
• Comments where you might disagree and need discussion
• Comments that may trigger follow-up feedback

For Group B: Process in the main context to maintain full context for:

• Iterative refinement based on reviewer responses
• Understanding how related comments connect
• Handling multi-round discussions

Step 4: Process Group B Comments

For each unresolved comment in Group B:

4a. Analyze the Feedback

Read the comment and determine:

• Is this actionable feedback about the code?
• Is the concern valid and relevant?
• Does it identify a real bug, style issue, or improvement?

Skip comments that are:

• Already resolved
• General discussion/questions (not actionable)
• Approval messages or acknowledgments

4b. If You Agree with the Feedback

1. Make a surgical fix - Change only what's needed to address the specific feedback
2. Commit the change with a clear message:

   git add <specific-file>
   git commit -m "$(cat <<'EOF'
   Fix: <brief description of what was fixed>
   
   Addresses review feedback: <short summary>
   
   Co-Authored-By: Claude Opus 4.5 <[e-mail]>
   EOF
   )"
   

3. Get the commit SHA:

   git rev-parse HEAD
   

4. Reply to the comment with a link to the commit:

   gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies \
     -f body="Fixed in [\`{short_sha}\`](https://github.com/{owner}/{repo}/commit/{full_sha})
   

Comment generated by Claude Code"

#### 4c. If You Disagree with the Feedback

Reply to the comment thread explaining why (2-3 sentences max):

```bash
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies \
-f body="@{reviewer_username} <explanation of why you disagree - 2-3 sentences max>

*Comment generated by Claude Code*"

Note: If the comment is from chatgpt-codex-connector[bot] (Codex), always tag @codex instead of the bot username to invite their response.

Common reasons to disagree:

• The suggested change would break existing functionality
• The current approach is intentional for a specific reason
• The feedback is based on a misunderstanding of the code's purpose
• The suggestion conflicts with project conventions

4d. Handling Iterative Feedback

For complex algorithm or architecture comments, expect multiple rounds:

1. Make initial fix based on your understanding
2. Check for reviewer responses before moving to next comment
3. If reviewer provides clarification or correction, read their response and iterate
4. Keep related comments together - if comments A, B, C all touch the same subsystem, address them as a unit

This is why Group B stays in main context - you need full conversation history to handle: "Actually, I meant X not Y" or "This commit made things worse, please restore..."

Step 5: Wait for Group A Subagents

If you launched subagents for Group A comments:

1. Use TaskOutput to check on subagent completion
2. Verify each subagent successfully committed and replied to its comment
3. Handle any failures by processing those comments manually

Step 6: Push All Commits

After addressing all feedback (wait for any parallel subagents to complete):

git push

Step 7: Report Summary

Provide a summary of actions taken:

• Number of comments addressed with fixes
• Number of comments where you disagreed (with brief reasons)
• Number of comments skipped (already resolved, not actionable)

API Reference

Reply to a review comment

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}/replies \
  -f body="Your response

*Comment generated by Claude Code*"

Reply to an issue comment

gh api repos/{owner}/{repo}/issues/{pr_number}/comments \
  -f body="Your response

*Comment generated by Claude Code*"

Get repo owner and name

gh repo view --json owner,name -q '"\(.owner.login)/\(.name)"'

Example Workflow

Comment: "This function should handle the case where the list is empty"
Analysis: Valid - the function doesn't check for empty input
Action: Add empty list check, commit, reply with commit link

Comment: "Consider using a more descriptive variable name than 'x'"
Analysis: Disagree - 'x' is conventional for coordinates in this context
Action: Reply "@reviewer x is the standard name for x-coordinates in graphics code, keeping for consistency with the domain"

Comment: "Nice work!"
Analysis: Not actionable - skip
Action: None

Notes

• CRITICAL: You MUST reply to comments on GitHub using gh api - do not just make local fixes!
• Always append *Comment generated by Claude Code* to all PR comment replies
• When disagreeing with Codex (chatgpt-codex-connector[bot]), tag @codex to invite their response
• Keep commits atomic - one fix per comment (multiple files OK if needed for one fix)
• Don't refactor beyond what the feedback asks for
• Tag the reviewer in disagreement responses so they get notified
• Skip comments that are already marked as resolved or are just acknowledgments

Parallelization Strategy

Use subagents (Group A) when:

• Comments are on different files with no shared logic
• Fixes are obvious and don't require clarification
• You're confident about the solution
• Comments are style/formatting/typo fixes

Use main context (Group B) when:

• Multiple comments discuss the same algorithm or component
• Comments require reading reference code or papers to understand
• You may need to ask clarifying questions
• The reviewer provided code snippets showing expected patterns
• Previous attempts at fixing were rejected - need iteration

Efficiency tip: Launch all Group A subagents in parallel first, then work through Group B comments sequentially in main context. Check for subagent completion before pushing.