PR Comment Handler Skill

A Claude Code skill for finding open PRs on the current branch and systematically addressing review comments using the GitHub CLI — reading comments, implementing fixes, and responding to reviewers.

When to Use This Skill

Choose this skill when:

• Addressing reviewer feedback on an open pull request
• Reading and categorizing PR review comments by priority
• Implementing fixes for code review comments in bulk
• Responding to reviewers with explanations or acknowledgments
• Tracking which review comments have been addressed
• Resolving PR review threads after implementing fixes

Consider alternatives when:

• You need to create a new PR (use the branch finishing skill)
• You need a code review before submission (use a code review skill)
• You need to set up PR templates or workflows (use a CI/CD skill)

Quick Start

Copy
# Add to your Claude Code project
claude mcp add gh-address-comments

# Address all comments on the current branch's PR
claude "address the PR comments on this branch"

# View and prioritize comments
claude "show me all unresolved PR comments"

Copy
# Prerequisites
gh auth status  # Ensure gh CLI is authenticated

# Find the PR for current branch
gh pr view --json number,title,reviewDecision

# List review comments
gh pr view --json comments,reviews

Core Concepts

Comment Processing Workflow

Step	Action	Command
1. Find PR	Locate open PR for current branch	gh pr view
2. List Comments	Fetch all review comments	gh api repos/{owner}/{repo}/pulls/{pr}/comments
3. Categorize	Group by type: change request, question, suggestion	Parse comment body
4. Prioritize	Order: blockers → change requests → suggestions → nitpicks	Sort by label/tone
5. Implement	Make requested code changes	Edit files
6. Respond	Reply to comments with status	gh api POST
7. Resolve	Mark addressed threads as resolved	gh api GraphQL

Comment Categories

Type	Action Needed	Response Pattern
Change Request	Implement the change	"Done — updated in [commit]"
Question	Answer with explanation	Explain the reasoning
Suggestion	Evaluate and decide	"Adopted" or "Kept as-is because..."
Nitpick	Fix if trivial	"Fixed" or "Noted for future"
Approval	No action	Thank the reviewer

Addressing Comments

Copy
# Fetch all review comments on a PR
gh api repos/owner/repo/pulls/123/comments --jq '.[] | {id, path, line, body, user: .user.login}'

# Reply to a specific comment
gh api repos/owner/repo/pulls/123/comments \
  --method POST \
  --field body="Done — fixed in the latest commit." \
  --field in_reply_to=12345

# Resolve a review thread (GraphQL)
gh api graphql -f query='
  mutation {
    resolveReviewThread(input: { threadId: "THREAD_ID" }) {
      thread { isResolved }
    }
  }
'

Configuration

Parameter	Type	Default	Description
auto_detect_pr	boolean	true	Automatically find PR for current branch
include_resolved	boolean	false	Include already-resolved comments
group_by	string	"file"	Group comments by: file, reviewer, type
auto_respond	boolean	false	Auto-reply with "Done" after implementing
push_after_fixes	boolean	true	Push changes after addressing comments
resolve_threads	boolean	false	Auto-resolve threads after responding

Best Practices

1. Address all comments in one batch — pushing multiple small commits for each comment clutters the PR; make all changes, then push once with a summary commit.

2. Respond to every comment, even if no change is needed — reviewers want to know their feedback was seen; reply with "Kept as-is because..." for comments you choose not to address.

3. Group changes by file, not by comment — when multiple comments affect the same file, make all changes to that file together to avoid merge conflicts within your own commits.

4. Push fixes before responding to comments — respond after the code changes are pushed so your responses can reference the fix commit; this gives reviewers confidence the changes are actually made.

5. Re-request review after addressing all comments — once all comments are addressed and pushed, re-request review from the original reviewers to signal the PR is ready for another pass.

Common Issues

PR has comments from multiple reviewers with conflicting suggestions — Prioritize by the reviewer's authority (maintainer > contributor) and the team's established patterns. When genuinely conflicted, respond asking for consensus.

Some comments reference outdated code — After rebasing, comment positions may not match current code. Use gh api to fetch the original diff context and map it to the current file state.

Too many comments to address in one session — Focus on blockers and change requests first (they block merge). Address suggestions and nitpicks in a follow-up commit, noting which ones you'll handle later.