Back to Details

review-diff

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review diff

审查 diff

Reviews always run in subagents: a fresh context, on a different model from the implementer (which is probably you). Each subagent reviews through one lens: a file saying what to look for and how much code to read. You coordinate: scope, lenses, launch, check, triage, fix, report.
Other skills reuse this flow with their own lens set (for example, 
/deep-review
).
审查始终在子 Agent 中运行：使用全新的上下文，并采用与实现者（很可能就是你）不同的模型。 每个子 Agent 通过一个 lens（审查视角）进行审查：该文件说明需要关注什么，以及需要阅读多少代码。 你负责协调：范围、lens、启动、检查、分流、修复和报告。
其他 Skill 也会复用此流程，并使用各自的 lens 集合（例如 
/deep-review
）。

1. Scope

1. 范围

The default change set is the working tree against the current branch's 
HEAD
: 
git diff HEAD
plus untracked files (
git status --short
), which the diff doesn't show. If that's empty (for example, a clean tree on a feature branch), ask the user for the range, such as the merge-base with 
main
. Don't launch reviewers on an empty change set.
Find the originating ticket, task, or plan, if there is one, so lenses that judge against it can.
默认变更集是将工作树与当前分支的 
HEAD
进行比较：
git diff HEAD
，再加上未跟踪文件（
git status --short
），因为 diff 不会显示这些文件。 如果变更集为空（例如，在功能分支上工作树是干净的），请让用户提供比较范围，例如与 
main
的 merge-base。 不要在空变更集上启动 reviewer。
查找原始 ticket、task 或 plan（如果存在），以便需要据此进行判断的 lens 有所依据。

2. Lenses

2. Lenses

Use the lens set the calling skill gives. Otherwise, the standard set, both on the 
strong
tier:
  • lenses/big-picture.md
    : approach, fit, boundaries, consistency, and the originating work.
  • lenses/detail.md
    : logic, edge cases, data flow, small-scale consistency.
Brief reviewers with absolute paths: 
reviewer.md
and the standard lenses live in this skill's directory (
review-diff
's), whichever skill supplies the lens set.
使用调用方 Skill 提供的 lens 集合。否则，使用标准集合，且两者均处于 
strong
层级：
  • lenses/big-picture.md
    ：整体方案、契合度、边界、一致性以及原始工作项。
  • lenses/detail.md
    ：逻辑、边界情况、数据流和小范围一致性。
使用绝对路径向 reviewer 发出简要说明：
reviewer.md
和标准 lenses 位于本 Skill（
review-diff
）的目录中，无论 lens 集合由哪个 Skill 提供。

3. Choose models

3. 选择模型

For each lens on the 
strong
tier:
  • User names models → one reviewer per model.
  • User gives a count → that many reviewers.
  • Otherwise → one reviewer.
Lenses on other tiers get one reviewer each.
Resolve models with the 
/model-tiers
skill: named models as the user named them, the rest from the lens's tier. Reviewer models follow 
/model-tiers
' rules: different from the implementer, distinct per lens.
对于 
strong
层级上的每个 lens：
  • 用户指定模型 → 每个模型安排一名 reviewer。
  • 用户指定数量 → 安排相应数量的 reviewer。
  • 其他情况 → 安排一名 reviewer。
其他层级上的 lens 各安排一名 reviewer。
使用 
/model-tiers
Skill 解析模型：用户指定的模型按用户给出的名称使用，其余模型从 lens 的层级中选择。 Reviewer 模型遵循 
/model-tiers
的规则：不得与实现者相同，并且每个 lens 使用不同的模型。

4. Launch

4. 启动

Launch all reviewers in parallel, in one message, as 
/model-tiers
describes, and wait for their results. Brief each with:
text
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: <ticket/task/plan pointer, or "none">
Point at the files; don't summarise them into the brief.
If a reviewer fails, retry once. If it fails again, continue with the other reviewers' findings and report the failure. If every reviewer fails, report the blocker and stop.
按照 
/model-tiers
的说明，在一条消息中并行启动所有 reviewer，并等待其结果。 向每个 reviewer 发出以下简要说明：
text
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: <ticket/task/plan pointer, or "none">
直接指向这些文件；不要在简要说明中概括它们。
如果某个 reviewer 失败，重试一次。如果再次失败，则继续使用其他 reviewer 的审查结果，并报告该失败。 如果所有 reviewer 都失败，请报告阻塞问题并停止。

5. Check and triage

5. 检查与分流

Merge findings from all reviewers. Merge findings that share a root cause, across lenses. Note where reviewers disagree, especially on design questions.
Check each finding against the code before acting on or reporting it. Drop findings that don't hold, and say why in the report. A fix-now or fix-trivial you can't confirm either way is a design question. Drop other findings you can't confirm.
CategoryAction
fix-nowFix directly.
fix-trivialFix directly when the fix is local and uncontroversial.
design-questionDon't fix. Present to the user with enough context to decide.
informationalMention briefly; no change unless the user asks.
Treat a fix-now as a design question when:
  • another reviewer calls it a design question,
  • it has more than one reasonable remediation, or
  • it changes user-visible behaviour.
Skip fixes that expand scope beyond the reviewed diff, unless the diff introduced the bug.
合并所有 reviewer 的审查结果。对于跨 lens 且根因相同的审查结果，将它们合并。 记录 reviewer 存在分歧之处，尤其是在设计问题上。
在处理或报告每项审查结果之前，先对照代码进行核查。 剔除不成立的审查结果，并在报告中说明原因。 对于归为 fix-now 或 fix-trivial、但无论如何都无法确认的审查结果，将其视为 design-question。 剔除其他无法确认的审查结果。
类别操作
fix-now直接修复。
fix-trivial当修复是局部且无争议时，直接修复。
design-question不修复。向用户说明情况，并提供足够上下文以便用户作出决定。
informational简要提及；除非用户要求，否则不作更改。
出现以下情况时，将 fix-now 视为 design-question：
  • 另一名 reviewer 将其视为 design-question；
  • 它存在一种以上合理的修复方式；或
  • 它会改变用户可见的行为。
不要进行超出已审查 diff 范围的修复，除非该 diff 引入了此 bug。

6. Fix

6. 修复

Apply fix-now and fix-trivial items. Match existing codebase style. Run the project's lint, if known.
Don't re-run the review unless the user asks.
处理 fix-now 和 fix-trivial 项。遵循现有代码库风格。如果已知项目的 lint 命令，请运行它。 除非用户要求，否则不要重新运行审查。

7. Report

7. 报告

  1. Reviewers: lens and model per reviewer, with its finding counts. Group reviewers on the 
    cheap
    tier into one line: their lenses, models, and total findings. Note any fallback: another tier, or a reviewer on the implementer's model.
  2. Fixed: what changed and why; group trivial fixes briefly.
  3. Dropped: findings the check rejected, one line each with the reason.
  4. Design questions: numbered, with the trade-off and each reviewer's view where they disagreed.
  5. Informational: one line, if anything noteworthy remains.
Name the lens each finding came from. If nothing needed fixing and there are no design questions, say so in one sentence.
  1. Reviewers：列出每名 reviewer 使用的 lens 和模型，以及其审查结果数量。 将 
    cheap
    层级上的 reviewer 归为一行：列出它们的 lens、模型及审查结果总数。 说明任何回退情况：改用其他层级，或使用与实现者相同的模型。
  2. 已修复：说明改了什么以及为什么改；将琐碎修复简要归组。
  3. 已剔除：列出核查后被否决的审查结果，每项一行并说明原因。
  4. 设计问题：编号列出，说明取舍，并列出各 reviewer 在存在分歧时的看法。
  5. 信息性事项：如果仍有值得注意的内容，用一行说明。
注明每项审查结果来自哪个 lens。 如果无需修复任何内容，也没有设计问题，请用一句话说明。