respond-to-pr-comments-in-blocklist

回复拉黑列表中的 PR 评论

使用此技能回复当前分支上的 PR 评论。如果对话中已经显示评论（通常来自内置的 /pr-comments 技能），请从该上下文继续。如果尚未显示评论，请先获取并展示，然后引导用户逐条处理可操作的评论，收集明确决定，按要求修改代码，最后才请求用户批准是否发布 GitHub 回复或解决审查线程。

何时不使用此技能

如果用户只想获取或查看 PR 评论（改用 pr-comments），或只想修改相关代码而无意在 GitHub 上发布回复或解决线程，请跳过此技能。只有在用户确认希望发布回复或解决线程后，才阅读此技能。

前提条件

• 在 PR 分支对应的仓库检出目录中操作。
• 除非已加载的上下文缺少评论正文、作者、URL、路径或行元数据等必要字段，否则不要重新获取评论。
• 在用户批准最终预览之前，不要发布 GitHub 回复、提交审查或解决线程。

如果上下文中没有 PR 评论，请先获取并展示，然后再继续。若可用，优先调用内置的 /pr-comments 工作流。否则，使用等效的 GitHub CLI 后备方案：识别当前 PR，获取 PR 级评论、审查评论和审查正文，然后通过 insert_code_review_comments 展示。展示获取到的评论后，询问用户是否要继续此回复工作流，然后再进行修改。

评论筛选

询问回复模式前，先从已加载的评论中筛选出仍需用户处理的可操作评论。

跳过以下评论，不要询问用户：

• 来自 Warp/Oz/代码审查机器人的自动 PR 概述或状态评论，尤其是没有关联文件位置、仅总结审查状态或检查进度，或表示无需修改代码的评论。
• 当前 GitHub 用户已经回复过的评论。

要识别当前 GitHub 用户，请优先使用：

GH_PAGER="" gh api user --jq .login

对于审查线程，在可用时使用已加载上下文中的 reply_metadata.parent_comment_id、线程元数据、解决状态和评论顺序。仅当线程已解决，或该线程中最新的相关回复由当前 GitHub 用户撰写时，才跳过原始评论和整个线程。如果审查者在当前用户回复后又添加了更新的跟进评论，则将该线程保留在逐条处理流程中。对于没有明确线程元数据的 PR 级评论，只有在已加载上下文明确显示当前用户针对该评论作出了回复时才跳过，例如直接回复、引用、链接，或紧随其后且明确指向该评论的回复。

如果跳过了自动评论或已回复的评论，请保留一份简短的内部跳过列表，记录评论 URL 和跳过原因。不要为跳过的评论创建决定记录，不要将其纳入逐条处理流程，也不要列入最终的 GitHub 回复／解决预览中；只需简要汇报跳过的数量。

如果无法确定评论是否为自动评论、是否已回复或是否仍需处理，请将其保留在逐条处理流程中。

询问用户的问题要求

此技能中的每次 ask_user_question 调用都必须包含一个使用工具自由输入字段的 Other... 选项。使用该选项，让用户能够输入自定义模式、回复、理由、发布指示或后续步骤，而不必为了收集自定义文本而在正常聊天中交还控制权。

初始模式选择

讨论单条评论之前，调用 ask_user_question，且只提出一个模式问题：

• 逐条回复
• 先收集所有决定，再批量处理
• Other...

后续流程均使用所选模式。

逐条模式

对于每条评论，先收集用户的决定，并立即执行所请求的代码更改，然后再处理下一条评论。每次更改后，记录以下内容：

• 正在处理的评论
• 更改了哪些代码或文档
• 已运行或仍需运行的验证
• GitHub 回复草稿，以及是否应解决该讨论串

批量模式

对于每条评论，先与用户逐条确认决定，暂不编辑代码。批量模式不会跳过信息收集阶段，也不会把信息收集合并处理：用户仍必须能够针对每条评论单独请求更多背景、要求解释、检查相关代码，或提供自定义方案，然后再做决定。所有评论都确定处理方式后，再一次性应用所请求的代码更改，然后进行验证并准备最终的 GitHub 回复预览。

逐条处理流程

按评论显示的顺序处理。对于每条评论：

1. 简要重述相关背景：
   • 作者
   • 文件和行号，或 PR 级位置
   • 可点击的文件引用；有位置元数据时，单行评论使用 path:line，跨行评论使用 path:start-end
   • 简洁的评论摘要
   • 理解评论所需的明显代码背景
2. 如果根据已加载的上下文无法明确确定修复方式，在提供选项前检查相关文件。
3. 调用 ask_user_question，并针对具体评论设置选项。

如果评论附在代码上，先输出文件引用，再询问用户，以便用户快速打开相关位置。使用相对于仓库的路径，例如 src/lib.rs:42 或 src/lib.rs:40-48。对于没有文件位置的 PR 级评论，说明该评论没有关联的代码位置。

始终提供含义如下的选项：

• 应用 Agent 针对该评论推荐的修复方案。
• 在决定前解释这条评论的含义。
• 确认收到评论，但不更改代码。
• Other...

使用 Other... 选项的自由填写字段来收集自定义回复或方案。不要仅为了收集自定义文本，就在普通聊天中把控制权交还给用户。

用户选择“解释”时，简要说明评论的背景、审阅者可能提出该评论的原因，以及其中的权衡。然后针对同一条评论再次询问，并更新选项；不要跳过决定环节。

此解释流程适用于逐条模式和批量模式。在批量模式中，只有最终的代码编辑和 GitHub 评论更新会延后；每条评论的信息收集仍需交互完成。

用户选择“确认收到但不更改代码”时，提供机会让用户补充不做代码更改的理由。将用户提供的任何理由保留在最终 GitHub 回复草稿中。

决策记录

为每条评论维护一条内部决策记录。每条记录应包含：

• 评论标识符或 URL
• 评论类型：审阅讨论串评论、讨论串回复、PR 级评论或审阅正文
• 所选处理方式：修复、解释后修复、确认收到但不更改、其他或不采取行动
• 计划进行的代码更改（如有）
• 所需验证
• 回复草稿正文
• 是否解决审阅讨论串

回复草稿应简洁、具体。优先说明更改了什么，或为什么有意不处理该评论。每条可能发布到 GitHub 的回复草稿都必须以 [Warp Agent] 开头，以便审阅者清楚地知道回复由 Agent 撰写。如果在发布回复前修复已提交并推送，则在回复中加入解决该评论的提交链接，以便审计。

应用修复

遵循用户选择的模式：

• 在逐条模式下，编辑并验证每个已接受的修复，然后再继续处理下一条评论。
• 在批量模式下，等待收集完所有评论的处理决定后，再一次性应用所有已接受的修改。

进行修改时：

• 只应用与所选 PR 评论相关的修改。
• 保留无关的本地修改。
• 遵循仓库特定的编码、测试和样式规则。
• 在逐条模式下，每次修复后运行最精简且有用的验证；应用所有修复后，运行最终验证。
• 如果请求的修复不安全、含糊不清，或与另一条评论冲突，请停止并在编辑前询问用户。

最终验证

应用所有已接受的修复后：

1. 检查 git diff，确认修改与收集到的处理决定一致。
2. 根据仓库惯例和修改的文件，运行相关的格式化、lint、类型检查、构建或测试。
3. 如果无法运行验证，请在最终摘要中说明原因，并在预览中注明这一限制。

除非用户明确要求，否则不要提交修改。

回复 GitHub 前先提交并推送

验证完成后，在发布任何 GitHub 回复或解决评审讨论串之前，询问用户是否要将修改提交并推送到 origin。这样可确保评审者先看到已推送的代码，再看到 Agent 撰写的评论回复。

如果处理评论后工作树没有变化，请跳过提交/推送问题，直接继续 GitHub 回复预览。

调用 ask_user_question，并提供类似以下选项：

• Commit and push these changes to origin before posting replies
• Do not commit or push; continue to the GitHub reply preview
• Stop before posting GitHub replies
• Other...

如果用户选择提交并推送：

1. 检查 git status 和最终 diff，确保只包含针对评论所做的预期修改。
2. 如果提交信息尚不明确，请询问或提议一条简洁的提交信息；保留 Other... 选项，以便用户提供自定义提交说明。
3. 暂存预期的修改，使用非交互式命令提交，并将当前分支推送到 origin。
4. 在提交信息中加入 Co-Authored-By: Warp Agent <[email protected]>（绝不要将其加入 PR 描述），如果提交中已包含此项，则不要重复添加。
5. 如果提交或推送失败，请停止，不要发布 GitHub 回复，并报告失败情况。

GitHub 回复和解决讨论串的预览

完成提交/推送决策后，在 GitHub 上发布任何内容之前，按评论分组展示预览。每条评论都应包括：

• 评论 URL 或简短标识符
• 操作：仅回复、仅解决、回复并解决，或不执行 GitHub 操作
• 回复内容
• 提交链接（若修复对应的提交已推送）
• 与该评论相关的验证

然后调用 ask_user_question，询问是否继续：

• Post replies and resolve approved threads
• Edit the draft responses first
• Do not post anything
• Other...

如果用户选择编辑，请收集其修改，更新预览，然后再次请求批准。只有用户选择批准选项后才能发布。

使用 GitHub CLI 发帖

只有获得批准后才能使用 GitHub CLI。所有 gh 命令都要关闭分页器。

运行任何会发布回复或 PR 评论的 GitHub CLI 命令前，都要确认要发送的正文以 [Warp Agent] 开头。如果不是，请先添加此前缀再发布。

对于审查评论，请使用 REST API 端点发布回复。将回复正文写入临时 JSON 文件，并通过 --input 传入，不要将回复文本直接放在命令行参数中：

REPLY_BODY_FILE="$(mktemp)"
cat > "$REPLY_BODY_FILE"
REPLY_PAYLOAD_FILE="$(mktemp)"
python3 - "$REPLY_BODY_FILE" "$REPLY_PAYLOAD_FILE" <<'PY'
import json
import sys
from pathlib import Path

body_file = Path(sys.argv[1])
payload_file = Path(sys.argv[2])
payload_file.write_text(json.dumps({"body": body_file.read_text()}))
PY
GH_PAGER="" gh api \
  --method POST \
  /repos/{owner}/{repo}/pulls/{pull_number}/comments/{comment_id}/replies \
  --input "$REPLY_PAYLOAD_FILE"
rm -f "$REPLY_BODY_FILE" "$REPLY_PAYLOAD_FILE"

对于无法直接加入讨论串的 PR 级评论或审查正文评论，请发布普通 PR 评论，并引用或链接到原评论：

REPLY_BODY_FILE="$(mktemp)"
cat > "$REPLY_BODY_FILE"
GH_PAGER="" gh pr comment {pull_number} --body-file "$REPLY_BODY_FILE"
rm -f "$REPLY_BODY_FILE"

要解决审查讨论串，请使用 GraphQL。如果尚未知道讨论串节点 ID，请查询 PR 的所有审查讨论串，并将已加载的评论 ID 对应到其所属的讨论串。使用分页，以便也能解决前 100 条之外的讨论串：

GH_PAGER="" gh api graphql --paginate \
  -f owner="{owner}" \
  -f repo="{repo}" \
  -F number={pull_number} \
  -f query='
    query($owner: String!, $repo: String!, $number: Int!, $endCursor: String) {
      repository(owner: $owner, name: $repo) {
        pullRequest(number: $number) {
          reviewThreads(first: 100, after: $endCursor) {
            pageInfo {
              hasNextPage
              endCursor
            }
            nodes {
              id
              isResolved
              comments(first: 100) {
                nodes {
                  databaseId
                  url
                }
              }
            }
          }
        }
      }
    }'

使用以下命令解决已批准的讨论串：

GH_PAGER="" gh api graphql \
  -f threadId="$THREAD_ID" \
  -f query='mutation($threadId: ID!) { resolveReviewThread(input: { threadId: $threadId }) { thread { id isResolved } } }'

如果根据现有元数据无法回复或解决某条评论，请说明这一限制，并建议手动在 GitHub 上操作，不要猜测。

最终回复

发布已批准的回复并解决已批准的讨论串后，请总结：

• 已处理的评论
• 已更改的文件
• 验证结果
• 更改是否已提交并推送到 origin
• 已发布的 GitHub 回复或已解决的讨论串
• 留给用户处理的事项