review-address

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review Address — Reply to Every PR Review Comment

Review Address — 回复所有PR评审评论

Goal: Post an inline reply to every reviewer comment on the PR. Code fixes and push-backs are the content of those replies — but the replies themselves are the deliverable. The skill is NOT complete until every comment has a response posted via the GitHub API.

This applies equally to GitHub Copilot's review comments, other review bots, and human reviewers — every non-author comment gets a reply.

目标：为PR上的每条评审者评论发布inline回复。 代码修复和反驳是这些回复的内容，但回复本身是交付成果。只有通过GitHub API为所有评论发布回复后，该技能才算完成。

这一规则同样适用于GitHub Copilot的评审评论、其他评审机器人以及人类评审者——所有非作者的评论都将得到回复。

Process (Default — Not in Plan Mode)

流程（默认模式——非计划模式）

1. Detect PR

1. 检测PR

bash

gh pr view --json number,author -q '{number: .number, author: .author.login}'

Capture PR number + PR_AUTHOR. Stop with message if no open PR on current branch.

bash

gh pr view --json number,author -q '{number: .number, author: .author.login}'

捕获PR编号和PR_AUTHOR。如果当前分支没有打开的PR，则停止并提示消息。

2. Fetch & Process All Comments

2. 获取并处理所有评论

Get owner/repo from

gh repo view --json owner,name

Three paginated API calls (no login filter):

Review comments (inline):

bash

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

Issue comments (top-level):

bash

gh api repos/{owner}/{repo}/issues/$PR/comments --paginate

Reviews (for reviewer identity):

bash

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

Discard all comments where

.user.login == PR_AUTHOR

Keep every review comment where

.user.login != PR_AUTHOR

. Compute

handled_by_author

(whether PR_AUTHOR already replied in thread) only as metadata for reply wording — never skip a comment because of it.

Inline comments: check

in_reply_to_id

chain for a reply where

.user.login == PR_AUTHOR

→ set

handled_by_author: true

Top-level comments: check subsequent comments by PR_AUTHOR → set
```
handled_by_author: true
```

Display comments grouped by

user.login

for triage clarity:

Bots first (logins ending in
```
[bot]
```
)
Then humans alphabetically

GitHub Copilot's review comments come from the login

copilot-pull-request-reviewer[bot]

— it's just another bot reviewer, so it sorts into the bots group and gets triaged and replied to like any other.

Triage every kept comment (address or push back), even if already handled/resolved.

通过

gh repo view --json owner,name

获取仓库所有者/仓库名称。

三次分页API调用（无登录筛选）：

评审评论（inline）：

bash

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

Issue评论（顶层）：

bash

gh api repos/{owner}/{repo}/issues/$PR/comments --paginate

评审记录（用于识别评审者）：

bash

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

丢弃所有

.user.login == PR_AUTHOR

的评论。

保留所有

.user.login != PR_AUTHOR

的评审评论。仅将

handled_by_author

（PR作者是否已在该线程中回复）作为回复措辞的元数据——绝不会因为该字段而跳过评论。

Inline评论： 检查

in_reply_to_id

链中是否存在

.user.login == PR_AUTHOR

的回复 → 设置

handled_by_author: true

顶层评论： 检查PR作者后续的评论 → 设置
```
handled_by_author: true
```

按

user.login

分组显示评论，以便清晰分类处理：

先显示机器人（登录名以
```
[bot]
```
结尾）
然后按字母顺序显示人类评审者

GitHub Copilot的评审评论来自登录名

copilot-pull-request-reviewer[bot]

——它只是另一个机器人评审者，因此会被归类到机器人组，并像其他评审者一样被分类处理和回复。

对所有保留的评论进行分类处理（处理或反驳），即使评论已被处理/解决。

3. Make Code Fixes

3. 修复代码

For each comment triaged as "address":

Make the minimal KISS fix in the code
No distinction between bot/human

For push-backs: prepare clear reasoning response (no code changes).

对于每个被分类为“处理”的评论：

在代码中进行最小化的KISS修复
不对机器人/人类评审者做区分

对于反驳的情况：准备清晰的理由作为回复（无需修改代码）。

4. Commit & Push

4. 提交并推送代码

Only if code changes were made. Write a conventional commit that describes the actual fixes — not a static placeholder. The single commit covers everything from Step 3.

Type: pick from
```
fix
```
/
```
refactor
```
/
```
perf
```
/
```
docs
```
/
```
test
```
/
```
style
```
/
```
chore
```
based on what the changes actually did. If the addressed comments are a mix, use the type of the most significant change and mention the rest in the body.
Scope (optional): the module / area touched (e.g.
```
auth
```
,
```
api
```
,
```
parser
```
). Omit if changes span many areas.
Subject: imperative, lowercase, no period, ≤72 chars, summarizing the substance of the fix — not "address PR review feedback".
Body (optional, blank line after subject): bulleted list when several distinct comments were addressed in one commit.

bash

git add -A
git commit -m "<type>(<scope>): <imperative summary of the fix>" \
           -m "- <comment 1 — what changed>" \
           -m "- <comment 2 — what changed>"
git push

Examples:

fix(auth): reject empty bearer tokens before signature check

refactor(parser): extract token loop into iterator to fix off-by-one

perf(api): memoize permission lookups noted in review

Skip this step entirely if all comments were push-backs (no code changes).

仅当有代码变更时执行此步骤。编写一个conventional commit来描述实际的修复内容——不要使用静态占位符。单次提交涵盖步骤3中的所有变更。

类型：根据变更实际内容从
```
fix
```
/
```
refactor
```
/
```
perf
```
/
```
docs
```
/
```
test
```
/
```
style
```
/
```
chore
```
中选择。如果处理的评论涉及多种类型，使用最主要变更的类型，并在提交体中提及其他类型。
范围（可选）：涉及的模块/领域（例如
```
auth
```
、
```
api
```
、
```
parser
```
）。如果变更涉及多个领域，则省略。
主题：祈使语气、小写、无句号、≤72字符，总结修复的实质内容——不要写“处理PR评审反馈”。
提交体（可选，主题后空一行）：当一次提交处理多个不同评论时，使用项目符号列表。

bash

git add -A
git commit -m "<type>(<scope>): <imperative summary of the fix>" \
           -m "- <comment 1 — what changed>" \
           -m "- <comment 2 — what changed>"
git push

示例：

fix(auth): reject empty bearer tokens before signature check

refactor(parser): extract token loop into iterator to fix off-by-one

perf(api): memoize permission lookups noted in review

如果所有评论都被反驳（无代码变更），则完全跳过此步骤。

5. Reply to Every Comment

5. 回复所有评论

This is the primary deliverable. Reply to every triaged comment via appropriate endpoint:

Inline comments:

bash

gh api repos/{owner}/{repo}/pulls/$PR/comments/{id}/replies -X POST -f body="Fixed — [brief description]"

Top-level comments:

bash

gh api repos/{owner}/{repo}/issues/$PR/comments -X POST -f body="[response]"

For addressed items: "Fixed — [brief description]" For push-backs: clear reasoning why the suggestion was declined.

Do not proceed to the next step until every comment has a reply posted.

这是主要交付成果。 通过相应的端点回复所有分类处理后的评论：

Inline评论：

bash

gh api repos/{owner}/{repo}/pulls/$PR/comments/{id}/replies -X POST -f body="Fixed — [brief description]"

顶层评论：

bash

gh api repos/{owner}/{repo}/issues/$PR/comments -X POST -f body="[response]"

对于已处理的评论：“Fixed — [简要描述]” 对于反驳的评论：清晰说明拒绝该建议的理由。

在所有评论都发布回复之前，不要进入下一步。

6. Re-review Prompt (conditional)

6. 请求重新评审（条件触发）

After all replies posted, if any human reviewers (non-bot) had comments that were addressed (not pushed back):

Use

AskUserQuestion

to ask if the user wants to request re-review from those specific humans. List each human reviewer whose feedback was addressed.

For each selected reviewer:

bash

gh api repos/{owner}/{repo}/pulls/$PR/requested_reviewers -X POST --field "reviewers[]={login}"

Skip entirely if no human reviewers had comments addressed.

在所有回复发布后，如果有任何人类评审者（非机器人）的评论被处理（未被反驳）：

使用

AskUserQuestion

询问用户是否要向这些特定的人类评审者请求重新评审。列出所有反馈已被处理的人类评审者。

对于每个选中的评审者：

bash

gh api repos/{owner}/{repo}/pulls/$PR/requested_reviewers -X POST --field "reviewers[]={login}"

如果没有人类评审者的评论被处理，则完全跳过此步骤。

Completion Checklist (must all be true)

完成检查清单（必须全部满足）

Every reviewer comment has an inline reply posted via
```
gh api
```
Code fixes committed and pushed (if any)

If replies are not posted, the skill has NOT been executed.

所有评审者评论都已通过
```
gh api
```
发布inline回复
代码修复已提交并推送（如有）

如果未发布回复，则该技能未执行。

Plan Mode Behavior

计划模式行为

If triggered while in plan mode: do not act. Instead produce a triage table grouped by reviewer listing each comment, the decision (address/push-back), and proposed change or reasoning.

如果在计划模式下触发：不要执行操作。而是生成一个按评审者分组的分类处理表格，列出每条评论、决策（处理/反驳）以及提议的变更或理由。

Principles

原则

Replies are the output — code fixes support replies, not the other way around
Re-runnable means safe to run repeatedly — not "skip handled"
KISS — minimal fixes, no over-engineering
Push back when warranted — not all suggestions are improvements
Single commit — one commit for all fixes
Reviewer-grouped — triage organized by commenter for clarity

回复是输出——代码修复为回复提供支持，反之则不然
可重复运行意味着安全重复执行——不要“跳过已处理的评论”
KISS——最小化修复，避免过度设计
必要时反驳——并非所有建议都是改进
单次提交——所有修复合并为一次提交
按评审者分组——分类处理按评论者组织，以便清晰查看

Edge Cases

边缘情况

Condition	Handling
No open PR	stop with message
No review comments	stop with message
All from PR author	stop: "no reviewer comments to address"
All previously handled	still reply to all with follow-up status
All push-backs	skip commit/push, only reply
No human reviewers addressed	skip re-review prompt

条件	处理方式
无打开的PR	停止并提示消息
无评审评论	停止并提示消息
所有评论来自PR作者	停止：“没有需要处理的评审者评论”
所有评论已被处理	仍回复所有评论并说明后续状态
所有评论都被反驳	跳过提交/推送步骤，仅回复评论
无人类评审者的评论被处理	跳过请求重新评审的提示