Back to Details

respond-to-code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Respond to code review

响应代码评审

Work from the actual review comments and current code. Verify claims before changing code or replying.
基于实际评审意见和当前代码开展工作。在修改代码或回复前，先核实相关说法。

Scope

适用范围

  • If the user asks only to check or summarize comments, collect and assess them, then report findings. Do not edit code or post replies.
  • If the user asks to address or respond to comments, apply verified fixes, run relevant checks, and reply as authorized.
  • Identify the pull request or merge request from the link, number, current branch, or repository context. Ask only if more than one target remains plausible.
  • Use the team's existing authenticated tools. If GitHub CLI is missing and would help, read the optional one-time setup guide; offer it to the user rather than assuming they want it installed.
  • 若用户仅要求检查或总结意见，请收集并评估意见，再报告结果。不要编辑代码或发布回复。
  • 若用户要求处理或回复意见，请实施经过验证的修复，运行相关检查，并在授权范围内进行回复。
  • 从链接、编号、当前分支或仓库上下文确定对应的 pull request 或 merge request。仅当存在多个可能的目标时，再向用户询问。
  • 使用团队已有的已认证工具。如果缺少 GitHub CLI 且它会有所帮助，请阅读可选的一次性设置指南；向用户提供该指南，而不是默认他们想要安装。

Workflow

工作流程

Required on every use: Identify the review platform and read its procedure before collecting feedback: GitHub, GitLab, or Bitbucket. Read the matching reference even if you have used this skill before; it contains the platform's collection, reply, and resolution steps. Skip the other platforms' references; read a one-time setup guide only when setup is needed.
  1. Collect all feedback. Read review summaries, inline comments and replies, unresolved threads, and CI status. Check for newer comments after the last push. Human and bot reviewers vary by repository; never assume Copilot, Codex, Claude, or any other bot is configured.
  2. Verify each finding. Inspect the relevant code and reproduce the behavior or run a focused check where possible. For claims about a library or API, consult current documentation. Mark each finding as valid, already addressed, unclear, or unsupported; explain the evidence for anything not changed.
  3. Make focused fixes when requested. Follow the repository's branch, commit, and test rules. Keep independent fixes reviewable. Do not change unrelated behavior to satisfy a comment, and do not claim a fix until its relevant check passes.
  4. Respond to the review. Post one consolidated reply covering every finding, with fixes, evidence, and reasons for items not changed. This is the default even when findings came from several reviewers. Reply in individual threads only when the user asks, or the platform or repository requires thread-specific replies or resolution. Avoid duplicate replies.
  5. Check readiness. Confirm the latest checks and review status. Merge only when the user has authorized merging, including authorization already given in the conversation. Addressing comments alone does not authorize a merge.
If a finding remains unclear after checking code and documentation, or reviewers contradict each other or a user decision, explain the conflict and ask for the missing decision. Never apply an unverified suggestion merely to close a thread.
每次使用都必须执行： 在收集反馈前，先确定评审平台并阅读对应流程：GitHub、GitLab 或 Bitbucket。即使你之前使用过本技能，也请阅读对应的参考文档；其中包含该平台的反馈收集、回复和解决步骤。无需阅读其他平台的参考文档；仅在需要设置时才阅读一次性设置指南。
  1. 收集所有反馈。 阅读评审摘要、行内评论及回复、未解决的讨论线程和 CI 状态。检查最后一次推送后是否有新的评论。不同仓库的人工评审者和机器人评审者配置不同；切勿默认已配置 Copilot、Codex、Claude 或其他任何机器人。
  2. 核实每一项评审结论。 检查相关代码，尽可能复现问题行为或运行针对性检查。对于涉及库或 API 的说法，请查阅最新文档。将每一项结论标记为有效、已处理、不明确或不成立；对于未修改的内容，需说明依据。
  3. 按需进行针对性修复。 遵循仓库的分支、提交和测试规则。确保独立的修复项便于评审。不要为了满足某条评论而修改不相关的行为，且在相关检查通过前，不要声称已完成修复。
  4. 回复评审。 发布一条统一的回复，涵盖所有评审结论，包括修复内容、验证依据以及未修改项的原因。即使结论来自多位评审者，这也是默认方式。仅当用户要求，或平台/仓库要求按线程回复或解决时，才在单独的线程中回复。避免重复回复。
  5. 检查就绪状态。 确认最新的检查结果和评审状态。仅当用户已授权合并（包括对话中已给出的授权）时才可执行合并。仅处理评审意见并不等同于获得合并授权。
如果在检查代码和文档后，某项结论仍然不明确，或者评审者之间、评审者与用户决策之间存在冲突，请说明冲突情况，并询问所需的决策。切勿为了关闭线程而采纳未经验证的建议。

Waiting for reviews

等待评审

Wait only for reviewers that were requested or are expected from the repository's known configuration. A reaction, reviewing comment, or changed review-request state indicates activity; allow more time and check again. An explicit decline ends that wait. With no activity, check up to three times about 3–4 minutes apart, then report that no review has appeared yet and stop polling. Use a timer or background monitor when available instead of blocking the task. Never claim a bot review passed merely because no comment appeared. If the user wants to enable optional reviewers, see review bot setup; setup is separate from responding to existing feedback.
仅等待已被邀请或根据仓库已知配置预期会参与的评审者。收到反应、评审评论或评审请求状态变更都表示有活动，请给予更多时间后再检查。明确拒绝则结束等待。如果没有任何活动，每隔3-4分钟检查一次，最多检查三次，之后报告尚未收到评审并停止轮询。如有可用的计时器或后台监控工具，请使用它们而不要阻塞任务。切勿仅因没有收到评论就声称机器人评审已通过。如果用户想要启用可选评审者，请参阅评审机器人设置；设置工作与响应现有反馈是分开的。

Reply format

回复格式

For each finding, give its location or reviewer reference and one of:
  • Fixed: the change, evidence from a test or check, and commit if available.
  • Already addressed: where the existing code or earlier commit handles it.
  • Not changed: the specific reason and supporting code or documentation.
  • Needs decision: the unresolved question and its effect on the PR or MR.
Keep the reply short enough to scan. Resolve threads only after their findings are addressed and the team's workflow permits it.
对于每一项评审结论，给出其位置或评审者引用，并标注以下状态之一：
  • 已修复： 说明修改内容、测试或检查的验证依据，以及提交记录（如有）。
  • 已处理： 说明现有代码或更早的提交已处理该问题的位置。
  • 未修改： 说明具体原因，以及支撑的代码或文档依据。
  • 需决策： 说明未解决的问题及其对 PR 或 MR 的影响。
保持回复简洁，便于快速浏览。仅在评审结论得到处理且团队工作流程允许的情况下，才解决讨论线程。