address-pr-comments

Original：🇺🇸 English

Translated

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.

3installs

Sourceabsolutelyskilled/absolutelyskilled

Added on2026-04-09

NPX Install

npx skill4agent add absolutelyskilled/absolutelyskilled address-pr-comments

SKILL.md Content

View Translation Comparison →

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:

bash

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:

bash

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:

bash

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

bash

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

Step 3 - Filter to unaddressed comments

A comment is "unaddressed" if:

It was NOT written by the PR author (the user)
It has no reply from the PR author in its thread
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:

Read the file at the path mentioned in
```
path
```
Understand the reviewer's suggestion in context
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:

bash

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

address-pr-comments

NPX Install

Tags

SKILL.md Content

Address PR Review Comments

When to use this skill

Prerequisites

Core workflow

Step 1 - Identify the PR

Step 2 - Fetch all review comments

Step 3 - Filter to unaddressed comments

Step 4 - Read code context and evaluate each comment

Step 5 - Make code changes for agreed comments

Step 6 - Draft all replies (batch mode)

Step 7 - Present batch to user for approval

Step 8 - Post replies

Error handling

Anti-patterns

References