code-review

对给定的拉取请求进行代码审查。

Agent 假设（适用于所有 Agent 和子 Agent）：

• 所有工具都能正常工作，不会出错。不要测试工具或进行探索性调用。确保明确告知每个已启动的子 Agent。
• 只有在完成任务确有需要时才调用工具。每次工具调用都应有明确目的。

为此，请严格按以下步骤操作：

1. 启动一个 haiku Agent，检查以下任一情况是否成立：

   • 拉取请求已关闭
   • 拉取请求是草稿
   • 拉取请求不需要代码审查（例如自动生成的拉取请求，或显然正确的简单改动）
   • Claude 已经对此拉取请求发表评论（使用 gh pr view <PR> --comments 检查 Claude 留下的评论）

   如果任一情况成立，则停止，不要继续。

注意：仍需审查 Claude 生成的拉取请求。

2. 启动一个 haiku Agent，返回所有相关 CLAUDE.md 文件的路径列表（而非文件内容），包括：

   • 根目录下的 CLAUDE.md 文件（如果存在）
   • 拉取请求修改的文件所在目录中的任何 CLAUDE.md 文件

3. 启动一个 sonnet Agent，查看拉取请求并返回变更摘要

4. 并行启动 4 个 Agent，独立审查变更。每个 Agent 都应返回问题列表，其中每个问题包含描述和标记原因（例如“遵循 CLAUDE.md 要求”“缺陷”）。各 Agent 的任务如下：

   Agent 1 + 2：CLAUDE.md 合规性审查 sonnet Agent 并行审查变更是否符合 CLAUDE.md 要求。注意：评估某个文件是否符合 CLAUDE.md 要求时，只考虑路径与该文件相同或位于其父目录中的 CLAUDE.md 文件。

   Agent 3：Opus 缺陷审查 Agent（与 Agent 4 并行运行） 扫描明显缺陷。只关注差异本身，不要阅读额外上下文。只标记重大缺陷；忽略小问题和可能的误报。不要标记无法通过查看 git diff 以外的上下文来确认的问题。

   Agent 4：Opus 缺陷审查 Agent（与 Agent 3 并行运行） 查找新增代码中的问题，包括安全问题、逻辑错误等。只关注变更涉及的代码。

   重要：我们只需要高可信度的问题。 仅标记符合以下情况的问题：

   • 代码无法编译或解析（语法错误、类型错误、缺少导入、未解析的引用）
   • 无论输入是什么，代码都会明确地产生错误结果（明显的逻辑错误）
   • 明确无歧义地违反 CLAUDE.md 要求，且能引用被违反的具体规则

   不要标记：

   • 代码风格或质量方面的问题
   • 取决于特定输入或状态的潜在问题
   • 主观建议或改进意见

   如果不能确定问题确实存在，就不要标记。误报会损害信任，也会浪费审查者的时间。

   此外，还要告知每个子 Agent 拉取请求的标题和描述，以便提供作者意图的上下文。

5. 对于第 4 步中 Agent 3 和 4 发现的每个问题，并行启动子 Agent 验证该问题。这些子 Agent 应获得拉取请求的标题和描述，以及问题描述。子 Agent 的任务是高置信度地核实所述问题确实存在。例如，如果标记的问题是“变量未定义”，子 Agent 应核实代码中该变量确实未定义。对于 CLAUDE.md 相关问题，子 Agent 应核实被违反的规则适用于该文件，且确实遭到了违反。缺陷和逻辑问题使用 Opus 子 Agent；CLAUDE.md 违规使用 sonnet Agent。

6. 过滤掉第 5 步中未通过验证的问题。此步骤将得到本次审查的高可信度问题列表。

7. 如果发现问题，跳到第 8 步发布评论。 如果未发现任何问题，使用 gh pr comment 发布摘要评论（如果提供了 --comment 参数）： "未发现任何问题。已检查错误和 CLAUDE.md 合规性。"

8. 列出你计划发布的所有评论。这仅供你确认自己认可这些评论。不要在任何地方发布此列表。

9. 使用 gh pr review 发布每个问题的行内评论。每条评论：

   • 简要说明问题
   • 对于小型、自成一体的修复，提供可提交的建议代码块
   • 对于较大的修复（6 行以上、结构性更改或涉及多个位置的更改），说明问题和建议的修复方式，不提供建议代码块
   • 除非提交该建议后问题就能彻底解决，否则绝不要发布可提交的建议。如果还需要后续步骤，就不要留下可提交的建议。

   重要：每个独特问题只能发布一条评论。不要重复评论。

评估第 4 步和第 5 步中的问题时，请使用以下列表（这些属于误报，不要标记）：

• 已存在的问题
• 看起来像是错误、但实际上正确的内容
• 资深工程师不会指出的吹毛求疵
• Linter 会检测到的问题（不要运行 Linter 进行验证）
• 一般代码质量问题（例如，缺少测试覆盖率、一般性安全问题），除非 CLAUDE.md 明确要求
• CLAUDE.md 中提及但在代码中明确被忽略的问题（例如，通过 Lint 忽略注释）

注意：

• 使用 gh CLI 与 GitHub 交互（例如，获取拉取请求、发布评论）。不要使用网页抓取。
• 开始前创建待办事项列表。
• 必须在行内评论中引用并链接每个问题（例如，提及 CLAUDE.md 时，请附上它的链接）。
• 如果未发现问题，请按以下格式发布评论：

---

代码审查

未发现任何问题。已检查错误和 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[start]-L[end]。
  • 至少提供被评论代码行的前后一行上下文，并以该行居中（例如，如果评论第 5–6 行，应链接到 L4-7）。