respond

respond

阅读 PR 中的审查评论，为每条评论打 0–100 分，并根据得分采取行动：立即修复显而易见的问题，对不合理的意见提出异议，在修复工作已开始的同时询问处于边界的意见。此技能发布的每条回复都带有 agent on behalf of; 署名行。

第 0 阶段：检查 PR 状态

在对评论进行分类之前，先使用 gh CLI 检查 PR 的构建和合并状态：

gh pr checks <pr-number>            # check run conclusions
gh pr view <pr-number> --json mergeable,mergeStateStatus

构建失败。 如果任何检查的 state: FAILURE，获取失败作业日志（gh run view <run-id> --log-failed），并在处理审查评论之前修复根本原因。优先修复构建问题——如果构建已损坏，审查评论可能就不再适用。

合并冲突。 如果 mergeable 为 CONFLICTING 或 mergeStateStatus 为 DIRTY，先变基到 origin/<base>，并使用 lease 强制推送，然后再处理评论。过时的冲突会阻碍后续所有工作。

在分类表顶部注明构建/合并状态：

## PR #N status
- Build: passing | failing (N jobs)
- Merge: clean | conflicts (rebase needed)

如果两者均正常，则进入第 1 阶段。如果需要修复，注明已完成的工作。

第 1 阶段：获取讨论线程和审查正文

根据当前 Git 远程仓库确定 <owner>/<repo>，然后获取行内审查线程和 PR 级别的审查正文：

# Inline threads — comments anchored to specific diff lines
gh api repos/<owner>/<repo>/pulls/<pr>/comments

# PR-level review bodies — summaries submitted with a review
gh api repos/<owner>/<repo>/pulls/<pr>/reviews

# PR metadata + diff for context
gh pr view <pr> --json number,title,baseRefName,headRefName
gh pr diff <pr>

行内线程。 仅筛选未解决的线程。除非用户要求包含过时线程，否则跳过过时线程。按线程对评论分组——第一条评论是建议，其余评论是讨论内容。

审查正文。 筛选 body 非空的审查。空正文只是行内评论的容器，可以忽略。

去重。 同时包含正文和行内评论的审查会出现在两次获取结果中。将行内评论作为线程评分（它们包含文件上下文）。仅对审查正文中尚未被其行内评论涵盖的建议评分——通过 pull_request_review_id 将行内评论关联到其父审查。

第 2 阶段：为每条建议评分

对于每个未解决的线程或审查正文条目，阅读建议、后续讨论和相关差异，然后分配 0–100 的置信度分数，表示你对该建议正确且有价值的确信程度。

尽可能将审查正文解析为单独的条目：项目符号列表、编号列表和表格行往往包含多个不同的建议，每条都应有自己的分数和分类表行。连贯的评论（如“LGTM”或一般性观察）则作为一个条目处理。

CHANGES_REQUESTED 的权重高于 COMMENTED——审查者指出了阻塞问题。评分时应考虑这一点；它提高的是你对建议重要性的信心，而不是对建议正确性的信心。

完整的 4 步校准标准（建议类型、证据依据、上下文修正因素、边界情况复核）见 references/scoring.md。阅读一次，并根据该标准为每个条目评分。

第 3 阶段：分类表 + 立即执行

展示完整的分类表，让用户一目了然：

## PR #N review triage

| # | Score | Type          | Reviewer | Location      | Summary                       | Action    |
|---|-------|---------------|----------|---------------|-------------------------------|-----------|
| 1 | 92    | BUG           | copilot  | auth.ts:42    | Missing null check on token   | FIX       |
| 2 | 78    | VALID_CONCERN | alice    | (review body) | Missing error handling in 3   | FIX       |
| 3 | 60    | STYLE         | copilot  | utils.ts:15   | Extract to shared helper      | ASK       |
| 4 | 35    | SCOPE_CREEP   | bob      | index.ts:3    | Add backward compat shim      | PUSH BACK |
| 5 | 20    | STYLE         | copilot  | (review body) | "consider adding tests"       | SKIP      |

### Legend
- FIX (>= 50): agree and implement — proceeding now
- ASK (30–49): needs your call — what do you want to do?
- PUSH BACK (< 30): draft reply below — edit or approve

每一行都应包含一行展开说明，以便用户无需重新打开 PR 即可决定如何处理 ASK 条目。展开格式见 references/triage-examples.md。

然后立即——在同一轮中：

1. 开始修复所有 FIX 条目（>= 50），同时让用户查看 ASK 和 PUSH BACK 条目。
2. 对得分 < 30 的条目发布 PUSH BACK 回复（用户可以在你处理前提出异议；不要等待）。
3. 就 ASK 条目（30–49）询问用户，并提供足够的上下文，方便用户快速决定。

分类表仅用于提供信息，不是处理高置信度条目的门槛。用户可以看到当前进展并随时叫停（“停下，不要修复 #2”），但默认做法是迅速处理显而易见的问题。

阶段 4：执行

此阶段发布的每条回复都会通过 scripts/post-reply.sh，该脚本会封装 gh api 调用并附加署名后缀（见下文的署名规则）。发布回复时，不要在此技能中直接调用 gh api——署名必须在同一个位置统一处理。

修复项（>= 50）。 阅读源代码，实施修复，然后回复：

# Inline thread reply
./scripts/post-reply.sh --thread \
  --pr <pr-number> \
  --comment-id <comment-id> \
  --body "Fixed — <brief description of what changed>."

# Review body reply (PR conversation comment)
./scripts/post-reply.sh --issue \
  --pr <pr-number> \
  --body "Re: @<reviewer>'s review — Fixed: <brief description>."

反驳项（< 30）。 发布回复，说明原因，而不只是说不：

./scripts/post-reply.sh --thread \
  --pr <pr-number> \
  --comment-id <comment-id> \
  --body "<pushback explanation>"

保持专业且具体的语气。在适当情况下，引用项目约定（AGENTS.md / CLAUDE.md / 你的运行框架说明文件、复杂度预算、早期开发阶段的立场）。

询问项（30–49）。 等待用户决定。用户决定后，将其作为修复项或反驳项执行。如果用户没有回应某个具体的询问项，则将其保留为未解决状态。

完成所有操作后。 如果代码有更改，交由 /plate 执行提交和推送。汇总说明：修改的文件、已回复的讨论串、仍待用户决定的讨论串。

署名规则

此技能在 GitHub 发布的每条回复——包括行内讨论串回复、评审正文回复、PR 对话评论——都必须以以下署名后缀结尾：

---
agent on behalf of; <github-handle>

措辞必须完全一致：agent on behalf of;（小写、分号，前面留一个空格再接用户名）。不要改写。将该行放在回复末尾，单独成行，并在前面加上水平分隔线（---）。这样做是为了让审阅者一眼看出回复是由 Agent 代表团队成员发布的。

署名由 scripts/post-reply.sh 强制添加。字面短语 agent on behalf of; 存放在该脚本中，作为单个 Bash 常量（ATTRIBUTION_PREFIX）——绝不要将其作为固定字符串散落在回复模板中。用户名由脚本在发布时按以下顺序解析：

1. 如果设置了 RESPOND_GH_HANDLE 环境变量，则使用其值。
2. gh api user --jq .login（已通过身份验证的 gh 用户）。
3. 最后回退到 git config user.name。

不要为了符合正文长度限制而删除署名。GitHub REST 对 issue 评论和评审讨论串回复的限制为 65,536 个字符；署名后缀约 40 个字符，永远不会接近上限。如果回复确实需要那么长，应在删除署名前拆分内容。

设立此规则是为了避免后续审计时意外删除该后缀。在先更新本节之前，不要修改 post-reply.sh 来省略或缩短前缀。

规则

• 执行前先展示分流表——但 >= 50 的项无需等待批准。
• 每个讨论串只回复一次——不要将回复拆分成多条评论。
• 匹配审阅者的语气——对人保持专业，对机器人保持简洁。
• 反驳时引用具体依据——在适当情况下，引用项目的 Agent 说明文件（AGENTS.md / CLAUDE.md / GEMINI.md）、复杂度预算或早期开发阶段的立场。
• 不要争论风格问题——如果建议纯属风格问题且评分 < 30，则跳过（在表中标记为 SKIP），而不是发布反驳；评分为 30–49 的风格问题仍列为询问项，由用户决定。
• 不要推迟到后续处理——不要回复“会在后续 PR 中处理”或“好主意，以后单独处理”。评分 >= 50 时现在就修复；评分 < 30 时予以反驳。唯一可接受的推迟，是用户明确选择跳过的询问项。
• 批量提交——将修复合并为一次提交，而不是每个讨论串单独提交。
• 用户可以覆盖任何默认行为——“不要修复 #2”就停止处理该项，“实际上修复 #4”就执行。评分是默认依据，不是硬性要求。

此技能绝不会做什么

• 生成新的评审——请改用 /copilot-review。
• 超出评审者要求的具体修复范围重构代码。
• 除非评审者明确要求，否则不添加测试。
• 除了当前待分类的 PR 外，不创建新议题或 PR。
• 更改评审评论中未提及的文件。
• 解决它未回复的讨论串——让 GitHub 自动解决。
• 发布回复时不附带署名后缀——参见 署名规则。

注意事项

• gh api 在评论数达到 50 条以上的 PR 上会触发速率限制——尽可能批量读取，并优先使用单次分页调用，而不是多次请求。
• 解析评审正文时，可能会将内容连贯的评论拆分成多个片段——在分别为片段评分前，先检查是否存在相关讨论串。
• is_resolved 在不同 GitHub Apps 中并不总是可靠——如有疑问，请检查最新评论以确认讨论串状态。
• CHANGES_REQUESTED 状态的机器人评审者会夸大感知到的紧急程度——references/scoring.md 针对此情况应用 -10 的修正值。
• 去重行内评论和评审正文摘要颇为棘手——采取行动前，请检查 pull_request_review_id 是否重叠。