address-review-bots

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Address Review Bots

处理评审机器人反馈

Use When

使用场景

Use this after creating or pushing to a PR when the user asks to wait for Claude, Devin, or similar review-bot feedback, address bot comments, or keep iterating until bot reviews are clean.

This complements local validation. It does not replace the target repository's normal pre-push or pre-merge checks.

当用户要求等待Claude、Devin或同类评审机器人的反馈、处理机器人评论，或持续迭代直至机器人评审无问题时，在创建PR或向PR推送代码后使用本流程。

本流程是本地验证的补充，不会替代目标仓库常规的推送前或合并前检查。

Core Loop

核心循环

Confirm the current branch has a PR:

bash

gh pr view --json number,url,headRefOid,headRefName

If no PR exists, stop and tell the user this skill needs an existing PR.

Record the review window immediately before or after pushing:

bash

REVIEW_BOT_SINCE="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

Wait for review-bot checks and snapshot fresh comments:

bash

mkdir -p .context
node scripts/review-bot-snapshot.mjs \
  --wait \
  --since "$REVIEW_BOT_SINCE" \
  --json > .context/review-bot-snapshot.json

Run the bundled

scripts/review-bot-snapshot.mjs

from this skill directory. If the agent cannot execute relative to the skill directory, resolve the directory containing this

SKILL.md

first and pass the script path explicitly.

If you are starting from already-posted comments and did not capture a push timestamp, omit

--since

Classify each fresh bot comment:

```
valid_actionable
```
: the bot found a real issue that should be fixed before merge.
```
already_fixed_or_stale
```
: the finding is no longer present on the current head, or the comment points at an old head.
```
false_positive
```
: the bot's claim is wrong; gather concrete code evidence.
```
needs_user_decision
```
: the change is product/UX/architecture policy rather than an obvious correctness fix.
```
valid_low_risk_cleanup
```
: the bot found a real, bounded improvement that is not merge-blocking but is cheap, objective, and aligned with repo conventions.
```
non_actionable
```
: summaries, praise, progress updates, or "no issues" comments.

Do not treat "non-blocking", "nit", "none worth an inline change", or similar wording as automatically

non_actionable

. If the comment includes concrete code references, a plausible failure mode, a consistency issue, or a maintainability concern, inspect the referenced code and classify it on its merits.

Fix

valid_actionable

comments automatically. Also fix

valid_low_risk_cleanup

comments automatically when the change is tightly scoped and does not alter product, UX, architecture policy, or public behavior in a way that needs user judgment. Leave product, UX, and architecture tradeoffs for the user unless the decision is obvious from repo conventions.

Before moving on, make a compact classification table in your notes or final answer for every substantive bot observation:

text

permalink | isOutdated or n/a | claim | classification | evidence | reply/resolution action or why left open

Apply scoped fixes and nearby tests for valid actionable comments.
Self-review the delta, then verify with the repository's final validation command.

If the user has set

REVIEW_BOT_VALIDATION_COMMAND

, use it exactly. Otherwise resolve validation in this order:

Use a command required by repository instructions or CI.
Inspect the applicable package manifest, starting at the repository root and following workspace configuration for changed packages. Detect its package manager from the root manifest's
```
packageManager
```
field, then its lockfile (
```
pnpm-lock.yaml
```
,
```
yarn.lock
```
,
```
package-lock.json
```
or
```
npm-shrinkwrap.json
```
,
```
bun.lock
```
or
```
bun.lockb
```
). Do not switch package managers merely because another executable is available.
If a
```
precommit
```
package script exists, run it with the detected package manager, for example
```
pnpm run precommit
```
,
```
yarn run precommit
```
,
```
npm run precommit
```
, or
```
bun run precommit
```
.
If
```
precommit
```
is absent, run each available
```
lint
```
and
```
test
```
package script with that same package manager. Do not invoke a missing script or treat its absence as a validation failure.
If neither script exists, use the repository's documented non-JavaScript or CI-equivalent checks. If none can be found, report that validation coverage is unavailable instead of inventing a command.

Use narrower checks while iterating, but do not commit or push review-bot fixes without running every resolved final validation command after the last code change.

Commit and push if fixes were made:

bash

git add <fixed-files>
git commit -m "fix: address review bot feedback"
git push

Repeat from step 2 until there are no fresh valid actionable or valid low-risk cleanup bot comments, remaining comments are stale/non-actionable/false positives/user decisions, or further changes would be speculative.
On each stable current head, scan unresolved in-scope review threads and apply the review-thread cleanup policy below before declaring the bot loop clean.

Default to at most 8 fix-push loops unless the user explicitly asks to keep going.

确认当前分支已关联PR：

bash

gh pr view --json number,url,headRefOid,headRefName

如果不存在PR，请停止操作并告知用户本功能需要已存在的PR。

记录推送前后的评审时间窗口：

bash

REVIEW_BOT_SINCE="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

等待评审机器人检查并获取最新评论快照：

bash

mkdir -p .context
node scripts/review-bot-snapshot.mjs \
  --wait \
  --since "$REVIEW_BOT_SINCE" \
  --json > .context/review-bot-snapshot.json

从本技能目录运行附带的

scripts/review-bot-snapshot.mjs

脚本。如果Agent无法相对于技能目录执行，请先找到包含本

SKILL.md

的目录，然后显式传入脚本路径。

如果从已发布的评论开始处理且未捕获推送时间戳，请省略

--since

参数。

对每条新的机器人评论进行分类：

```
valid_actionable
```
：机器人发现了需要在合并前修复的真实问题。
```
already_fixed_or_stale
```
：该问题在当前分支头部已不存在，或评论指向旧的分支头部。
```
false_positive
```
：机器人的判断错误；需收集具体代码证据。
```
needs_user_decision
```
：该变更涉及产品/UX/架构策略，而非明显的正确性修复。
```
valid_low_risk_cleanup
```
：机器人发现了真实、有限的改进点，不影响合并，但修复成本低、目标明确且符合仓库规范。
```
non_actionable
```
：总结性评论、表扬、进度更新或"无问题"类评论。

不要将"非阻塞"、"细枝末节"、"不值得修改"等表述自动归为

non_actionable

。如果评论包含具体代码引用、合理的故障模式、一致性问题或可维护性担忧，请检查引用的代码并根据实际情况分类。

自动修复

valid_actionable

类评论。当变更范围明确且不会改变产品、UX、架构策略或需要用户判断的公共行为时，也自动修复

valid_low_risk_cleanup

类评论。产品、UX和架构权衡问题留给用户处理，除非根据仓库规范可明显做出决策。

继续下一步前，请在笔记或最终回复中为每个实质性的机器人观察结果制作简洁的分类表：

text

permalink | isOutdated or n/a | claim | classification | evidence | reply/resolution action or why left open

针对有效可操作的评论应用范围明确的修复及相关测试。
自行审查变更差异，然后使用仓库的最终验证命令进行验证。

如果用户已设置

REVIEW_BOT_VALIDATION_COMMAND

，请严格使用该命令。否则按以下顺序确定验证方式：

使用仓库说明或CI要求的命令。
检查适用的包清单，从仓库根目录开始，遵循变更包的工作区配置。从根清单的
```
packageManager
```
字段检测包管理器，然后从锁文件（
```
pnpm-lock.yaml
```
、
```
yarn.lock
```
、
```
package-lock.json
```
或
```
npm-shrinkwrap.json
```
、
```
bun.lock
```
或
```
bun.lockb
```
）确认。不要仅因其他可执行文件可用就切换包管理器。
如果存在
```
precommit
```
包脚本，请使用检测到的包管理器运行它，例如
```
pnpm run precommit
```
、
```
yarn run precommit
```
、
```
npm run precommit
```
或
```
bun run precommit
```
。
如果
```
precommit
```
不存在，请使用同一包管理器运行所有可用的
```
lint
```
和
```
test
```
包脚本。不要调用不存在的脚本，也不要将脚本缺失视为验证失败。
如果上述脚本均不存在，请使用仓库文档中记录的非JavaScript或等效CI检查。如果找不到任何检查，请报告验证覆盖不可用，不要自行创建命令。

迭代过程中可使用更窄范围的检查，但在最后一次代码变更后，必须运行所有确定的最终验证命令，才能提交或推送评审机器人反馈的修复。

如果进行了修复，请提交并推送：

bash

git add <fixed-files>
git commit -m "fix: address review bot feedback"
git push

重复步骤2，直到没有新的有效可操作或低风险清理类机器人评论，剩余评论为过期/非可操作/误判/需用户决策，或进一步变更具有投机性。
在每个稳定的当前分支头部，扫描未解决的相关评审线程，并在宣布机器人循环完成前应用以下评审线程清理策略。

默认最多运行8次修复-推送循环，除非用户明确要求继续。

Review Judgment

评审判断

Treat review bots as input, not authority. A valid comment needs concrete evidence in code, tests, generated artifacts, or repo conventions. Before fixing or rejecting a substantive observation, inspect the referenced file and surrounding code.

Review bots may update an existing top-level summary comment instead of creating a fresh review comment. If a fresh bot status comment says a review summary was posted or updated, inspect that summary even when the snapshot lists it under stale comments because its original

createdAt

predates the current review window. In that case, use

updatedAt

and the status comment content to decide whether the summary needs classification.

For stale inline comments, compare the snapshot head SHA, comment commit ID, and current code.

For comments outside a resolvable review thread, leave a short PR reply when it helps future reviewers understand a rejection. Follow the stricter reply-before-resolve rules below for review threads.

将评审机器人视为输入而非权威。有效评论需要代码、测试、生成工件或仓库规范中的具体证据。在修复或拒绝实质性观察结果前，请检查引用的文件及周边代码。

评审机器人可能更新现有的顶级总结评论，而非创建新的评审评论。如果新的机器人状态评论表明评审摘要已发布或更新，即使快照因原始

createdAt

早于当前评审窗口而将其列为过期评论，也需检查该摘要。在这种情况下，使用

updatedAt

和状态评论内容来决定是否需要对摘要进行分类。

对于过期的内联评论，比较快照头部SHA、评论提交ID和当前代码。

对于无法解析为评审线程的评论，若有助于未来评审者理解拒绝原因，请在PR中留下简短回复。对于评审线程，请遵循以下更严格的回复后再解决的规则。

Review-Thread Cleanup

评审线程清理

Query unresolved review threads with GitHub tooling that exposes the thread's

isResolved

and

isOutdated

fields. The snapshot helper's fresh/stale classification is based on comment SHA and time and is not a substitute for GitHub's

isOutdated

value. Confirm the PR head is still the expected current SHA before mutating any thread.

Inspect the current code and classify every unresolved in-scope thread before resolving it:

For
```
isOutdated: true
```
, verify that the issue is fixed or no longer relevant on the current head. Resolve the thread only after that verification. No PR reply is required unless extra context would help. If the issue is still relevant, ambiguous, or needs a user decision, leave the thread unresolved.
For
```
isOutdated: false
```
, never resolve silently. If the issue is fixed or stale, first reply in that same review thread with a concise explanation and concrete evidence from the current head, such as the function or behavior that addresses the concern and the relevant test. Resolve the thread only after GitHub confirms the reply was posted. If the reply fails, leave the thread unresolved and report the failure.
Leave the thread unresolved when the finding is still valid, the correct fix is ambiguous, the evidence is weak, or resolution requires product, UX, public API, or architecture judgment. Report its permalink and why it remains open.

Do not treat a

false_positive

classification by itself as permission to resolve a non-outdated thread. Resolve only when concrete current-head evidence establishes that the concern is stale or no longer applies, and post that evidence in-thread first.

Example reply:

Resolved in the current head:
addOrReplaceNewerTarget
now delegates to
mergeReopenTargetFields
, which preserves
bundleId
when a focused-window target replaces an event-derived target. Covered by
tools.test.ts
.

使用GitHub工具查询未解决的评审线程，这些工具会暴露线程的

isResolved

和

isOutdated

字段。快照助手基于评论SHA和时间进行的新/旧分类不能替代GitHub的

isOutdated

值。在修改任何线程前，请确认PR头部仍是预期的当前SHA。

在解决每个未解决的相关线程前，检查当前代码并进行分类：

若
```
isOutdated: true
```
，验证该问题在当前分支头部已修复或不再相关。仅在验证后解决线程。除非额外上下文有帮助，否则无需在PR中回复。如果问题仍然相关、模糊或需要用户决策，请保持线程未解决。
若
```
isOutdated: false
```
，切勿静默解决。如果问题已修复或过期，请先在同一评审线程中回复简洁的解释和当前分支头部的具体证据，例如解决该问题的函数或行为及相关测试。仅在GitHub确认回复已发布后解决线程。如果回复失败，请保持线程未解决并报告失败情况。
当发现结果仍然有效、正确修复方案不明确、证据不足，或解决需要产品、UX、公共API或架构判断时，保持线程未解决。报告其permalink及未解决的原因。

不要仅将

false_positive

分类作为解决非过期线程的许可。仅当当前分支头部的具体证据表明该问题已过期或不再适用时，才可解决，并先在线程中发布该证据。

回复示例：

已在当前分支头部解决：
addOrReplaceNewerTarget
现在委托给
mergeReopenTargetFields
，该函数在聚焦窗口目标替换事件派生目标时保留
bundleId
。相关测试已覆盖在
tools.test.ts
中。

Self-Review Before Push

推送前的自我审查

After applying a review-bot fix and before committing or pushing, step back and review the changes as if another engineer made them. Do not assume the patch is correct because you wrote it.

Review the full

git diff

, every edited file, nearby call sites or tests, whether the fix addresses the underlying issue rather than only the bot's example, and whether it introduces new edge cases or test gaps.

The goal is not to consume all 8 loops. The goal is to push fixes that review bots and CI do not need to correct again.

If a fresh valid actionable bot finding appears after a push, deepen the next self-review: focused diff review first, then related files/tests, then module-level assumptions and failure modes if misses continue. Repeated misses mean the local review is missing context; slow down and inspect the broader subsystem before pushing again.

在应用评审机器人的修复后、提交或推送前，退一步以其他工程师的视角审查变更。不要因是自己编写的补丁就假设其正确。

审查完整的

git diff

、每个编辑的文件、附近的调用站点或测试、修复是否解决了根本问题而非仅机器人给出的示例，以及是否引入了新的边缘情况或测试缺口。

目标不是用完所有8次循环，而是推送无需评审机器人和CI再次修正的修复。

如果推送后出现新的有效可操作机器人发现，请深化下一次自我审查：先聚焦差异审查，再检查相关文件/测试，如果持续遗漏则检查模块级假设和故障模式。反复遗漏表明本地审查缺少上下文，请放慢速度，在再次推送前检查更广泛的子系统。

Waiting Rules

等待规则

Be selective about waiting for GitHub. This skill is for PR review automation after a push; for normal implementation work, the repository's local validation command is usually the faster gate. The helper waits for review-like checks matching Claude, Devin, or review patterns and should not block indefinitely on unrelated CI.

The helper's default wait limit is 35 minutes so it exceeds the Claude review workflow's 30-minute job limit. Keep those values coordinated when either limit changes.

选择性地等待GitHub处理。本技能用于推送后的PR评审自动化；对于常规开发工作，仓库的本地验证命令通常是更快的检查方式。助手会等待匹配Claude、Devin或评审模式的类评审检查，不会无限期阻塞在无关的CI上。

助手的默认等待限制为35分钟，超过Claude评审工作流的30分钟作业限制。当任一限制变更时，请保持这些值协调。

Helper Script

助手脚本

Use

scripts/review-bot-snapshot.mjs

rather than rewriting GitHub API commands. Default bots are Claude and Devin; override with

--bot-logins

REVIEW_BOT_LOGINS

if needed.

Common options:

bash

node scripts/review-bot-snapshot.mjs --help
node scripts/review-bot-snapshot.mjs --wait
node scripts/review-bot-snapshot.mjs --wait --json
node scripts/review-bot-snapshot.mjs --pr 123 --bot-logins "claude[bot],devin-ai-integration[bot]"

使用

scripts/review-bot-snapshot.mjs

而非重写GitHub API命令。默认机器人为Claude和Devin；如有需要，可使用

--bot-logins

或

REVIEW_BOT_LOGINS

覆盖。

常用选项：

bash

node scripts/review-bot-snapshot.mjs --help
node scripts/review-bot-snapshot.mjs --wait
node scripts/review-bot-snapshot.mjs --wait --json
node scripts/review-bot-snapshot.mjs --pr 123 --bot-logins "claude[bot],devin-ai-integration[bot]"

Final Response

最终回复

Report:

how many review-bot loops ran,
which bot comments were fixed,
which comments were rejected or left for user decision, with permalinks,
the classification and rationale for every substantive bot observation,
the commit SHA(s) pushed,
the final validation command and result,
the number of review threads resolved,
the number resolved silently because GitHub marked them
```
isOutdated: true
```
,
the number resolved after posting an explanatory in-thread reply,
every unresolved thread left open, with its permalink and rationale.

If no valid comments remain, say that directly only after classifying each substantive observation. If review checks timed out, say what was checked and what is still unknown.

报告以下内容：

运行了多少次评审机器人循环，
修复了哪些机器人评论，
拒绝或留给用户决策的评论（包含permalink），
每个实质性机器人观察结果的分类及理由，
推送的提交SHA，
最终验证命令及结果，
解决的评审线程数量，
因GitHub标记为
```
isOutdated: true
```
而静默解决的线程数量，
发布解释性线程回复后解决的线程数量，
所有未解决的线程（包含permalink及未解决理由）。

如果没有剩余有效评论，仅在对每个实质性观察结果进行分类后直接说明。如果评审检查超时，请说明已检查的内容及仍未知的信息。