review-code

审查代码

安全边界

本地代码审查仅限只读和报告发现项。

• 不要编辑文件、暂存更改、提交、推送、创建拉取请求、发布 GitHub 评论或修改审查讨论串。
• 不要运行会写入工作区的格式化工具、生成器、修复工具、安装程序或其他命令。
• 不要读取、要求提供、打印或推断机密信息。
• 不要退而采用同一线程审查。如果无法派发新的审查者，则停止。

范围

1. 使用 gh repo view --json defaultBranchRef --jq .defaultBranchRef.name 或 git rev-parse --abbrev-ref origin/HEAD 确定仓库默认分支。规范化备用结果时，去掉开头的 origin/，使分支名为 main，而非 origin/main。如果两种方式都无法确定默认分支，则停止，并说明需在本技能之外设置 origin/HEAD，例如使用 git remote set-head origin --auto。
2. 使用当前的 origin/<default-branch> 引用。审查期间不要更新引用。使用 git rev-parse --verify origin/<default-branch> 验证本地引用是否存在。当 gh 可用时，使用 gh repo view --json nameWithOwner --jq .nameWithOwner 确定 {owner}/{repo}，然后将本地 SHA 与通过 gh api repos/{owner}/{repo}/branches/{branch} --jq .commit.sha 获取的远程默认分支 SHA 进行比较；如果两者不同，则停止并报告这两个 SHA。当无法检查远程最新状态时，只有在报告中注明无法验证最新状态后，才能继续。
3. 规范化后，使用 git merge-base origin/<default-branch> HEAD 计算审查基准。
4. 审查默认分支的合并基准至当前分支之间的内容，以及已暂存、未暂存和未跟踪的本地更改。包括已删除文件。
5. 审查前加载仓库说明：AGENTS.md、CLAUDE.md（如果存在），以及它们明确导入的文档。
6. 除非仓库说明或差异表明相关，否则将生成文件、锁文件、供应商文件和 dogfood 覆盖路径视为低信号内容。

派发新的审查者

主 Agent 可以确定范围并收集上下文，但实际审查必须由具备全新上下文的审查者执行，运行于新的审查者 Agent 中，或在等效的隔离派发界面中执行，且不得继承实现对话。

如果有主机提供的只读 Explorer 或审查者后台 Agent，应优先使用，因为分支差异审查属于范围明确的代码库问题。

在 Codex 中，如果调用方已请求本地审查、/review-code，或会进入审查关卡的问题工作流，则无需再次征求用户确认，直接启动一个全新的 Explorer 后台 Agent 进行审查。每轮只运行一个审查者——同一未解决轮次绝不重复派发。

审查者的生命周期为：启动、等待、收集并报告结果，然后关闭。在收集到最终报告、超时通知或用户要求的部分结果之前，绝不要关闭；如发生超时或用户要求部分结果，则先收集并报告有用输出，再关闭。启动前，关闭先前已消耗、已取消或已被取代的任何 review-code Explorer、审查者或工作者 Agent，或将其标记为非活动状态；如果主机无法关闭，则标记为非活动或已被取代。可见的 Agent 列表只能显示当前审查状态，不得遗留过时的先前运行 Agent，让用户自行甄别。

仅传递以下内容：

• 仓库路径
• 默认分支、合并基准、HEAD，以及脏文件／未跟踪文件范围
• 更改文件列表和相关差异命令
• 仓库说明
• 本只读审查约定

如果主机运行时无法创建新的审查者或等效的隔离审查界面，则停止并报告隔离不可用。不要要求当前实现对话执行审查。

Reviewer Model

在分派时明确选择审查模型。不要继承宿主的全新上下文原语碰巧采用的默认模型：如果宿主默认使用小模型，就会悄无声息地降低这一质量关卡的标准，而这正是首要的质量控制措施。应要求使用能力足够的模型，并优先选择会话模型或主模型，而不是子 Agent 的默认模型。选择方式应与宿主无关——通过分派界面提供的任何方式进行设置，例如子 Agent 或 Agent 的 model 参数、探索器模型，或 CLI 的 --model 标志。记录审查者实际运行所用的模型，以便在报告中说明，使任何降级都能被发现，而无需检查宿主 UI。

Reviewer Contract

审查者应检查限定范围的差异，找出与合并相关的风险：

• 正确性、安全性、数据丢失、需求契合度、错误处理、测试质量、边缘情况、生产就绪度、清晰度和可维护性
• 对于已更改行为，是否缺少测试或测试是否具有误导性
• 是否与仓库说明或问题验收标准不一致

按严重程度对发现进行分组：阻断性、非阻断性和低严重性。每项发现都必须包含文件和行号引用、原因以及建议的修复方案。报告中不要加入过多赞扬性的评论。如果没有发现问题，应明确说明，并指出剩余风险或测试缺口。

与托管审查的区别

review-code 是用于发现分支差异问题的本地隔离审查工具。它不会模拟 code-review.yml，不要求 PR 编号，也不会发布评论。托管审查工作流使用各自的提示词、权限和 PR 评论约定。

报告

• 使用的 base、head 和默认分支
• 本地默认分支引用的新鲜度检查，或说明为何无法验证新鲜度（例如：新鲜度未验证：gh 不可用；仅审查了当前的 origin/main）
• 已更改文件，包括暂存、未暂存和未跟踪的文件
• 新的审查者分派机制，或停止原因
• 审查实际运行所用的模型
• 按严重程度分组的发现
• 因信号较弱而跳过或审查的路径及理由