Address PR Comments Guide

Your agent for systematically addressing code review comments on pull requests — understanding reviewer intent, implementing requested changes, and responding constructively to feedback.

When to Use This Agent

Choose Address PR Comments Guide when:

• Reviewing and responding to PR feedback from team members
• Implementing changes requested by code reviewers
• Resolving comment threads with explanations or code modifications
• Understanding ambiguous review comments and deciding on appropriate responses
• Batch-processing multiple review comments on a single PR

Consider alternatives when:

• You need to create the initial PR — use a general coding agent
• You need code review best practices — use a code reviewer agent
• You need to understand the codebase architecture — use an architect agent

Quick Start

Copy
# .claude/agents/address-comments.yml
name: Address PR Comments Guide
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: PR comment response agent that implements review feedback and responds constructively to code review comments

Example invocation:

claude "Review the comments on PR #142 and implement the requested changes — the reviewer asked for better error handling and suggested extracting a utility function"

Core Concepts

Comment Response Framework

Comment Type	Action	Response Pattern
Bug found	Fix the bug	"Good catch — fixed in [commit]"
Style suggestion	Evaluate and apply	"Applied" or "I prefer X because..."
Architecture concern	Discuss or refactor	"Agreed, refactored to..." or "Here's why I chose this approach..."
Question	Explain reasoning	Clear explanation of the design decision
Nitpick	Apply if agreed	"Done" — keep it brief
Out of scope	Acknowledge and defer	"Great idea — I'll create a follow-up ticket"

Comment Prioritization

Priority 1: Blocking (must fix before merge)
  └─ Bugs, security issues, breaking changes

Priority 2: Important (should fix)
  └─ Performance issues, missing tests, error handling gaps

Priority 3: Suggestions (nice to have)
  └─ Refactoring ideas, style preferences, documentation

Priority 4: Nitpicks (optional)
  └─ Naming tweaks, formatting, minor style differences

Configuration

Parameter	Description	Default
auto_implement	Automatically implement requested changes	true
response_style	Response tone (concise, detailed, collaborative)	concise
batch_mode	Process all comments at once vs one-by-one	batch
create_commits	Create separate commits per comment or batch	batch
resolve_threads	Automatically resolve addressed threads	false

Best Practices

1. Address blocking comments first, then work through priorities. Process P1 (bugs, security) before style suggestions. Reviewers expect critical issues fixed before they re-review — spending time on formatting while a security bug remains open signals misaligned priorities.

2. Be concise in responses, not defensive. "Good catch, fixed in abc123" is better than a paragraph explaining how the bug happened. Reviewers appreciate efficiency. Save detailed explanations for genuine design disagreements where context matters.

3. Push back respectfully when you disagree. Not every review comment is correct. When you disagree, explain your reasoning: "I considered that approach, but chose this because [specific reason]. Happy to discuss further if you see a downside I'm missing."

4. Create follow-up tickets for out-of-scope suggestions. When a reviewer suggests improvements that go beyond the PR's scope, acknowledge the value and create a tracked ticket. This validates the feedback without scope-creeping the current PR.

5. Batch related changes into single commits. If three comments all relate to error handling improvements, implement them in one commit with a clear message. This keeps the git history clean and makes the re-review easier.

Common Issues

Reviewer's comment is ambiguous or contradicts another reviewer. Ask for clarification rather than guessing. "I want to make sure I understand — are you suggesting we extract this into a separate function, or inline it? [Other reviewer] suggested the opposite, so I want to align on the direction."

Addressing one comment breaks code in a different area. Before implementing changes, check whether the modification affects other parts of the codebase. Run tests after each change. If a requested refactor would break something else, mention it in your response so the reviewer can adjust their suggestion.

PR has too many comments to address efficiently. When a PR accumulates 20+ comments, it's often a sign the PR is too large. Consider whether splitting the PR into smaller, focused changes would make the review process more manageable for future submissions.