Back to Details

pr-comments-address

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Address review comments on the following PR: $ARGUMENTS
处理以下PR的评审评论：$ARGUMENTS

Workflow

工作流程

Step 1: Resolve the PR

步骤1：确定PR

If 
$ARGUMENTS
is provided, use it directly as the PR number or URL. Otherwise, detect the PR from the current branch:
bash
gh pr view --json number,url,title
If no PR is found for the current branch, stop and ask the user to provide a PR number or URL.
If 
CLAUDE.md
or 
.claude/rules/
exist in the repo, read and follow them. If they are absent, skip silently and apply general best practices.
如果提供了
$ARGUMENTS
，则直接将其用作PR编号或URL。否则，从当前分支检测PR：
bash
gh pr view --json number,url,title
如果当前分支未找到对应的PR，请停止操作并询问用户提供PR编号或URL。
如果仓库中存在
CLAUDE.md
或
.claude/rules/
，请读取并遵循其中的规则。如果不存在，则直接跳过并应用通用最佳实践。

Step 2: Fetch PR Comments

步骤2：获取PR评论

Fetch the PR comments using the GitHub CLI:
bash
gh pr view <PR> --comments --json reviews,comments,reviewThreads
Read the output carefully. Identify every unresolved review comment — inline code comments and top-level review comments.
使用GitHub CLI获取PR评论：
bash
gh pr view <PR> --comments --json reviews,comments,reviewThreads
仔细读取输出内容，识别每一条未解决的评审评论——包括行内代码评论和顶级评审评论。

Step 3: Triage Comments

步骤3：分类评论

Enter plan mode. Do NOT make any changes yet. Categorize every comment into one of:
  • Clear fix — the required change is unambiguous
  • Ambiguous — the intent or correct solution is unclear
  • Discussion only — no code change needed, just a reply (e.g. questions, praise, acknowledgements)
进入规划模式，暂不进行任何修改。将每条评论归入以下类别之一：
  • 明确修复——所需修改清晰明确
  • 模糊待确认——意图或正确解决方案不明确
  • 仅需讨论——无需修改代码，仅需回复（例如问题、表扬、确认）

Step 4: Present Triage and Resolve Ambiguity

步骤4：展示分类结果并解决模糊点

Present the comment triage to the user and stop. Show the full table, then surface every ambiguous comment with its file location and ask explicitly what change should be made. Do not proceed until the user has answered every ambiguous comment.
向用户展示评论分类结果并暂停操作。展示完整的分类表格，然后列出所有模糊待确认的评论及其文件位置，明确询问应进行何种修改。在用户回复所有模糊问题之前，请勿继续操作。

Step 5: Present the Confirmed Plan

步骤5：展示确认后的计划

Show what you are about to change for every clear-fix and now-clarified comment. Ask the user to confirm before touching any file. Wait for explicit user confirmation. Do not apply any changes until the user says yes.
针对所有明确修复和已澄清的评论，展示即将进行的修改内容。在修改任何文件之前，请用户确认。等待用户明确确认，在用户同意之前请勿进行任何修改。

Step 6: Apply Code Fixes

步骤6：应用代码修复

Apply code fixes for all clear-fix and clarified comments:
  • Read the full file before editing — never patch blindly from the comment alone
  • Make the minimal change that addresses the comment
  • Do not refactor, reformat, or improve code outside the scope of the comment
  • Do not fix multiple comments in a single edit if they touch the same file — apply them one at a time to avoid conflicts
对所有明确修复和已澄清的评论应用代码修复：
  • 编辑前请完整读取文件——切勿仅根据评论盲目修改
  • 仅进行能解决评论问题的最小改动
  • 请勿对评论范围外的代码进行重构、格式化或优化
  • 如果多条评论涉及同一文件，请勿在单次编辑中修复多个问题——应逐一应用修改以避免冲突

Step 7: Draft Replies

步骤7：草拟回复

Draft a reply for every comment (clear fix, ambiguous, and discussion-only):
  • For fixed comments: confirm what was changed, briefly
  • For discussion-only comments: write a natural, concise acknowledgement or answer
  • Keep replies short and professional — no filler phrases like "Great point!" or "Thanks for the feedback!"
  • Write in first person as the PR author
为每条评论草拟回复（包括明确修复、模糊待确认和仅需讨论的评论）：
  • 针对已修复的评论：简要说明已完成的修改
  • 针对仅需讨论的评论：撰写自然、简洁的回复或解答
  • 回复需简短专业——避免使用“好观点！”或“感谢反馈！”之类的套话
  • 以PR作者的第一人称撰写

Step 8: Present Reply Drafts

步骤8：展示草拟的回复

Present the reply drafts to the user for review. Wait for confirmation or edits from the user before posting anything.
将草拟的回复展示给用户审阅。在发布任何内容之前，等待用户的确认或修改意见。

Step 9: Post Replies

步骤9：发布回复

Post the replies using the GitHub CLI once the user approves:
bash
gh api repos/{owner}/{repo}/pulls/comments/{comment_id}/replies \
  -f body="<reply text>"
Post each reply to its corresponding comment thread.
获得用户批准后，使用GitHub CLI发布回复：
bash
gh api repos/{owner}/{repo}/pulls/comments/{comment_id}/replies \
  -f body="<reply text>"
将每条回复发布到对应的评论线程中。

Important

重要提示

  • Never guess at the intent of an unclear comment — always surface it with full context and ask explicitly
  • Confirm changes factually: "Done — extracted into a separate hook."
  • Answer questions directly without over-explaining
  • For subjective comments where you disagree: draft a reply that opens a dialogue rather than blindly accepting
  • Never use filler phrases: "Great catch!", "Thanks for the feedback!", "Absolutely!"
  • Do not resolve comment threads — let the reviewer do that
  • Do not push commits or open new PRs
  • Do not change files unrelated to a review comment
  • 切勿猜测模糊评论的意图——务必提供完整上下文并明确询问用户
  • 如实确认修改：“已完成——提取为独立的hook。”
  • 直接回答问题，无需过度解释
  • 对于存在分歧的主观性评论：草拟回复以开启对话，而非盲目接受
  • 切勿使用套话：“发现得好！”“感谢反馈！”“完全同意！”
  • 请勿标记评论线程为已解决——让评审者来完成此操作
  • 请勿推送提交或创建新的PR
  • 请勿修改与评审评论无关的文件

Examples

示例

Positive Trigger

触发示例

User: "address the review comments and fix the code feedback on PR #42"
Expected behavior: Use 
pr-comments-address
to fetch comments from PR #42, triage them into clear fix / ambiguous / discussion-only, present the triage table, and wait for user input before making changes.
User: "fix the PR feedback on my current branch"
Expected behavior: Use 
pr-comments-address
to detect the PR from the current branch via 
gh pr view
, fetch all unresolved review comments, and present the triage for user confirmation.
User: "respond to the code review on https://github.com/org/repo/pull/99"
Expected behavior: Use 
pr-comments-address
with the provided PR URL, fetch comments, triage, apply fixes after confirmation, and draft replies for user approval before posting.
用户：“处理PR #42的评审评论并修复代码反馈”
预期行为：使用
pr-comments-address
从PR #42获取评论，将其分类为明确修复/模糊待确认/仅需讨论，展示分类表格，等待用户输入后再进行修改。
用户：“修复我当前分支的PR反馈”
预期行为：使用
pr-comments-address
通过
gh pr view
从当前分支检测PR，获取所有未解决的评审评论，展示分类结果供用户确认。
用户：“回复https://github.com/org/repo/pull/99上的代码评审”
预期行为：使用
pr-comments-address
处理提供的PR URL，获取评论，分类，获得确认后应用修复，草拟回复供用户批准后发布。

Non-Trigger

非触发示例

User: "review this pull request #123"
Expected behavior: Do not use 
pr-comments-address
. The user wants to review a PR, not address existing comments. Use a PR review workflow instead.
User: "create a pull request for my branch"
Expected behavior: Do not use 
pr-comments-address
. The user wants to create a new PR, not address review comments on an existing one.
用户：“评审这个拉取请求#123”
预期行为：请勿使用
pr-comments-address
。用户想要评审PR，而非处理现有评论。请使用PR评审工作流替代。
用户：“为我的分支创建一个拉取请求”
预期行为：请勿使用
pr-comments-address
。用户想要创建新的PR，而非处理现有PR的评审评论。

Troubleshooting

故障排除

Skill Does Not Trigger

技能未触发

  • Error: The skill is not selected when the user asks to address PR comments.
  • Cause: Request wording does not match the description trigger conditions.
  • Solution: Rephrase with explicit keywords like "address review comments", "fix PR feedback", or "handle PR comments" and retry.
  • 错误：当用户要求处理PR评论时，未选择该技能。
  • 原因：请求措辞不符合描述中的触发条件。
  • 解决方案：使用明确的关键词重新表述，例如“处理评审评论”“修复PR反馈”或“处理PR评论”，然后重试。

No PR Found for Current Branch

当前分支未找到PR

  • Error: 
    gh pr view
    returns no PR for the current branch.
  • Cause: The current branch does not have an open PR, or the branch has not been pushed.
  • Solution: Provide the PR number or URL explicitly as an argument, or push the branch and create a PR first.
  • 错误：
    gh pr view
    未返回当前分支对应的PR。
  • 原因：当前分支未关联开放的PR，或分支尚未推送。
  • 解决方案：明确提供PR编号或URL作为参数，或先推送分支并创建PR。

No Unresolved Comments

无未解决评论

  • Error: The PR has no unresolved review comments to address.
  • Cause: All comments have already been resolved, or the PR has no review comments.
  • Solution: Inform the user that there are no pending comments. If they expect comments, suggest checking that the correct PR was targeted.
  • 错误：PR中没有需要处理的未解决评审评论。
  • 原因：所有评论已解决，或PR未收到任何评审评论。
  • 解决方案：告知用户没有待处理的评论。如果用户预期存在评论，建议检查是否定位到了正确的PR。

GitHub CLI Not Authenticated

GitHub CLI未认证

  • Error: 
    gh
    commands fail with authentication errors.
  • Cause: The GitHub CLI is not logged in or the token has expired.
  • Solution: Run 
    gh auth login
    to authenticate, then retry the skill.
  • 错误：
    gh
    命令因认证错误失败。
  • 原因：GitHub CLI未登录或令牌已过期。
  • 解决方案：运行
    gh auth login
    进行认证，然后重试该技能。