Back to Details

code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Provide a code review for the given pull request.
Agent assumptions (applies to all agents and subagents):
  • All tools are functional and will work without error. Do not test tools or make exploratory calls. Make sure this is clear to every subagent that is launched.
  • Only call a tool if it is required to complete the task. Every tool call should have a clear purpose.
To do this, follow these steps precisely:
  1. Launch a haiku agent to check if any of the following are true:
    • The pull request is closed
    • The pull request is a draft
    • The pull request does not need code review (e.g. automated PR, trivial change that is obviously correct)
    • Claude has already commented on this PR (check 
      gh pr view <PR> --comments
      for comments left by claude)
    If any condition is true, stop and do not proceed.
Note: Still review Claude generated PR's.
  1. Launch a haiku agent to return a list of file paths (not their contents) for all relevant CLAUDE.md files including:
    • The root CLAUDE.md file, if it exists
    • Any CLAUDE.md files in directories containing files modified by the pull request
  2. Launch a sonnet agent to view the pull request and return a summary of the changes
  3. Launch 4 agents in parallel to independently review the changes. Each agent should return the list of issues, where each issue includes a description and the reason it was flagged (e.g. "CLAUDE.md adherence", "bug"). The agents should do the following:
    Agents 1 + 2: CLAUDE.md compliance sonnet agents Audit changes for CLAUDE.md compliance in parallel. Note: When evaluating CLAUDE.md compliance for a file, you should only consider CLAUDE.md files that share a file path with the file or parents.
    Agent 3: Opus bug agent (parallel subagent with agent 4) Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff.
    Agent 4: Opus bug agent (parallel subagent with agent 3) Look for problems that exist in the introduced code. This could be security issues, incorrect logic, etc. Only look for issues that fall within the changed code.
    CRITICAL: We only want HIGH SIGNAL issues. Flag issues where:
    • The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references)
    • The code will definitely produce wrong results regardless of inputs (clear logic errors)
    • Clear, unambiguous CLAUDE.md violations where you can quote the exact rule being broken
    Do NOT flag:
    • Code style or quality concerns
    • Potential issues that depend on specific inputs or state
    • Subjective suggestions or improvements
    If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time.
    In addition to the above, each subagent should be told the PR title and description. This will help provide context regarding the author's intent.
  4. For each issue found in the previous step by agents 3 and 4, launch parallel subagents to validate the issue. These subagents should get the PR title and description along with a description of the issue. The agent's job is to review the issue to validate that the stated issue is truly an issue with high confidence. For example, if an issue such as "variable is not defined" was flagged, the subagent's job would be to validate that is actually true in the code. Another example would be CLAUDE.md issues. The agent should validate that the CLAUDE.md rule that was violated is scoped for this file and is actually violated. Use Opus subagents for bugs and logic issues, and sonnet agents for CLAUDE.md violations.
  5. Filter out any issues that were not validated in step 5. This step will give us our list of high signal issues for our review.
  6. If issues were found, skip to step 8 to post comments.
    If NO issues were found, post a summary comment using 
    gh pr comment
    (if 
    --comment
    argument is provided): "No issues found. Checked for bugs and CLAUDE.md compliance."
  7. Create a list of all comments that you plan on leaving. This is only for you to make sure you are comfortable with the comments. Do not post this list anywhere.
  8. Post inline comments for each issue using 
    gh pr review
    with inline comments. For each comment:
    • Provide a brief description of the issue
    • For small, self-contained fixes, include a committable suggestion block
    • For larger fixes (6+ lines, structural changes, or changes spanning multiple locations), describe the issue and suggested fix without a suggestion block
    • Never post a committable suggestion UNLESS committing the suggestion fixes the issue entirely. If follow up steps are required, do not leave a committable suggestion.
    IMPORTANT: Only post ONE comment per unique issue. Do not post duplicate comments.
Use this list when evaluating issues in Steps 4 and 5 (these are false positives, do NOT flag):
  • Pre-existing issues
  • Something that appears to be a bug but is actually correct
  • Pedantic nitpicks that a senior engineer would not flag
  • Issues that a linter will catch (do not run the linter to verify)
  • General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in CLAUDE.md
  • Issues mentioned in CLAUDE.md but explicitly silenced in the code (e.g., via a lint ignore comment)
Notes:
  • Use gh CLI to interact with GitHub (e.g., fetch pull requests, create comments). Do not use web fetch.
  • Create a todo list before starting.
  • You must cite and link each issue in inline comments (e.g., if referring to a CLAUDE.md, include a link to it).
  • If no issues are found, post a comment with the following format:
对给定的拉取请求（PR）执行代码评审。
Agent 假设（适用于所有Agent及子Agent）：
  • 所有工具均可正常运行，不会出现错误。请勿测试工具或发起探索性调用。务必告知所有启动的子Agent这条规则。
  • 仅在完成任务需要时调用工具，每次工具调用都要有明确的目的。
请严格遵循以下步骤执行：
  1. 启动一个haiku Agent检查是否满足以下任一条件：
    • 拉取请求已关闭
    • 拉取请求为草稿状态
    • 拉取请求无需代码评审（例如自动化PR、明显正确的微小改动）
    • Claude已经在该PR下发表过评论（执行
      gh pr view <PR> --comments
      查看Claude留下的评论）
    如果任一条件成立，停止后续流程。
注意：Claude生成的PR仍需评审。
  1. 启动一个haiku Agent返回所有相关CLAUDE.md文件的路径列表（不返回文件内容），包括：
    • 根目录的CLAUDE.md文件（如果存在）
    • 所有包含本次PR修改文件的目录下的CLAUDE.md文件
  2. 启动一个sonnet Agent查看拉取请求，返回变更内容摘要
  3. 并行启动4个Agent独立评审变更内容。每个Agent需返回问题列表，每个问题需要包含描述和标记原因（例如「CLAUDE.md合规性」、「bug」）。Agent职责如下：
    Agent 1 + 2：CLAUDE.md合规sonnet Agent 并行审计变更的CLAUDE.md合规性。注意：评估文件的CLAUDE.md合规性时，仅考虑该文件所在路径或父路径下的CLAUDE.md文件。
    Agent 3：Opus bug Agent（与Agent4并行的子Agent） 扫描明显bug，仅关注diff本身，不读取额外上下文。只标记严重bug；忽略吹毛求疵的问题和可能的误报。不要标记需要查看git diff之外上下文才能确认的问题。
    Agent 4：Opus bug Agent（与Agent3并行的子Agent） 查找引入代码中存在的问题，包括安全问题、逻辑错误等，仅查找变更代码范围内的问题。
    重要提示：我们仅需要高置信度的问题。 仅标记满足以下条件的问题：
    • 代码无法编译或解析（语法错误、类型错误、缺少导入、引用未解析）
    • 无论输入是什么，代码一定会产生错误结果（明确的逻辑错误）
    • 明确无歧义的CLAUDE.md违规，可以引用被违反的具体规则
    请勿标记：
    • 代码风格或质量相关的顾虑
    • 依赖特定输入或状态的潜在问题
    • 主观建议或改进方案
    如果不确定问题是否真实存在，不要标记。误报会消耗信任，浪费评审者时间。
    除此之外，每个子Agent都需要知晓PR标题和描述，帮助理解作者的意图。
  4. 针对步骤4中Agent3和4发现的每个问题，并行启动子Agent验证问题。这些子Agent需要获取PR标题、描述以及问题描述，Agent的职责是评审问题，高置信度验证所述问题是否真实存在。例如，如果标记了「变量未定义」的问题，子Agent需要验证代码中是否确实存在该问题。CLAUDE.md相关问题同理，Agent需要验证被违反的CLAUDE.md规则是否适用于该文件，且确实被违反。bug和逻辑问题使用Opus子Agent验证，CLAUDE.md违规使用sonnet子Agent验证。
  5. 过滤掉所有步骤5中未被验证的问题，这一步会得到我们评审用的高置信度问题列表。
  6. 如果发现了问题，跳转到步骤8发表评论。
    如果没有发现问题，使用
    gh pr comment
    发表摘要评论（如果提供了
    --comment
    参数）： "未发现问题。已检查bug和CLAUDE.md合规性。"
  7. 创建你计划发表的所有评论的列表，仅用于你确认评论内容合适，不要将该列表公开发布。
  8. 使用
    gh pr review
    为每个问题发表行内评论。每条评论要求：
    • 简要描述问题
    • 对于小型、独立可修复的问题，包含可直接提交的建议块
    • 对于大型修复（6行以上、结构性变更、跨多处修改），描述问题和建议修复方案，不要提供建议块
    • 永远不要提交可直接提交的建议，除非提交该建议可以完全修复问题。如果需要后续步骤，不要留下可直接提交的建议。
    重要提示：每个唯一问题仅发表一条评论，不要发布重复评论。
步骤4和5中评估问题时参考以下列表，这些属于误报，请勿标记：
  • 预先存在的问题
  • 看起来是bug但实际逻辑正确的内容
  • 资深工程师不会标记的过于吹毛求疵的问题
  • linter可以捕获的问题（不要运行linter验证）
  • 通用代码质量顾虑（例如缺少测试覆盖、通用安全问题）除非CLAUDE.md明确要求
  • CLAUDE.md中提到但代码中明确屏蔽的问题（例如通过lint ignore注释）
注意事项：
  • 使用gh CLI与GitHub交互（例如获取拉取请求、创建评论），不要使用web fetch。
  • 开始前创建待办列表。
  • 行内评论中必须引用并链接每个问题的来源（例如如果提到CLAUDE.md，需要包含指向它的链接）。
  • 如果没有发现问题，按照以下格式发表评论：

Code review

代码评审

No issues found. Checked for bugs and CLAUDE.md compliance.
  • When linking to code in inline comments, follow the following format precisely, otherwise the Markdown preview won't render correctly: 
    https://github.com/OWNER/REPO/blob/FULL_SHA/path/to/file.py#L10-L15
    • Requires full git sha
    • You must provide the full sha. Commands like 
      https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar
      will not work, since your comment will be directly rendered in Markdown.
    • Repo name must match the repo you're code reviewing

    • sign after the file name

    • Line range format is L[start]-L[end]
    • Provide at least 1 line of context before and after, centered on the line you are commenting about (eg. if you are commenting about lines 5-6, you should link to 
      L4-7
      )
未发现问题。已检查bug和CLAUDE.md合规性。
  • 行内评论中链接代码时严格遵循以下格式，否则Markdown预览无法正确渲染：
    https://github.com/OWNER/REPO/blob/FULL_SHA/path/to/file.py#L10-L15
    • 需要完整的git sha
    • 必须提供完整sha，类似
      https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar
      的命令无效，因为你的评论会直接在Markdown中渲染。
    • 仓库名称必须和你正在评审的仓库一致
    • 文件名后加#号
    • 行范围格式为L[起始行]-L[结束行]
    • 提供你评论的行前后至少1行上下文，以评论行为中心（例如如果你评论第5-6行，你应该链接到
      L4-7
      ）