pr-review-response

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PR Review Response

PR评审回复

Evaluate and respond to PR review comments critically rather than accepting them blindly.

对PR评审评论进行严谨评估并回复，而非盲目接受。

Usage

使用方法

Invoke with a PR number or let it auto-detect from the current branch:

/pr-review-response 42
/pr-review-response

Or trigger naturally: "respond to PR review comments", "handle the review feedback on my PR", "address the bot comments on PR #42".

通过指定PR编号调用，或让它从当前分支自动检测：

/pr-review-response 42
/pr-review-response

也可以自然触发："回复PR评审评论"、"处理我的PR上的评审反馈"、"处理PR #42上的机器人评论"。

Workflow

工作流程

1. Identify the PR

1. 识别PR

bash

undefined

bash

undefined

If PR number given as argument, use it. Otherwise detect from branch:

如果指定了PR编号参数，则使用该编号；否则从分支检测：

BRANCH=$(git branch --show-current) PR_NUMBER=$(gh pr list --head "$BRANCH" --json number --jq '.[0].number') REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')


If no open PR is found, tell the user and stop.

BRANCH=$(git branch --show-current) PR_NUMBER=$(gh pr list --head "$BRANCH" --json number --jq '.[0].number') REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')


如果未找到开放状态的PR，告知用户并终止流程。

2. Fetch all review comments

2. 获取所有评审评论

bash

gh api "repos/${REPO}/pulls/${PR_NUMBER}/comments" --paginate

Also fetch PR review bodies (top-level review summaries):

bash

gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" --paginate

Parse each comment to extract:

```
id
```
- comment ID for replying
```
path
```
- file path
```
line
```
/
```
original_line
```
- line number in diff
```
body
```
- the comment text
```
diff_hunk
```
- surrounding diff context
```
user.login
```
- who left it (bot vs human)
```
in_reply_to_id
```
- thread parent (skip if already replied to)

bash

gh api "repos/${REPO}/pulls/${PR_NUMBER}/comments" --paginate

同时获取PR评审正文（顶层评审摘要）：

bash

gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" --paginate

解析每条评论，提取以下信息：

```
id
```
- 用于回复的评论ID
```
path
```
- 文件路径
```
line
```
/
```
original_line
```
- 差异中的行号
```
body
```
- 评论文本
```
diff_hunk
```
- 周围的差异上下文
```
user.login
```
- 评论者（机器人或人类）
```
in_reply_to_id
```
- 线程父级（若已回复则跳过）

3. Read full context

3. 读取完整上下文

For each commented file, read the entire file — not just the diff hunk. Bots only see the diff; you see the whole project.

4. Evaluate each comment

4. 评估每条评论

For every comment, decide one of three outcomes:

针对每条评论，决定以下三种结果之一：

Accept

接受

The suggestion is correct and improves the code. Criteria:

Fixes a real bug or correctness issue
Aligns with project conventions (check AGENTS.md/existing patterns)
The proposed fix is actually better than what's there

建议正确且能改进代码。判断标准：

修复了真实的bug或正确性问题
符合项目约定（参考AGENTS.md或现有模式）
提议的修复确实比当前实现更好

Decline

拒绝

The suggestion is wrong, irrelevant, or conflicts with project intent. Common reasons:

Bot lacks project context (e.g., suggesting strict TS options when intentionally relaxed)
Suggestion conflicts with AGENTS.md or established patterns
It's a stylistic preference, not a correctness issue
The bot misunderstands the architecture or tooling
The "fix" would break something the bot can't see

建议错误、无关或与项目目标冲突。常见原因：

机器人缺乏项目上下文（例如，在有意放宽的情况下建议启用严格的TS选项）
建议与AGENTS.md或既定模式冲突
仅为风格偏好，而非正确性问题
机器人误解了架构或工具
"修复"会破坏机器人无法看到的内容

Discuss

讨论

You're unsure, or the comment raises a legitimate question that needs the user's input.

你不确定，或评论提出了需要用户输入的合理问题。

5. Present assessment for approval

5. 展示评估结果以获取批准

Before making ANY changes, show the user a summary table:

PR #42 — 3 review comments from gemini-code-assist[bot]

| # | File             | Comment (summary)              | Verdict | Reason                                    |
|---|------------------|--------------------------------|---------|-------------------------------------------|
| 1 | package.json     | module field wrong path        | ACCEPT  | Genuine bug — entry point is src/index.ts  |
| 2 | tsconfig.json    | Enable noUnusedLocals/Params   | DECLINE | Intentionally relaxed for development      |
| 3 | .gitignore       | Commit bun.lock                | ACCEPT  | Correct — lockfiles should be committed    |

Planned actions:
- Fix package.json module field
- Fix .gitignore to stop ignoring bun.lock
- Commit and push changes
- Post PR comment with responses to all 3 comments

Proceed? (changes will be committed and pushed)

Wait for user approval. Do not proceed without it.

在进行任何更改之前，向用户展示汇总表格：

PR #42 — 来自gemini-code-assist[bot]的3条评审评论

| # | 文件             | 评论（摘要）              | 结论 | 理由                                    |
|---|------------------|--------------------------------|---------|-------------------------------------------|
| 1 | package.json     | module字段路径错误        | 接受  | 真实bug —— 入口点应为src/index.ts  |
| 2 | tsconfig.json    | 启用noUnusedLocals/Params   | 拒绝 | 为开发需求有意放宽配置      |
| 3 | .gitignore       | 提交bun.lock                | 接受  | 正确 —— 锁文件应被提交    |

计划操作：
- 修复package.json的module字段
- 修改.gitignore不再忽略bun.lock
- 提交并推送更改
- 发布PR评论回复所有3条评论

是否继续？（更改将被提交并推送）

等待用户批准。 未经批准不得继续。

6. Apply changes

6. 应用更改

On approval:

Apply accepted fixes — edit the files as needed

Stage and commit with a clear message:

bash

git add -A && git commit -m "address PR review: accept N, decline M comments"

Push to the PR branch:
bash
```
git push
```

获得批准后：

应用已接受的修复 —— 根据需要编辑文件

暂存并提交，使用清晰的提交信息：

bash

git add -A && git commit -m "处理PR评审：接受N条，拒绝M条评论"

推送到PR分支：
bash
```
git push
```

7. Post PR responses

7. 发布PR回复

Compose a single PR comment that addresses every review comment. Format:

bash

BODY=$(cat <<'COMMENT'

撰写单个PR评论，回复所有评审评论。格式如下：

bash

BODY=$(cat <<'COMMENT'

Review Response

评审回复

package.json — module field path ✅

package.json — module字段路径 ✅

Accepted. Fixed

module

from

index.ts

src/index.ts

. Good catch — the entry point was incorrect.

已接受。将

module

从

index.ts

修改为

src/index.ts

。发现得好——入口点确实错误。

tsconfig.json — strict unused checks ❌

tsconfig.json — 严格未使用项检查 ❌

Declined.

noUnusedLocals

and

noUnusedParameters

are intentionally disabled. During active development, unused variables are common as code evolves. This is a deliberate choice documented in project conventions, not an oversight.

已拒绝。

noUnusedLocals

和

noUnusedParameters

被有意禁用。在活跃开发期间，未使用变量是代码演进中的常见情况。这是项目约定中明确记录的 deliberate选择，并非疏忽。

.gitignore — commit bun.lock ✅

.gitignore — 提交bun.lock ✅

Accepted. Removed

bun.lock

from

.gitignore

. Lockfiles should be committed for reproducible builds.

2 accepted, 1 declined COMMENT )

gh pr comment "$PR_NUMBER" --body "$BODY"


Use reply threads where possible — reply to individual comments:

```bash

已接受。从

.gitignore

中移除

bun.lock

。锁文件应被提交以确保构建可复现。

2条接受，1条拒绝 COMMENT )

gh pr comment "$PR_NUMBER" --body "$BODY"


尽可能使用回复线程——回复单个评论：

```bash

Reply to a specific review comment

回复特定评审评论

gh api "repos/${REPO}/pulls/${PR_NUMBER}/comments/${COMMENT_ID}/replies"
-f body="Accepted. Fixed in latest push — changed module field to `src/index.ts`."

undefined

gh api "repos/${REPO}/pulls/${PR_NUMBER}/comments/${COMMENT_ID}/replies"
-f body="已接受。在最新推送中修复——将module字段改为`src/index.ts`。"

undefined

Key Principles

核心原则

Never blindly accept — bots lack project context. A suggestion that looks reasonable in isolation may conflict with project intent.
Read the full file — don't evaluate based on the diff hunk alone. The surrounding code matters.
Check conventions first — AGENTS.md, CLAUDE.md, and existing patterns take precedence over generic best practices.
Explain declines — a declined suggestion deserves a clear reason. This helps the reviewer (human or bot) and documents the decision.
Batch everything — one commit for all fixes, one comment for all responses. Don't create noise with per-comment commits.
User approval gate — never push code or post comments without explicit user approval.

绝不盲目接受 —— 机器人缺乏项目上下文。孤立来看合理的建议可能与项目目标冲突。
读取完整文件 —— 不要仅基于差异片段进行评估。周边代码至关重要。
先检查约定 —— AGENTS.md、CLAUDE.md和现有模式优先于通用最佳实践。
解释拒绝理由 —— 被拒绝的建议需要清晰的理由。这有助于评审者（人类或机器人）并记录决策过程。
批量处理 —— 所有修复一次提交，所有回复一次发布。不要因逐条评论提交而产生噪音。
用户批准闸门 —— 未经用户明确批准，不得推送代码或发布评论。

Watch Mode

监听模式

After pushing a PR, you can use the watch script to automatically respond once a review comes in:

bash

./skills/pr-review-response/scripts/watch-pr.sh 42

推送PR后，你可以使用监听脚本在评审到来时自动回复：

bash

./skills/pr-review-response/scripts/watch-pr.sh 42

or auto-detect:

或自动检测：

./skills/pr-review-response/scripts/watch-pr.sh


This polls for new comments, waits for the review to stabilize (60s cooldown), then invokes this skill. See `scripts/watch-pr.sh` for details.

./skills/pr-review-response/scripts/watch-pr.sh


该脚本会轮询新评论，等待评审稳定（60秒冷却期），然后调用此技能。详情请查看`scripts/watch-pr.sh`。