review-diff

审查差异

审查始终由子 Agent 执行：使用全新的上下文，并且与实现者（很可能是你）使用不同的模型。 每个子 Agent 只依据一个 视角 进行审查：一份说明要检查什么以及需要阅读多少代码的文件。 由你协调：范围、视角、启动、检查、分流、修复、报告。

其他技能会使用这套流程，但采用各自的视角集（例如 /deep-review）。

1. 范围

默认的变更集是工作树相对于当前分支 HEAD 的差异： git diff HEAD 加上未跟踪文件（git status --short），因为差异中不会显示未跟踪文件。 如果变更集为空（例如，功能分支上的干净工作树）， 请向用户询问范围，例如与 main 的合并基点。 不要针对空的变更集启动审查者。

如果有来源问题、任务或计划，请找出来，以便依据它进行判断的视角能够参考。

2. 视角

使用调用技能提供的视角集。否则，使用标准视角集，且都采用 strong 等级：

• lenses/big-picture.md：方法、契合度、边界、一致性以及相关工作。
• lenses/detail.md：逻辑、边缘情况、数据流和小范围一致性。

向审查者提供绝对路径：reviewer.md 和标准视角文件位于该技能（review-diff）的目录中， 无论视角集由哪个技能提供。

3. 选择模型

对于 strong 等级的每个视角：

• 用户指定模型 → 每个模型安排一名审查者。
• 用户指定人数 → 安排相应数量的审查者。
• 否则 → 安排一名审查者。

其他等级的视角各安排一名审查者。

使用 /model-tiers 技能解析模型：按用户指定的名称使用指定模型，其余模型则从视角的等级中选择。 审查者模型遵循 /model-tiers 的规则：必须与实现者使用的模型不同，并且每个视角使用不同模型。

4. 启动

按照 /model-tiers 的说明，在一条消息中并行启动所有审查者，并等待结果。 向每位审查者提供：

Read and follow <absolute path to review-diff's directory>/reviewer.md.
Lens: <absolute path to the lens file>
Review: <diff command, e.g. git diff HEAD, plus any untracked files by path>
Originating work: <issue/task/plan pointer, or "none">

指出相关文件；不要在说明中概述文件内容。

如果审查者失败，重试一次。如果再次失败，则继续处理其他审查者的发现，并报告此次失败。 如果所有审查者都失败，则报告阻碍并停止。

5. 检查和分流

合并所有审查者的发现。对于根本原因相同的发现，即使来自不同视角，也要合并。 记录审查者之间的分歧，尤其是设计问题上的分歧。

采取行动或报告之前，先对照代码检查每项发现。 剔除不成立的发现，并在报告中说明原因。无法确认的 fix-now 或 fix-trivial 项属于设计问题。 其他无法确认的发现应予以剔除。

类别	操作
fix-now	直接修复。
fix-trivial	如果修复范围局部且没有争议，则直接修复。
design-question	不要修复。向用户提供足够的背景，供其决定。
informational	简要说明；除非用户要求，否则不做更改。

以下情况应将 fix-now 视为设计问题：

• 另一位审查者认为它属于设计问题；
• 它有不止一种合理的修复方式；或
• 它会改变用户可见的行为。

除非差异引入了问题，否则跳过会扩大审查差异范围的修复。

6. 修复

应用 fix-now 和 fix-trivial 项。遵循代码库现有风格。如果已知项目的 lint 命令，则运行它。

除非用户要求，否则不要重新执行审查。

7. 报告

1. 审查者：列出每位审查者使用的视角和模型，以及其发现数量。 将 cheap 层级的审查者归为一行：列出他们的视角、模型和发现总数。 注明任何回退情况：使用了其他层级，或审查者使用了实现者的模型。
2. 已修复：说明修改内容及原因；简要归类琐碎的修复。
3. 已舍弃：逐条列出检查驳回的发现，并说明原因。
4. 设计问题：按编号列出，说明权衡，以及意见不一致时各审查者的观点。
5. 信息性事项：如有值得注意的遗留事项，用一行说明。

注明每项发现来自哪个视角。 如果无需修复且没有设计问题，请用一句话说明。