address-pr-comments

name	address-pr-comments
version	0.1.0
description	Use this skill when addressing, responding to, or resolving PR review comments on GitHub pull requests. Triggers on "address PR comments", "respond to review", "handle review feedback", "reply to PR comments", "fix review comments", or when the user wants to process open review threads on their PR. Uses the gh CLI to fetch unresolved comments, make code changes where agreed, and post batch replies with a humble, thankful tone.
category	engineering
tags	["github","pr-review","code-review","gh-cli","pull-request","review-comments"]
recommended_skills	["git-advanced","clean-code","code-review-mastery"]
platforms	["claude-code","gemini-cli","openai-codex"]
license	MIT
maintainers	[{"github":"maddhruv"}]

When this skill is activated, always start your first response with the :speech_balloon: emoji.

Address PR Review Comments

Automates the workflow of reading open PR review comments, understanding each one, making code changes where the feedback is valid, and posting thoughtful replies to every comment - all via the gh CLI. The agent exercises judgment on which comments to accept vs. respectfully defer, and batches all replies for user review before posting.

---

When to use this skill

Trigger this skill when the user:

• Wants to address or respond to PR review comments
• Says "handle my PR feedback" or "fix review comments"
• Asks to reply to open review threads on a GitHub PR
• Wants to process unresolved review comments on their branch
• Says "address the PR comments" or "respond to reviewer"
• Needs to batch-reply to all open comments on a PR

Do NOT trigger this skill for:

• Creating a new PR or writing a PR description
• Reviewing someone else's PR (that's code-review, not addressing comments)
• General git operations unrelated to PR review comments

---

Prerequisites

The gh CLI must be authenticated. Verify with:

gh auth status

The user should be on the branch associated with the PR, or provide a PR number/URL.

---

Core workflow

Step 1 - Identify the PR

Determine the PR number. If the user doesn't specify one:

gh pr view --json number,title,url -q '.number'

Gotcha: This only works if the current branch has an open PR. If it fails, ask the user for the PR number or URL.

Step 2 - Fetch all review comments

Fetch all review comments (not issue comments) on the PR:

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --paginate

Each comment object contains:

• id - unique comment ID
• body - the reviewer's comment text
• path - file path the comment is on
• line / original_line - line number in the diff
• diff_hunk - surrounding diff context
• in_reply_to_id - if this is a reply to another comment (threaded)
• user.login - who left the comment

Also fetch review-level comments (top-level review bodies):

gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews --paginate

Step 3 - Filter to unaddressed comments

A comment is "unaddressed" if:

1. It was NOT written by the PR author (the user)
2. It has no reply from the PR author in its thread
3. It is not a bot comment

To check threads, group comments by in_reply_to_id. A root comment (no in_reply_to_id) that has no reply from the PR author's login is unaddressed.

Gotcha: The in_reply_to_id field links replies to their parent comment. Comments without this field are root comments. Always check the full thread before deciding a comment is unaddressed.

Step 4 - Read code context and evaluate each comment

For each unaddressed comment:

1. Read the file at the path mentioned in path
2. Understand the reviewer's suggestion in context
3. Decide: agree (the suggestion improves the code) or defer (current approach is better)

Agreement criteria:

• The suggestion fixes a real bug or edge case
• It improves readability, performance, or maintainability
• It follows project conventions the current code missed
• It catches a typo, naming issue, or documentation gap

Defer criteria (respectfully):

• The suggestion would introduce unnecessary complexity
• The current approach was intentional and has good reasons
• The suggestion conflicts with project conventions or requirements
• The comment is based on a misunderstanding of the context

Step 5 - Make code changes for agreed comments

For each agreed comment, make the code change. Track what was changed:

• File path and what was modified
• Which comment prompted the change

Gotcha: Multiple comments may affect the same file or even the same lines. Process them carefully to avoid conflicting edits. Read the file fresh before each edit if multiple comments target the same file.

Step 6 - Draft all replies (batch mode)

Draft replies for ALL comments before posting any. Present them to the user for review.

Reply tone guidelines:

• Be humble and thankful: "Good catch!", "Thanks for flagging this!", "Great suggestion, updated!"
• For agreed + changed: mention the specific change made
• For deferred: explain the reasoning respectfully, stay open to further discussion
• Keep replies concise - 1-3 sentences max
• Never be defensive or dismissive

Reply templates:

For agreed comments where changes were made:

Good catch! Updated [brief description of change]. Thanks for the review!

Thanks for flagging this - you're right. Fixed in the latest push.

Great suggestion! Refactored to [what was done]. Appreciate the feedback.

For deferred comments:

Thanks for the suggestion! I considered this, but went with [current approach] because [reason]. Happy to discuss further if you see issues with this approach.

Appreciate the review! The current implementation is intentional here - [brief reason]. Let me know if you think there's still a concern.

Step 7 - Present batch to user for approval

Before posting, present a summary table:

| # | File | Comment (summary) | Action | Reply (draft) |
|---|------|-------------------|--------|---------------|
| 1 | src/api.ts:42 | Missing null check | Agreed - Fixed | "Good catch! Added null check..." |
| 2 | src/utils.ts:15 | Use lodash instead | Deferred | "Thanks! Kept native impl because..." |

Ask the user to approve, edit, or skip specific replies.

Step 8 - Post replies

Post each reply using the GitHub API:

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
  -method POST \
  -f body="Good catch! Updated the null check. Thanks for the review!" \
  -F in_reply_to={parent_comment_id}

Gotcha: Use in_reply_to to thread the reply under the original comment. Do NOT create a new top-level review comment - always reply in the existing thread. The in_reply_to value should be the id of the root comment in the thread.

---

Error handling

Error	Cause	Resolution
gh: not found	gh CLI not installed	Ask user to install: brew install gh
HTTP 401	gh not authenticated	Run gh auth login
HTTP 404 on PR	Wrong repo or PR doesn't exist	Verify PR number and repo
HTTP 422 on reply	Invalid in_reply_to ID	Verify the comment ID exists and belongs to the PR
No unaddressed comments	All comments already replied to	Inform the user - nothing to do

---

Anti-patterns

Mistake	Why it's wrong	What to do instead
Agreeing with everything	Wastes effort, may introduce bad changes	Exercise judgment - defer when current approach is better
Being defensive in replies	Creates friction, poor collaboration	Stay humble: "Thanks for the suggestion" even when deferring
Posting replies before user approval	User loses control over what's posted	Always batch and present for approval first
Replying as top-level comments	Breaks the review thread structure	Always use in_reply_to to thread replies
Ignoring diff context	May misunderstand what the reviewer is pointing at	Always read diff_hunk and the full file before deciding

---

References

For detailed information on specific topics, read the relevant file from references/:

• references/gh-api-reference.md - Full GitHub API endpoints for PR reviews and comments