respond-to-pr-comments-in-blocklist

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Respond to PR comments in blocklist

批量回复PR评论

Use this skill to respond to PR comments on the current branch. If comments are already visible in the conversation, typically from the built-in

/pr-comments

skill, continue from that context. If comments are not already visible, fetch and display them first, then guide the user through each actionable comment, collect an explicit decision, make requested code changes, and only then ask for approval before posting GitHub replies or resolving review threads.

使用此技能回复当前分支上的PR评论。如果评论已在对话中显示（通常来自内置的

/pr-comments

技能），则基于该上下文继续。如果评论未显示，先获取并展示它们，然后引导用户处理每条可操作的评论，收集明确的决策，执行要求的代码更改，之后在发布GitHub回复或处理评审线程前请求用户批准。

Preconditions

前置条件

Work in the repository checkout for the PR branch.
Do not refetch comments unless the loaded context is missing essential fields such as comment body, author, URL, path, or line metadata.
Do not post GitHub replies, submit reviews, or resolve threads until the final preview is approved by the user.

If no PR comments are present in context, fetch and display them before continuing. Prefer invoking the built-in

/pr-comments

workflow when available. Otherwise use the equivalent GitHub CLI fallback: identify the current PR, fetch PR-level comments, review comments, and review bodies, then display them with

insert_code_review_comments

. After displaying fetched comments, ask the user whether to continue with this response workflow before making changes.

在PR分支的仓库检出目录中工作。
除非加载的上下文缺少必要字段（如评论内容、作者、URL、路径或行元数据），否则不要重新获取评论。
在用户批准最终预览前，不要发布GitHub回复、提交评审或处理线程。

如果上下文中没有PR评论，先获取并展示它们再继续。如果可用，优先调用内置的

/pr-comments

工作流。否则使用等效的GitHub CLI备选方案：识别当前PR，获取PR级评论、评审评论和评审内容，然后使用

insert_code_review_comments

展示它们。展示获取的评论后，在进行更改前询问用户是否要继续此回复工作流。

Comment filtering

评论过滤

Before asking for response mode, filter the loaded comments down to actionable comments that still need the user's attention.

Skip these comments without asking the user about them:

Automated PR-level overview or status comments from Warp/Oz/code-review bots, especially comments with no attached file location that summarize review status, check progress, or say no code change is requested.
Comments that have already been responded to by the current GitHub user.

To identify the current GitHub user, prefer:

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

For review threads, use

reply_metadata.parent_comment_id

, thread metadata, resolution state, and comment ordering from the loaded context when available. Skip the original comment and thread only when the thread is already resolved or when the latest relevant reply in that thread was authored by the current GitHub user. If a reviewer added a newer follow-up after the current user's reply, keep the thread in the walkthrough. For PR-level comments without explicit thread metadata, skip only when the loaded context clearly shows a current-user response to that specific comment, such as a direct reply, quote, link, or immediately following response that references it.

If an automated or already-answered comment is skipped, keep a short internal skipped list with the comment URL and reason. Do not create decision records for skipped comments, do not include them in the per-comment walkthrough, and do not include them in the final GitHub reply/resolution preview except as a brief skipped-count summary.

When unsure whether a comment is automated, already answered, or still actionable, keep it in the walkthrough rather than skipping it.

在询问回复模式前，将加载的评论筛选为仍需用户关注的可操作评论。

跳过以下评论，无需询问用户：

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

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

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

对于评审线程，在可用时使用加载上下文中的

reply_metadata.parent_comment_id

、线程元数据、处理状态和评论排序。仅当线程已处理或线程中最新相关回复由当前GitHub用户撰写时，才跳过原始评论和线程。如果评审者在当前用户回复后添加了新的跟进评论，则保留该线程在引导流程中。对于没有明确线程元数据的PR级评论，仅当加载的上下文明确显示当前用户对该特定评论的回复（如直接回复、引用、链接或紧随其后的相关回复）时才跳过。

如果跳过了自动化或已回复的评论，保留包含评论URL和原因的简短内部跳过列表。不为跳过的评论创建决策记录，不将它们纳入逐条评论的引导流程，仅在最终GitHub回复/处理预览中包含简短的跳过数量摘要。

如果不确定评论是否为自动化、已回复或仍可操作，将其保留在引导流程中而非跳过。

Ask User Question requirements

用户提问要求

Every

ask_user_question

call in this skill must include an

Other...

option that uses the tool's freeform other field. Use that option to let the user enter a custom mode, response, rationale, posting instruction, or next step without returning control in normal chat solely to collect custom text.

此技能中的每个

ask_user_question

调用必须包含一个

Other...

选项，使用工具的自由格式其他字段。使用该选项让用户输入自定义模式、回复、理由、发布指令或下一步操作，无需在常规聊天中返回控制权来收集自定义文本。

Initial mode selection

初始模式选择

Before discussing individual comments, call

ask_user_question

with exactly one mode question:

```
Respond one-by-one
```

Collect all decisions, then address in a batch

```
Other...
```

Use the selected mode for the rest of the workflow.

在讨论单个评论前，调用

ask_user_question

并提出一个模式问题，包含以下选项：

```
Respond one-by-one
```
（逐条回复）

Collect all decisions, then address in a batch

（收集所有决策后批量处理）

```
Other...
```
（其他...）

将所选模式用于后续整个工作流。

One-by-one mode

逐条模式

For each comment, collect the user's decision and immediately perform any requested code change before moving to the next comment. After each change, keep a note of:

the comment being addressed
what code or documentation changed
what validation was run or still needs to run
the draft GitHub reply and whether the thread should be resolved

对于每条评论，收集用户的决策并立即执行任何要求的代码更改，再处理下一条评论。每次更改后记录：

正在处理的评论
代码或文档的更改内容
已运行或仍需运行的验证
草稿GitHub回复以及是否应处理该线程

Batch mode

批量模式

For each comment, interactively collect the user's decision without editing code yet. Batch mode does not batch or skip the information-gathering phase: the user must still be able to ask for more context, request an explanation, inspect the referenced code, or provide a custom approach for any individual comment before deciding. After all comments have a decision, apply the requested code changes in one batch, then validate and prepare the final GitHub reply preview.

对于每条评论，交互式收集用户的决策，但暂不编辑代码。批量模式不会批量或跳过信息收集阶段：用户仍可要求获取更多上下文、请求解释、检查引用的代码或为任何单个评论提供自定义方法，然后再做决策。所有评论都有决策后，批量应用要求的代码更改，然后验证并准备最终GitHub回复预览。

Per-comment walkthrough

逐条评论引导流程

Process comments in the order they were displayed. For each comment:

Restate the relevant context briefly:
- author
- file and line or PR-level location
- a clickable file reference formatted as
```
path:line
```
  for single-line comments or
```
path:start-end
```
  for ranged comments when location metadata is available
- a concise summary of the comment
- any obvious code context needed to understand it
If the fix is not obvious from the loaded context, inspect the relevant files before presenting options.
Call
```
ask_user_question
```
with options tailored to the specific comment.

When a comment is attached to code, print the file reference before asking the question so the user can quickly open the relevant section. Use repository-relative paths, for example

src/lib.rs:42

src/lib.rs:40-48

. For PR-level comments with no file location, state that there is no attached code location.

Always include options with these meanings:

Apply the agent's recommended fix for this comment.
Explain what this comment means before deciding.
Acknowledge the comment but do not make code changes.
```
Other...
```

Use the

Other...

option's freeform field for custom responses or approaches. Do not return control to the user in normal chat solely to collect custom freeform text.

When the user selects "explain", provide concise context about the comment, why the reviewer likely raised it, and what tradeoffs are involved. Then ask about the same comment again with updated options; do not skip the decision.

This explanation loop applies in both one-by-one mode and batch mode. In batch mode, only the eventual code edits and GitHub comment updates are deferred; per-comment information gathering remains interactive.

When the user selects "acknowledge without changes", give them the option to provide more information about why no code changes are being made. Preserve any provided rationale for the final GitHub reply draft.

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

简要重述相关上下文：
- 作者
- 文件和行号或PR级位置
- 可点击的文件引用，当有位置元数据时，单行评论格式为
```
path:line
```
  ，范围评论格式为
```
path:start-end
```
- 评论的简明摘要
- 理解评论所需的任何明显代码上下文
如果从加载的上下文无法明确修复方案，先检查相关文件再呈现选项。
调用
```
ask_user_question
```
并提供针对该特定评论的选项。

当评论附加到代码时，在提问前打印文件引用，以便用户快速打开相关部分。使用仓库相对路径，例如

src/lib.rs:42

或

src/lib.rs:40-48

。对于没有文件位置的PR级评论，说明没有附加代码位置。

始终包含以下含义的选项：

应用Agent针对此评论的推荐修复。
先解释此评论的含义再做决策。
确认收到评论但不做代码更改。
```
Other...
```
（其他...）

使用

Other...

选项的自由格式字段输入自定义回复或方法。无需在常规聊天中返回控制权来收集自定义自由格式文本。

当用户选择“解释”时，提供关于评论的简明上下文、评审者提出该评论的可能原因以及涉及的权衡。然后再次询问同一评论并提供更新后的选项；不要跳过决策。

此解释循环适用于逐条模式和批量模式。在批量模式下，仅延迟最终的代码编辑和GitHub评论更新；逐条信息收集仍保持交互式。

当用户选择“确认但不更改”时，让他们选择提供不做代码更改的更多信息。保留提供的理由用于最终GitHub回复草稿。

Decision records

决策记录

Maintain an internal decision record for every comment. Each record should include:

comment identifier or URL
comment type: review-thread comment, thread reply, PR-level comment, or review body
selected disposition: fix, explain-then-fix, acknowledge-without-changes, custom, or no-action
planned code change, if any
validation needed
draft reply body
whether to resolve the review thread

For draft replies, be concise and concrete. Prefer replies that say what changed or why the comment is intentionally not addressed. Prefix every draft reply that may be posted to GitHub with

[Warp Agent]

so reviewers can clearly see the response was agent-authored. If the fix has already been committed and pushed before replies are posted, include a link to the commit that resolved the comment so the response is auditable.

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

评论标识符或URL
评论类型：评审线程评论、线程回复、PR级评论或评审内容
选定的处理方式：修复、解释后修复、确认但不更改、自定义或无操作
计划的代码更改（如有）
需要的验证
草稿回复内容
是否应处理评审线程

对于草稿回复，保持简洁具体。优先使用说明更改内容或为何故意不处理该评论的回复。所有可能发布到GitHub的草稿回复前缀为

[Warp Agent]

，以便评审者清楚看到该回复由Agent生成。如果在发布回复前已提交并推送修复，包含指向解决该评论的提交链接，使回复可审计。

Applying fixes

应用修复

Follow the user's selected mode:

In one-by-one mode, edit and validate each accepted fix before continuing to the next comment.
In batch mode, wait until all comment decisions are collected, then make all accepted edits together.

When making changes:

Apply only changes related to the selected PR comments.
Preserve unrelated local changes.
Follow repository-specific coding, testing, and style rules.
Run the narrowest useful validation after each one-by-one fix, and run final validation after all fixes are applied.
If a requested fix is unsafe, ambiguous, or conflicts with another comment, stop and ask the user before editing.

遵循用户选择的模式：

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

进行更改时：

仅应用与选定PR评论相关的更改。
保留无关的本地更改。
遵循仓库特定的编码、测试和样式规则。
在逐条模式下每次修复后运行最窄范围的有用验证，在所有修复完成后运行最终验证。
如果请求的修复不安全、不明确或与其他评论冲突，停止操作并询问用户后再编辑。

Final validation

最终验证

After all accepted fixes are applied:

Review
```
git diff
```
to confirm the changes match the collected decisions.
Run relevant formatting, linting, typechecking, build, or tests based on the repository's conventions and the files changed.
If validation cannot be run, explain why in the final summary and include that caveat in the preview.

Do not commit changes unless the user explicitly asks.

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

查看
```
git diff
```
以确认更改与收集的决策一致。
根据仓库约定和更改的文件，运行相关的格式化、 linting、类型检查、构建或测试。
如果无法运行验证，在最终摘要中解释原因，并在预览中包含该警告。

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

Commit and push before GitHub responses

提交并推送后再发送GitHub回复

After validation and before posting any GitHub replies or resolving review threads, ask whether the user wants to commit the changes and push them to

origin

. This order ensures reviewers see pushed code before they see agent-authored comment responses.

If there are no working tree changes from addressing comments, skip the commit/push question and continue to the GitHub reply preview.

Call

ask_user_question

with options like:

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...
```

If the user chooses to commit and push:

Review
```
git status
```
and the final diff so only intended comment-response changes are included.
Ask for or propose a concise commit message if one is not already clear; preserve the
```
Other...
```
option for custom commit instructions.
Stage the intended changes, commit in a non-interactive command, and push the current branch to
```
origin
```
.
Include
```
Co-Authored-By: Oz <oz-agent@warp.dev>
```
in the commit message.
If commit or push fails, stop before posting GitHub replies and report the failure.

验证完成后，在发布任何GitHub回复或处理评审线程前，询问用户是否要提交更改并推送到

origin

。此顺序确保评审者在看到Agent生成的评论回复前先看到已推送的代码。

如果处理评论后工作树没有更改，跳过提交/推送问题，直接进入GitHub回复预览。

调用

ask_user_question

并提供如下选项：

Commit and push these changes to origin before posting replies

（发布回复前提交并推送这些更改到origin）

Do not commit or push; continue to the GitHub reply preview

（不提交或推送；继续到GitHub回复预览）

```
Stop before posting GitHub replies
```
（在发布GitHub回复前停止）
```
Other...
```
（其他...）

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

查看
```
git status
```
和最终diff，确保仅包含预期的评论回复相关更改。
如果没有明确的提交消息，请求或建议一个简洁的提交消息；保留
```
Other...
```
选项用于自定义提交指令。
暂存预期的更改，通过非交互式命令提交，并将当前分支推送到
```
origin
```
。
在提交消息中包含
```
Co-Authored-By: Oz <oz-agent@warp.dev>
```
。
如果提交或推送失败，在发布GitHub回复前停止并报告失败。

GitHub reply and resolution preview

GitHub回复和处理预览

After the commit/push decision is complete, and before posting anything to GitHub, show a preview grouped by comment. For each comment include:

comment URL or short identifier
action: reply only, resolve only, reply and resolve, or no GitHub action
reply body
commit link, when a pushed commit exists for the fix
validation relevant to that comment

Then call

ask_user_question

to ask whether to proceed:

Post replies and resolve approved threads

```
Edit the draft responses first
```
```
Do not post anything
```
```
Other...
```

If the user chooses to edit, collect their edits, update the preview, and ask for approval again. Do not post until the user selects the approval option.

提交/推送决策完成后，在发布任何内容到GitHub前，按分组展示预览。对于每条评论包含：

评论URL或短标识符
操作：仅回复、仅处理、回复并处理或无GitHub操作
回复内容
提交链接（如果存在修复的已推送提交）
与该评论相关的验证

然后调用

ask_user_question

询问是否继续：

```
Post replies and resolve approved threads
```
（发布回复并处理已批准的线程）
```
Edit the draft responses first
```
（先编辑草稿回复）
```
Do not post anything
```
（不发布任何内容）
```
Other...
```
（其他...）

如果用户选择编辑，收集他们的修改，更新预览并再次请求批准。直到用户选择批准选项后再发布。

Posting with GitHub CLI

使用GitHub CLI发布

Use the GitHub CLI only after approval. Clear the pager for all

gh

commands.

Before running any GitHub CLI command that posts a reply or PR comment, verify the outgoing body begins with

[Warp Agent]

. If it does not, add the prefix before posting.

For review comments, post replies with the REST API endpoint. Write the reply body to a temporary JSON file and pass it with

--input

instead of putting the response text directly in command-line arguments:

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"

For PR-level comments or review-body comments that cannot be directly threaded, post a normal PR comment and quote or link to the original comment:

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"

To resolve review threads, use GraphQL. If the thread node ID is not already known, query all review threads for the PR and map loaded comment IDs to their containing thread. Use pagination so threads beyond the first 100 can still be resolved:

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
                }
              }
            }
          }
        }
      }
    }'

Resolve an approved thread with:

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

If a comment cannot be replied to or resolved through the available metadata, report the limitation and suggest a manual GitHub action instead of guessing.

仅在获得批准后使用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操作，而非猜测。

Final response

最终回复

After posting approved responses and resolving approved threads, summarize:

comments addressed
files changed
validation results
whether changes were committed and pushed to
```
origin
```
GitHub replies or resolutions posted
anything left for the user

发布已批准的回复并处理已批准的线程后，总结：

已处理的评论
更改的文件
验证结果
是否已提交并推送到
```
origin
```
已发布的GitHub回复或处理操作
剩余需用户完成的事项