# Pr Feedback

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

- Skill: `experientiallabs/pr-feedback` (Agent Skill)
- Install (CLI): `npx skillmds@latest add experientiallabs/pr-feedback`
- Raw SKILL.md: https://api.skillmd.com/api/skills/experientiallabs/pr-feedback/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: experientiallabs (https://skillmd.com/u/experientiallabs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/experientiallabs/pr-feedback

---


# 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:

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

### Step 2: Retrieve All Review Comments

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

```bash
# 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:
   ```bash
   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 <noreply@anthropic.com>
   EOF
   )"
   ```
3. **Get the commit SHA**:
   ```bash
   git rev-parse HEAD
   ```
4. **Reply to the comment** with a link to the commit:
   ```bash
   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):

```bash
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
```bash
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
```bash
gh api repos/{owner}/{repo}/issues/{pr_number}/comments \
  -f body="Your response

*Comment generated by Claude Code*"
```

### Get repo owner and name
```bash
gh repo view --json owner,name -q '"\(.owner.login)/\(.name)"'
```

## Example Workflow

```text
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.