answer-pr-reviews

回复 PR 审查意见

将 Superpowers 的 receiving-code-review 用于拉取请求。该技能会决定如何处理每条审查意见——采纳合理的意见并修复，对不合理的意见提出异议——但它不会接收拉取请求，也不会获取任何内容。本技能补上其余部分：要处理哪些拉取请求、每个请求中尚未回复的反馈、检出其分支，以及用于完成整个流程的推送和回复。

它会处理用户指定的拉取请求，或用户拥有且存在未回复反馈的所有未关闭拉取请求。每条评论都会得到回复；不会解决任何讨论串。

本技能只指定操作，不指定工具。请使用平台上对应的工具。

要求

• Superpowers（receiving-code-review、verification-before-completion）。如果缺少其中任何一项，请指出缺少哪项并停止。
• 一个 GitHub 仓库和 gh，且 gh auth status 通过；否则说明原因并停止。

阶段 1 — 选择拉取请求

1. 仓库：用户指定的仓库；否则使用当前检出对应的 GitHub 仓库（gh repo view --json nameWithOwner）。说明使用的是哪个仓库。
2. 拉取请求：用户指定的请求；如果用户要求“全部”或“我的 PR”，则运行 gh pr list --repo <owner/repo> --state open --author "@me" --limit 1000 --json number,title,url，并在阶段 2 中筛选出存在未回复反馈的请求。只有用户明确指定时，才处理其他作者的拉取请求。
3. 列出拉取请求及每个请求中未回复事项的数量，并说明修复将推送到各自的分支，且会发布回复。用户确认后即可开始——除非任务派发时已获得确认，例如 implement-issues；在这种情况下，列出请求后继续。

阶段 2 — 收集未回复的反馈

1. 获取拉取请求、其审查讨论串、审查和对话评论：

   gh api graphql -f owner=<owner> -f repo=<repo> -F number=<number> -f query='
   query($owner: String!, $repo: String!, $number: Int!) {
     repository(owner: $owner, name: $repo) {
       pullRequest(number: $number) {
         title body url headRefName
         reviewThreads(first: 100) {
           nodes {
             isResolved isOutdated path line
             comments(first: 100) { nodes { databaseId author { login } body } }
           }
         }
         reviews(first: 100) { nodes { author { login } body url } }
         comments(last: 100) { nodes { body } }
       }
     }
   }'
   

2. 需要回复的事项：

   • 所有尚未解决且最后一条评论结尾不含 `` 的讨论串；也包括已过时的讨论串，因为相关问题可能仍然存在于移动后的代码中；
   • 审查正文中提出的所有问题，除非有包含标记的对话评论链接到该审查的 url。严重性统计和“没有发现问题”之类的摘要不算问题。

   标记用于区分已回复和未回复的事项，而不是作者；同一个 gh 账号可能既发布审查，也发布回复，例如 implement-issues。

3. 如果存在 docs/agents/issue-tracker.md，且标题或正文包含其 Linking 部分列出的引用——在 GitHub 上即 Closes #<number> 或 Relates to #<number>——请使用 Reading 方法读取对应的意图 issue，并保留其中的 Constraints。

从这里开始，每次只处理一个拉取请求。没有待回复事项的请求即视为完成：说明这一点。

阶段 3 — 检出分支

1. 如果任务派发时附带了 worktree：在其中操作。

2. 否则，如果现有检出中有 headRefName（git worktree list）且没有未提交的更改，则使用该检出。如果存在未提交的更改，则停止处理此拉取请求并说明原因——绝不暂存、丢弃或提交他人的更改。

3. 如果没有检出，则创建一个。gh pr checkout 也会设置好分支的推送目标，包括 fork 的目标。

   git check-ignore -q .worktrees || echo ".worktrees/" >> "$(git rev-parse --git-common-dir)/info/exclude"
   git worktree add --detach ".worktrees/pr-<number>"
   cd ".worktrees/pr-<number>" && gh pr checkout <number> --repo <owner/repo>
   

阶段 4 — 使用 receiving-code-review 回复

在检出目录中调用 receiving-code-review。反馈为阶段 2 收集的事项，每项都包含其路径、行号和完整讨论串；意图 issue 中的 Constraints 代表用户先前作出的决定。

• 由用户运行：将问题交由用户回答。
• 任务派发时已获得确认：无法询问任何人。遇到要求提问或暂停讨论的情况时，请自行决定，并在该事项的回复中说明理由。

每项修复都要单独提交，这样回复中才能提及对应的提交。逐项记录处理结果——已修复（附提交）、已提出异议（附理由）或无法修复（说明失败原因）；回复应根据这些记录撰写。

阶段 5 — 推送，然后回复

1. 在 verification-before-completion 下，根据 AGENTS.md 或项目清单运行项目的测试、lint 和类型检查命令。如果失败，撤销导致失败的修复（这些项目标记为无法修复），然后再次运行。如果仍然失败：不要推送，不要回复任何内容，并报告情况。
2. 有新提交时，运行 git push — 切勿强制推送。推送被拒绝：停止处理此拉取请求，不要回复任何内容，并报告情况。
3. 推送成功后，回复每个项目，并在每条回复末尾加上 ``：

   • 行内讨论串 — 在讨论串内回复第一条评论：

     gh api --method POST repos/<owner>/<repo>/pulls/<number>/comments/<first comment databaseId>/replies -F [email protected]
     

     Fixed in <sha> — <what changed>.，或说明反对意见的理由，或说明尝试了什么以及无法修复的原因。

   • 审查正文中的问题 — 发送一条讨论评论，链接到审查的 url，并按顺序回答每个问题： gh pr comment <number> --repo <owner/repo> --body-file reply.md。

阶段 6 — 报告

用一张表列出：拉取请求、已回复项目、已修复 / 已提出异议 / 无法修复、检查结果，以及推送的头提交 — 或未推送的原因。然后列出所有未处理的拉取请求及原因。

不要做的事

• 不要自行决定如何处理某个项目 — 由 receiving-code-review 决定；此技能负责获取、推送和回复。
• 不要在提交推送前回复“已修复”。
• 检查失败时不要推送，也切勿强制推送。
• 不要解决讨论串、驳回审查、批准、合并或将拉取请求标记为就绪 — 是否接受工作由用户决定。
• 不要用讨论评论回复行内评论。
• 除非用户明确指定，否则不要回复其他作者的拉取请求。
• 不要为了检出代码而暂存、丢弃或提交他人尚未提交的更改。
• 不要回复已经包含此技能回复的项目。