address-pr-comments

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

激活此技能时，首条回复始终以:speech_balloon: emoji开头。

Address PR Review Comments

处理PR评审评论

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.

自动化实现读取未结PR评审评论、理解每条评论内容、针对有效反馈修改代码、并为每条评论撰写周到回复的完整工作流——全部通过

gh

CLI完成。Agent会判断哪些评论需要采纳，哪些需要礼貌地延后处理，所有回复会先批量整理好供用户审核后再发送。

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

当用户出现以下需求时触发此技能：

需要处理或回复PR评审评论
说“handle my PR feedback”或“fix review comments”
要求回复GitHub PR上的未结评审线程
需要处理其分支上未解决的评审评论
说“address the PR comments”或“respond to reviewer”
需要批量回复PR上所有未结评论

请勿针对以下场景触发此技能：

创建新PR或撰写PR描述
评审他人的PR（这属于代码评审范畴，不是处理评论）
与PR评审评论无关的通用git操作

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.

gh

CLI必须完成认证，可通过以下命令验证：

bash

gh auth status

用户应当处于与PR关联的分支上，或者提供PR编号/URL。

Core workflow

核心工作流

Step 1 - Identify the PR

步骤1 - 识别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.

确定PR编号，如果用户未指定：

bash

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

注意： 仅当当前分支存在已开启的PR时此命令生效。如果执行失败，询问用户获取PR编号或URL。

Step 2 - Fetch all review comments

步骤2 - 拉取所有评审评论

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

拉取PR上所有评审评论（而非Issue评论）：

bash

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

每个评论对象包含：

```
id
```
- 唯一评论ID
```
body
```
- 评审者的评论文本
```
path
```
- 评论关联的文件路径
```
line
```
/
```
original_line
```
- Diff中的行号
```
diff_hunk
```
- 关联的Diff上下文
```
in_reply_to_id
```
- 如果是对另一条评论的回复（线程化评论）
```
user.login
```
- 评论发布者账号

同时拉取评审级别的评论（顶层评审正文）：

bash

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

Step 3 - Filter to unaddressed comments

步骤3 - 筛选未处理的评论

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.

满足以下条件的评论属于“未处理”：

不是PR作者（用户）发布的
其所属线程中没有PR作者的回复
不是机器人发布的评论

要检查评论线程，按

in_reply_to_id

对评论分组。没有PR作者回复的根评论（无

in_reply_to_id

）即为未处理评论。

注意：
in_reply_to_id
字段将回复与其父评论关联，没有该字段的评论是根评论。判定评论是否未处理前，务必检查完整的线程内容。

Step 4 - Read code context and evaluate each comment

步骤4 - 读取代码上下文并评估每条评论

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

针对每条未处理评论：

读取
```
path
```
字段指定的文件内容
结合上下文理解评审者的建议
做出判定：采纳（建议能优化代码）或延后处理（当前实现更优）

采纳标准：

建议修复了实际存在的Bug或边缘 case
能提升可读性、性能或可维护性
符合当前代码遗漏的项目规范
发现了拼写错误、命名问题或文档缺口

延后处理标准（需礼貌说明）：

建议会引入不必要的复杂度
当前实现是有意为之且有充分理由
建议与项目规范或需求冲突
评论是基于对上下文的误解产生的

Step 5 - Make code changes for agreed comments

步骤5 - 针对采纳的评论修改代码

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.

针对每条采纳的评论完成代码修改，记录修改内容：

文件路径和修改内容
对应修改的评论ID

注意： 多条评论可能影响同一个文件甚至同一行代码，谨慎处理避免编辑冲突。如果多个评论指向同一个文件，每次编辑前重新读取最新的文件内容。

Step 6 - Draft all replies (batch mode)

步骤6 - 起草所有回复（批量模式）

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.

发送任何回复前先起草所有评论的回复内容，提交给用户审核。

回复语气指南：

保持谦逊和感恩：“好的发现！”、“感谢指出这个问题！”、“很棒的建议，已更新！”
针对采纳并修改的内容：说明具体做了什么修改
针对延后处理的内容：礼貌解释原因，保持开放讨论的态度
回复简洁：最多1-3句话
绝对不要有防御性或轻蔑的语气

回复模板：

针对已采纳并完成修改的评论：

好的发现！已更新[修改内容简述]。感谢评审！

感谢指出这个问题——你说的对，最新推送已修复。

很棒的建议！已重构为[修改内容]。感谢反馈。

针对延后处理的评论：

感谢你的建议！我考虑过这个方案，但最终选择了[当前方案]，原因是[理由]。如果你觉得这个方案有问题，我们可以进一步讨论。

感谢评审！这里的当前实现是有意为之的——[简要理由]。如果你认为仍有问题请告诉我。

Step 7 - Present batch to user for approval

步骤7 - 批量提交给用户审批

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.

发送前先展示汇总表格：

| # | 文件 | 评论（摘要） | 处理动作 | 回复（草稿） |
|---|------|-------------------|--------|---------------|
| 1 | src/api.ts:42 | 缺失空值检查 | 已采纳-已修复 | "好的发现！已添加空值检查..." |
| 2 | src/utils.ts:15 | 改用lodash实现 | 延后处理 | "谢谢！保留了原生实现，因为..." |

请用户审批、编辑或者跳过特定回复。

Step 8 - Post replies

步骤8 - 发送回复

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.

使用GitHub API发送每条回复：

bash

gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
  -method POST \
  -f body="好的发现！已更新空值检查。感谢评审！" \
  -F in_reply_to={parent_comment_id}

注意： 使用
in_reply_to
将回复归入原有评论线程，不要创建新的顶层评审评论，始终在现有线程中回复。
in_reply_to
的值应当是线程中根评论的
id
。

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

错误	原因	解决方案
`gh: not found`	未安装gh CLI	要求用户安装： `brew install gh`
`HTTP 401`	gh未完成认证	执行 `gh auth login`
PR接口返回 `HTTP 404`	仓库错误或PR不存在	验证PR编号和仓库信息
回复接口返回 `HTTP 422`	`in_reply_to` ID无效	验证评论ID存在且属于当前PR
无未处理评论	所有评论都已回复	告知用户无需操作

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

错误行为	问题	正确做法
采纳所有评论	浪费精力，可能引入不合理的修改	自主判断，当前方案更优时选择延后处理
回复语气有防御性	制造摩擦，不利于协作	保持谦逊：即使延后处理也要先说“感谢你的建议”
未经用户审批就发送回复	用户失去对发布内容的控制权	始终批量汇总后先提交用户审批
作为顶层评论回复	破坏评审线程结构	始终使用 `in_reply_to` 归入原有线程
忽略Diff上下文	可能误解评审者指出的问题	判定前始终读取 `diff_hunk` 和完整文件内容

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

如需特定主题的详细信息，阅读

references/

目录下的对应文件：

```
references/gh-api-reference.md
```
- PR评审和评论相关的完整GitHub API端点