Back to Details

changes-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Changes Review

代码变更审查

Attack a change from several directions at once and report what survives. This skill finds; it never fixes, never runs tooling, and never touches the working tree. It does not post anywhere unless the caller asks, and then only through the gate in Phase 8.
It is a primitive. Whoever calls it — a person, a PR workflow, an issue workflow — gets the same three stages, find, verify, synthesize, and configures them rather than forking the behavior. Anything needing the pull request itself, the project's architecture, or a round loop belongs to the caller, not here.
从多个维度同时审查代码变更，报告经检验后留存的问题。本skill仅负责发现问题；绝不修复问题、不调用工具、不修改工作目录。除非调用者要求，否则不会在任何地方发布内容，且发布需经过第8阶段的验证关卡。
这是一个基础组件。无论是个人、PR工作流还是Issue工作流调用它，都会得到相同的三个阶段：发现、验证、整合，且可对这些阶段进行配置，无需修改核心逻辑。任何需要直接操作Pull Request、项目架构或循环迭代的工作，都由调用者负责，而非本skill。

The premise

核心前提

The agent that wrote the code wants it accepted. A reviewer that shares its context inherits its blind spots — it reads the implementer's reasoning, finds it persuasive, and confirms the work. So every reviewer is dispatched cold to the implementer's reasoning: no plan, no rationale, no commit message body, no prior-round findings, no account of why the change looks the way it does.
The bugs this catches are the ones that compile and pass lint — premature drops, floor-vs-truncate on negative numbers, eager evaluation where laziness was meant. Tooling cannot see them and a context-rich reviewer rationalizes them away.
Conventions and cleanup are not this skill's job. A reviewer told to find bugs and tidy the code softens into a quality reviewer and stops finding bugs. Style, naming, comment noise, and convention drift belong to a cleanup pass, and this skill will not report them.
编写代码的Agent希望代码被接受。如果审查者与Agent共享上下文，就会继承其思维盲区——审查者会认同实现者的思路，认为其合理，进而确认工作无误。因此，每位审查者都在完全不了解实现者思路的情况下被调度：看不到实现计划、设计 rationale、提交消息正文、之前的审查结果，也不知道变更为何是当前的样子。
本skill能发现的是那些可以编译通过且通过lint检查的缺陷——比如提前终止逻辑、负数处理时的取整错误、本该延迟求值却提前执行的情况。工具无法发现这些问题，而了解上下文的审查者会将其合理化，从而忽略这些缺陷。
代码规范整理不属于本skill的职责。如果要求审查者同时查找缺陷和整理代码，审查者会变成质量优化人员，从而停止查找缺陷。代码风格、命名、注释冗余、规范偏离等问题属于代码清理环节，本skill不会报告这些内容。

Configuration

配置项

SettingFlagDefault
Scope
--base <branch>
/ 
--uncommitted
/ 
--commit <sha>
Uncommitted changes; the last commit when the tree is clean
Requirement
--issue <N>
Auto-detected (Phase 2)
Mode
--mode <simple|standard|deep>
standard
for 
--base
, 
simple
for a single commit or an uncommitted diff
External reviewer
--no-external
On whenever a third-party CLI is available
Stack lenses
--no-lens
On whenever the diff matches a lens (Phase 3)
Publication
--comment
/ 
--review
Off — report to the caller and stop (Phase 8)
Mode is the one dial. It sets how many reviewers run and how hard the findings get verified, because those two scale together — there is no useful run with four reviewers and no verification.
ModeReviewersVerification
simple
2 — cold and intent; the external leg is dropped first, since it is the one that cannot read the repo
reachability
only
standard
3 — cold, intent, externalall three lenses
deep
4 — two cold on different models, intent, externalall three lenses, the killed claims too, and a synthesis critic on the assembled report
With no requirement resolved, 
simple
is one reviewer, 
standard
is two and 
deep
is three — the intent reviewer needs something to check against. Verification always runs; the mode sets its depth, not whether it happens, and it roughly doubles the run, which is why the default follows the scope.
A late round in a fix loop is a 
simple
run over the fix: small diff, spec settled two rounds ago, and reachability is the lens that still changes the outcome. A whole branch reviewed cold is 
standard
. 
deep
is for a large change or a high cost of missing something — two cold reviewers on different models diverge usefully, where a second intent reviewer mostly repeats the first.
Every rule here that reads as arbitrary has an observation behind it, recorded with its outcome in 
references/calibration.md
. Read that before loosening one.
Two things only a calling skill can supply:
  • System facts. Who can execute code in this system, what is already privileged, which surfaces are deprecated or unsupported. A caller that knows the platform should say so. These facts reach only the reachability verifier — never a finder, which stays cold. Without them the verifier works out what it can from the repo.
  • The requirement, when the caller already resolved it. Pass the issue text, not a summary of it, and never the implementer's account of the diff.
A caller must not pass a plan, a rationale, a previous round's findings, or a description of what the change is trying to do. Those defeat the premise, and this skill cannot detect that it happened.
Round loops belong to the caller. This skill reviews once and stops. A caller looping should pass the fix itself as the scope on rounds after the first — the snapshot commit, or 
--base
against it — rather than re-reviewing a whole branch to check a two-line change. It also has to keep its own list of findings it consciously accepted: reviewers here are blind to previous rounds by design, so an accepted decision is found again every round and only the caller can recognize it.
设置项命令行参数默认值
审查范围
--base <branch>
/ 
--uncommitted
/ 
--commit <sha>
未提交的变更；若工作目录干净，则为最后一次提交
需求来源
--issue <N>
自动检测（第2阶段）
审查模式
--mode <simple|standard|deep>
使用
--base
时默认
standard
；针对单个提交或未提交差异时默认
simple
外部审查者
--no-external
只要有第三方CLI可用就启用
栈专属审查透镜
--no-lens
当差异匹配对应透镜时启用（第3阶段）
发布方式
--comment
/ 
--review
关闭——仅向调用者返回报告后停止（第8阶段）
审查模式是核心调节项。它决定了运行的审查者数量以及对发现问题的验证深度，因为这两者是成正比的——如果有四位审查者但没有验证环节，这样的审查是没有意义的。
模式审查者数量验证深度
simple
2位——无上下文审查者和需求匹配审查者；优先取消外部审查者，因为它无法读取仓库内容仅启用
reachability
验证透镜
standard
3位——无上下文审查者、需求匹配审查者、外部审查者启用全部三个验证透镜
deep
4位——两位使用不同模型的无上下文审查者、需求匹配审查者、外部审查者启用全部三个验证透镜，对已排除的问题也进行验证，且对整合后的报告进行批判性审查
如果未找到需求来源，
simple
模式仅运行1位审查者，
standard
模式运行2位，
deep
模式运行3位——需求匹配审查者需要对照的需求内容。验证环节始终会运行；模式决定的是验证深度，而非是否运行验证，验证环节大约会使整体运行时间翻倍，这也是默认模式会根据审查范围调整的原因。
修复循环中的后期阶段适合对修复内容运行
simple
模式：差异小、需求已在之前的迭代中确定，而
reachability
透镜仍能影响审查结果。对整个分支进行无上下文审查适合用
standard
模式。
deep
模式适用于大型变更或遗漏缺陷代价极高的场景——两位使用不同模型的无上下文审查者会产生有价值的差异化发现，而第二位需求匹配审查者大多会重复第一位的结果。
这里看似随意的规则背后都有实际观察依据，相关记录和结果可查看
references/calibration.md
。在修改规则前请先阅读该文档。
只有调用者能提供以下两项内容：
  • 系统事实：谁能在该系统中执行代码、哪些权限已存在、哪些接口已被弃用或不再支持。了解平台的调用者应提供这些信息。这些事实仅会传递给reachability验证透镜——绝不会传递给任何发现环节的审查者，以保持其无上下文状态。如果没有这些事实，验证透镜会从仓库中自行推断。
  • 需求内容：当调用者已确定需求时。需传递Issue的完整文本，而非摘要，且绝不能传递实现者对差异的说明。
调用者不得传递实现计划、设计rationale、之前的审查结果或变更意图描述。这些内容会破坏核心前提，且本skill无法检测到此类情况。
循环迭代由调用者负责。本skill仅进行一次审查就会停止。调用者若需要循环迭代，应在后续轮次中将修复内容本身作为审查范围——比如快照提交，或使用
--base
对比该提交——而非重新审查整个分支来检查两行代码的变更。调用者还需自行记录已确认接受的问题：由于本skill的审查者设计为对之前的迭代无感知，已接受的问题会在每一轮审查中被再次发现，只有调用者能识别这些问题。

Phase 1: Resolve scope

第1阶段：确定审查范围

Resolve the diff and the file list once, up front. Every reviewer sees the identical change set.
bash
git diff --name-only HEAD                    # tracked modifications
git ls-files --others --exclude-standard     # new untracked files
Filter out 
*-lock.*
, 
dist/
, 
build/
, 
.next/
, 
*.min.js
, 
*.map
, 
*.d.ts
.
Trivial diffs — only version bumps, lock files, or formatting that moved no non-whitespace token → print 
Trivial changes only. Nothing to attack.
and stop. Do not spend reviewers on them. A reformat that moved a token is not formatting: a reflowed ternary, or a 
return
that ended up inside a different branch, gets reviewed like any other change.
Dirty tree under 
--base
. 
git diff <base>...HEAD
excludes uncommitted work, so a dirty tree means the reviewers judge a change set that is not what exists on disk. Say so and review 
<base>...HEAD
plus the uncommitted diff together, or ask the caller to commit first.
Announce the resolved scope in one line: 
Attacking 6 files, 240 lines (base: master).
Do not read the project's architecture here. Establishing how the system is built is another skill's job, and doing it in this phase would leak into the finders.
提前一次性确定差异内容和文件列表。每位审查者都会看到完全相同的变更集。
bash
git diff --name-only HEAD                    # 已跟踪文件的修改
git ls-files --others --exclude-standard     # 新的未跟踪文件
过滤掉
*-lock.*
、
dist/
、
build/
、
.next/
、
*.min.js
、
*.map
、
*.d.ts
文件。
微小差异——仅包含版本升级、锁文件变更，或未移动任何非空白字符的格式调整→输出
仅存在微小变更，无需审查。
并停止。不要为这类内容消耗审查资源。如果格式调整移动了代码标记（比如重排的三元表达式，或
return
语句被移到了不同分支中），则不属于单纯的格式调整，需像其他变更一样进行审查。
使用
--base
时工作目录不干净。
git diff <base>...HEAD
会排除未提交的工作内容，因此工作目录不干净意味着审查者评估的变更集与磁盘上的实际内容不符。需告知调用者，并将
<base>...HEAD
的差异与未提交的差异合并审查，或要求调用者先提交变更。
用一行文字宣布确定的审查范围：
正在审查6个文件，共240行代码（基准分支：master）。
本阶段不要读取项目架构。确定系统构建方式是其他skill的工作，若在本阶段读取会将上下文泄露给发现环节的审查者。

Phase 2: Resolve the requirement

第2阶段：确定需求来源

The intent reviewer uses this, and so does the 
spec
verification lens in Phase 5. Resolve it once here, before dispatch, and hold the text for the whole run — the lens must not re-fetch it:
  1. --issue <N>
    was passed → 
    gh issue view <N> --json title,body
  2. Current branch matches 
    issue-<N>
    → same, with that number
  3. An open PR exists for the branch → 
    gh pr view --json title,body,closingIssuesReferences
    and take the linked issue's body; the PR description only under the rule below
  4. Last commit message contains 
    #<N>
    → same, with that number
Take the issue description only. Exclude comments the agent itself posted during this run — they are the implementer's reasoning wearing a different hat.
A pull request body is not a requirement when an agent wrote it. In this repo's own workflows the implementer writes it, which makes it an account of the diff — the one thing no reviewer may see. Use it only when a human authored it and it reads as a request rather than a summary of the change. Otherwise fall through to step 4, and if nothing resolves print the no-requirement line instead.
If nothing resolves, print 
No requirement found — running the cold reviewer only.
and skip the intent reviewer. Do not invent a requirement from the diff; a reviewer checking a change against a requirement inferred from that same change finds nothing.
需求匹配审查者和第5阶段的
spec
验证透镜会用到需求内容。本阶段需提前一次性确定需求内容，并在整个审查过程中保留该文本——验证透镜不得重新获取需求内容：
  1. 若传递了
    --issue <N>
    →调用
    gh issue view <N> --json title,body
    获取内容
  2. 当前分支名称匹配
    issue-<N>
    →同上，使用该编号
  3. 该分支存在已打开的PR→调用
    gh pr view --json title,body,closingIssuesReferences
    并获取关联Issue的内容；仅在符合以下规则时才使用PR描述
  4. 最后一次提交消息包含
    #<N>
    →同上，使用该编号
仅提取Issue的描述内容。排除本次审查过程中Agent自身发布的评论——这些内容是实现者思路的另一种体现。
当Agent编写PR正文时，PR正文不能作为需求来源。在本仓库的工作流中，实现者编写PR正文，这使其成为对差异的说明——而这正是审查者绝对不能看到的内容。仅当PR正文由人类编写且明确是需求请求而非变更摘要时，才使用它。否则进入步骤4，如果仍无法确定需求来源，则输出无需求提示。
如果无法确定需求来源，输出
未找到需求来源——仅运行无上下文审查者。
并跳过需求匹配审查者。不得从差异中推断需求内容；如果审查者对照从同一变更中推断出的需求进行检查，将无法发现任何问题。

Phase 3: Dispatch reviewers

第3阶段：调度审查者

Launch every reviewer at once so they run concurrently. They must not see each other's output. Do not summarize the change for them, do not explain what it is trying to do, and do not pass along anything from a previous round.
Choosing models, stated as intent rather than as names, since the roster changes and each host names its own:
  • Give each reviewer the most capable model the host offers. If that is the model running this skill, take the next tier down — a reviewer on the orchestrator's own model shares whatever the orchestrator already believes about this change.
  • Where the host lets you pick a model per reviewer, give each a different one. Same-model reviewers differ only by sampling; same-role reviewers only by phrasing. Where it does not, run the default and say so: role diversity survives that, model diversity does not.
On a host with no subagents, run each prompt in turn and never show one reviewer another's output. Say in the report that they were not isolated — a sequential run leaks earlier findings into later ones.
同时启动所有审查者，使其并行运行。审查者之间不得看到彼此的输出。不得为审查者总结变更内容、解释变更意图，也不得传递任何之前迭代的内容。
模型选择需遵循以下意图（而非具体名称，因为模型列表会变化，且每个宿主都有自己的命名方式）：
  • 为每位审查者分配宿主提供的最强大模型。如果该模型正是运行本skill的模型，则选择次一级的模型——使用与编排器相同模型的审查者会继承编排器对该变更的既有认知。
  • 如果宿主允许为每位审查者选择不同模型，为每位审查者分配不同的模型。使用相同模型的审查者仅在采样上有差异；相同角色的审查者仅在表述上有差异。如果宿主不支持，则使用默认模型并在报告中说明：角色多样性不受影响，但模型多样性无法实现。
如果宿主没有子Agent，则依次运行每个提示，且绝不向一位审查者展示另一位的输出。需在报告中说明审查者未被隔离——顺序运行会将早期发现泄露给后续审查者。

Reviewer 1 — cold (always)

审查者1——无上下文审查者（始终运行）

Dispatch a reviewer that hunts correctness bugs and returns findings in the shape its prompt specifies. Prompt: the contents of 
references/cold-reviewer-prompt.md
, then the diff.
Repo-aware and issue-blind: it may read callers, types, and tests, but the prompt forbids fetching the issue or PR. That prohibition is a soft guard, not a sandbox. It holds in practice because the reviewer is never handed an issue number and has no reason to hunt for one. Do not put the issue number in its prompt, not even in passing.
调度一位查找正确性缺陷的审查者，并使其按照指定格式返回发现结果。提示内容：
references/cold-reviewer-prompt.md
的内容，随后附上差异内容。
该审查者了解仓库但不了解Issue：可以读取调用逻辑、类型定义和测试代码，但提示禁止其获取Issue或PR内容。这是一个软性限制，而非沙箱隔离。在实践中，由于从未向审查者提供Issue编号，且没有理由去查找，因此该限制会生效。不要在提示中加入Issue编号，哪怕是顺带提及。

Reviewer 2 — intent (whenever a requirement resolved)

审查者2——需求匹配审查者（找到需求来源时运行）

Dispatch a reviewer that hunts requirement gaps and returns findings in the shape its prompt specifies. Prompt: 
references/intent-reviewer-prompt.md
with 
{{REQUIREMENT}}
replaced by the resolved issue title and body, then the diff.
调度一位查找需求缺口的审查者，并使其按照指定格式返回发现结果。提示内容：将
references/intent-reviewer-prompt.md
中的
{{REQUIREMENT}}
替换为已确定的Issue标题和正文，随后附上差异内容。

Reviewer 3 — second cold (
deep
mode only)

审查者3——第二位无上下文审查者（仅
deep
模式运行）

The same cold prompt on a different model. Two cold reviewers on different models produce meaningfully different findings; a second intent reviewer largely duplicates the first, so depth is bought with another bug hunter, never another requirement checker.
使用不同模型运行相同的无上下文提示。两位使用不同模型的无上下文审查者会产生有意义的差异化发现；而第二位需求匹配审查者大多会重复第一位的结果，因此深度审查需增加一位缺陷查找者，而非需求检查者。

External reviewer (
standard
and 
deep
, when available, unless 
--no-external
)

外部审查者（
standard
和
deep
模式，可用时运行，除非使用
--no-external
）

A model family outside this process entirely, via a CLI.
Invoke it through the collection's external-agent skill, 
/outsider
, rather than calling a script by path — a repo-relative path resolves only inside one checkout. That skill picks an installed agent CLI that is not the host running this skill, so the reviewer is both a different model family and a different process. The leg is optional: with no external agent available the run continues without it and the report says so.
Tell 
/outsider
to run review mode and pass it exactly three things:
  • --host <the agent you are>
    , so it does not select the host and review its own work
  • the scope this run resolved in Phase 1, as the matching scope flag — 
    --uncommitted
    , 
    --base <branch>
    , or 
    --commit <sha>
    . A different scope means Phase 4 dedupes two different change sets, which is worse than skipping this reviewer
  • a timeout of 
    540
    , with the surrounding command timeout set to its maximum
Do not retry, and never block on it. A missing CLI is a skipped leg, not a failed run: the skill reports why and exits cleanly, and the report notes the reviewer was unavailable.
This leg only ever gets a piped diff, so it is structurally cold — good at internal contradictions in the diff, prone to asking for context it cannot see. Never upgrade its confidence to match a native reviewer's.
It is the one reviewer with no output contract you control. Map each finding onto the fields the native reviewers return: claim, location, actor, severity, confidence, defect, cases. Missing severity or confidence becomes 
moderate
/ 
low
; a missing actor is resolved in Phase 6, not guessed here.
完全在本流程之外的模型家族，通过CLI调用。
通过集合中的外部Agent skill 
/outsider
调用，而非直接按路径调用脚本——相对路径仅在单个检出目录中有效。该skill会选择一个已安装的、非当前运行本skill的Agent CLI，因此审查者既属于不同的模型家族，也属于不同的进程。该环节是可选的：如果没有可用的外部Agent，审查会继续进行，且报告中会说明情况。
告知
/outsider
运行review模式，并向其传递以下三项内容：
  • --host <当前运行的Agent>
    ，使其不会选择当前宿主并审查自身工作
  • 第1阶段确定的审查范围，使用对应的范围参数——
    --uncommitted
    、
    --base <branch>
    或
    --commit <sha>
    。如果范围不同，第4阶段会对两个不同的变更集进行去重，这比跳过该审查者更糟糕
  • 超时时间
    540
    ，并将周围命令的超时时间设置为最大值
不要重试，且绝不等待该审查者完成。如果CLI缺失，则跳过该环节，而非视为运行失败：skill会报告原因并正常退出，且报告中会注明该审查者不可用。
该环节仅会接收管道传递的差异内容，因此本质上是无上下文的——擅长发现差异中的内部矛盾，但可能会请求无法获取的上下文。不要将其置信度提升至与原生审查者相同的水平。
这是唯一不受你控制输出格式的审查者。需将其返回的每个发现映射为原生审查者使用的字段：claim、location、actor、severity、confidence、defect、cases。缺失的severity或confidence默认设为
moderate
/
low
；缺失的actor在第6阶段确定，而非在此猜测。

Stack lenses (when the diff matches, unless 
--no-lens
)

栈专属审查透镜（差异匹配时运行，除非使用
--no-lens
）

The reviewers above are stack-agnostic on purpose. A lens adds the one thing they cannot carry: a catalog of failure modes specific to a library, deep enough that it would drown a general prompt.
Match the resolved file list against this table and dispatch a lens for each row that hits:
Diff containsLens
.tsx
/ 
.jsx
, or 
.ts
importing 
react
audit:react-audit
files importing 
three
or 
@react-three/*
audit:three-audit
Invoke the lens skill by name, the same way the external leg goes through 
/outsider
, and tell it four things: that it is running in lens mode, the exact files Phase 1 resolved, the base ref when the scope has one, and the fields to return — claim, location, actor, severity, confidence, defect, cases. Both lens skills return whatever shape the caller asks for, so a lens nobody asks returns its own tally on its own scale, and Phase 4 gets no actor or confidence to work with. A lens must not widen its own scope — a lens that audits the whole project returns findings this run cannot attribute to the change.
Map what comes back onto the finding contract the native reviewers use. A lens rates its own findings by its own catalog, so re-rate them here rather than trusting the labels: a lens finding is 
minor
unless it names a concrete failure this diff can produce, and anything the lens calls a convention violation is 
minor
with no exceptions — that is cleanup, and 
review:code-cleanup
owns it.
Lenses are optional in the same way the external reviewer is. A lens skill that is not installed is a skipped leg, never a failed run, and the report says which lenses ran.
上述审查者故意设计为与技术栈无关。透镜会添加一项他们无法具备的能力：针对特定库的故障模式目录，内容足够深入，若加入通用提示会导致信息过载。
将确定的文件列表与下表匹配，并为每个匹配项调度对应的透镜：
差异包含透镜
.tsx
/ 
.jsx
，或导入
react
的
.ts
文件
audit:react-audit
导入
three
或
@react-three/*
的文件
audit:three-audit
按名称调用透镜skill，方式与外部环节调用
/outsider
相同，并告知其四项内容：运行在lens mode、第1阶段确定的具体文件、审查范围包含基准分支时的基准引用、需要返回的字段——claim、location、actor、severity、confidence、defect、cases。两个透镜skill都会返回调用者要求的格式，因此如果未指定返回字段，透镜会返回自己的统计结果和评分标准，第4阶段将无法获取actor或confidence字段。透镜不得扩大自身审查范围——审查整个项目的透镜会返回无法归因于本次变更的发现结果。
将返回结果映射为原生审查者使用的发现格式。透镜会根据自身目录为发现结果评分，因此需在此重新评分，而非信任原标签：除非透镜指出本次变更会导致具体故障，否则透镜发现的问题为
minor
；透镜标记为规范违反的任何内容都属于
minor
，无例外——这属于代码清理，由
review:code-cleanup
负责。
透镜与外部审查者一样是可选的。如果未安装对应的透镜skill，则跳过该环节，而非视为运行失败，且报告中会说明运行了哪些透镜。

Phase 4: Consolidate

第4阶段：整合发现结果

Reviewers over-report, over-rate, and file one insight three times. Cut that down before spending anything on verification.
  1. Kill non-findings. No concrete failure — inputs or state leading to a named wrong result — is a worry, not a finding. Same for an intent finding with no quotable requirement clause.
  2. Kill unproven halves. A finding pairing a demonstrated claim with one nobody could demonstrate ships as the demonstrated claim alone — the weakest claim sets the credibility of the whole finding.
  3. Dedupe. Two reviewers hitting the same 
    file:line
    with the same claim is one finding at the higher severity and confidence. Independent corroboration is a strong signal — say so, and never let it look like two problems.
  4. Cluster by root cause. Ask whether one structural change would fix two or more findings. If so, report the root and nest its symptoms beneath it; filed separately, both are understated.
Keep what you killed. Verification rules on the drops too, and a drop confirmed is worth more than a drop assumed.
审查者会过度报告、过度评分，且同一洞见会被多次提交。在投入资源进行验证前，需先精简这些结果。
  1. 排除非有效发现。没有具体故障场景——即能导致明确错误结果的输入或状态——的内容只是担忧，而非有效发现。同样，没有可引用需求条款的需求匹配发现也需排除。
  2. 排除未验证的部分。如果一个发现包含已验证的结论和无法验证的部分，仅保留已验证的结论——最弱的结论决定了整个发现的可信度。
  3. 去重。两位审查者在同一
    file:line
    发现相同问题，合并为一个发现，并取较高的严重程度和置信度。独立佐证是强烈的信号——需在报告中说明，且绝不能让其看起来是两个问题。
  4. 按根本原因聚类。判断是否可以通过一个结构性变更修复两个或多个发现。如果可以，则报告根本原因，并将症状作为子项嵌套在其下；如果单独提交，每个问题的严重性都会被低估。
保留被排除的内容。验证环节也会针对被排除的内容进行检查，确认排除的内容比假设排除的更有价值。

Phase 5: Verify

第5阶段：验证发现结果

Takes the consolidated findings and is dispatched like any other reviewer — all lenses at once, none seeing another. The mode decides which lenses run: 
reachability
alone in 
simple
, all three otherwise.
Lenses come from 
references/verification-prompt.md
. Fill all four placeholders before dispatch: 
{{LENS}}
the lens name, 
{{FINDINGS}}
the consolidated findings including the ones you killed, 
{{DIFF}}
the change set Phase 1 resolved, and 
{{SYSTEM_FACTS}}
the caller's system facts or 
None supplied.
when there are none. Substitute globally — 
{{SYSTEM_FACTS}}
sits inside the reachability section, so filling every copy still satisfies the rule that those facts reach only that lens.
LensQuestionMay do
mechanism
Does the code actually do this?Read the repo, compile, run probes
reachability
Who triggers it, and does the consequence follow?Read the repo; receives the caller's system facts
spec
Is the quoted requirement real, and did this diff cause it?Read the requirement and 
git log
Every lens is told to default to refuting when it cannot demonstrate a claim. Pass the claims you killed in Phase 4 as well, marked as dropped — a verifier confirming a drop is cheap, and it sometimes corrects the reason.
One extra job for the 
mechanism
lens whenever the change ships its own test, story, or fixture: check that the artifact exercises the path it claims to guard. A fixture that quietly supplies the missing precondition is worse than no fixture — it turns an open question into a passing check.
Merge rule. A finding dies when 
mechanism
refutes it, when 
reachability
cannot name an actor who reaches it, or when 
spec
kills it. Nothing else removes a finding. Where a lens returns 
narrowed
, keep only the part it says survives.
Severity is then whatever the lenses justify — take 
reachability
's rating when it named an actor, since that is the actor-aware one, and 
mechanism
's otherwise. Verification is not a downgrade pass. A finding that came in reasoned and goes out demonstrated should come out sharper: higher confidence, and higher severity where the demonstration widened it. A verify phase whose ratings only ever fall is miscalibrated.
Verify the reasoned ones hardest. Every finding killed in verification across both calibration runs was established by reading; none established by execution was killed or downgraded. Sort the queue accordingly: reasoning-only findings first, then anything a reviewer rated low confidence.
接收整合后的发现结果，并像调度其他审查者一样调度验证透镜——所有透镜同时运行，彼此看不到对方的输出。模式决定了运行哪些透镜：
simple
模式仅运行
reachability
，其他模式运行全部三个透镜。
透镜内容来自
references/verification-prompt.md
。调度前需填充所有四个占位符：
{{LENS}}
为透镜名称，
{{FINDINGS}}
为整合后的发现结果（包括被排除的内容），
{{DIFF}}
为第1阶段确定的变更集，
{{SYSTEM_FACTS}}
为调用者提供的系统事实，若无则为
None supplied.
。全局替换占位符——
{{SYSTEM_FACTS}}
位于reachability部分，因此替换所有副本仍符合仅将这些事实传递给该透镜的规则。
透镜核心问题允许操作
mechanism
代码是否真的存在该问题？读取仓库内容、编译、运行探测代码
reachability
谁会触发该问题，后果是否会发生？读取仓库内容；接收调用者提供的系统事实
spec
引用的需求是否真实，该差异是否导致了需求缺口？读取需求内容和
git log
每个透镜都被告知无法验证时默认否定。将第4阶段排除的结论也传递给透镜，并标记为已排除——验证环节确认排除的成本很低，且有时会纠正排除的原因。
当变更包含自身的测试、story或fixture时，
mechanism
透镜需额外完成一项工作：检查该产物是否真的覆盖了它声称要防护的路径。如果fixture悄悄补充了缺失的前置条件，还不如没有fixture——它会将一个悬而未决的问题变成通过的检查。
合并规则。如果
mechanism
透镜否定了发现结果，或
reachability
透镜无法确定触发问题的角色，或
spec
透镜否定了发现结果，则该发现结果被排除。其他情况不会移除发现结果。如果透镜返回
narrowed
，仅保留其确认有效的部分。
严重程度由透镜的验证结果决定——如果
reachability
透镜确定了触发角色，则使用其评分，因为它是感知角色的透镜；否则使用
mechanism
透镜的评分。验证环节不是降级环节。如果发现结果提交时有合理依据，验证后得到证实，则应变得更清晰：置信度更高，若验证扩大了影响范围，严重程度也应更高。如果验证环节仅降低评分，则说明校准有误。
重点验证仅基于推理的发现结果。在两次校准运行中，所有被验证环节排除的发现结果都是基于读取得出的；基于执行得出的发现结果没有被排除或降级。因此需按以下顺序排序验证队列：仅基于推理的发现结果优先，然后是审查者评分低置信度的结果。

Phase 6: Rate and order

第6阶段：评分与排序

The last judgment call, and the one the caller cannot make for itself.
  1. Re-rate by actor. Severity is a function of actor and failure, never failure alone. A defect reachable only by code that already holds full trust is not a security finding, whatever the mechanism looks like. Every finding names an actor: anonymous client, authenticated user, installed extension code, first-party code, or operator action. When verification ran, the reachability lens already named it — take that one over the finder's.
  2. Order. Severity, then confidence. Decisions last, whatever their severity.
  3. Separate decisions from defects. A finding whose entire blast radius is a deprecated, unsupported, or already-documented-as-broken surface is not a defect the author will fix — it is a question about whether that is acceptable. Mark it as a decision and say what the decision is.
  4. Check the framing carries the consequence. A finding framed around what a caller or consumer cannot do gets a real fix; the same finding framed around what an internal counter does wrong gets a literal one-line patch. Where both framings are available, lead with the consequence.
  5. Do not rewrite the claim. Severity and survival are yours to judge; the defect itself is reported in the reviewer's own framing. Do not soften a claim you kept. This governs the caller-facing report only — Phase 8 writes to the author and has the opposite mandate.
这是最后一个主观判断环节，且调用者无法替代完成。
  1. 按角色重新评分。严重程度是角色与故障的共同函数，而非仅由故障决定。仅能被已拥有完全信任权限的代码触发的缺陷，无论机制如何，都不属于安全发现。每个发现结果都需明确触发角色：匿名客户端、已认证用户、已安装扩展代码、第一方代码或操作员操作。如果运行了验证环节，
    reachability
    透镜已确定了角色——优先使用该角色，而非发现者提供的角色。
  2. 排序。先按严重程度排序，再按置信度排序。决策项无论严重程度如何，都排在最后。
  3. 区分决策项与缺陷。如果一个发现结果的影响范围仅涉及已弃用、不再支持或已记录为故障的接口，则不属于作者需要修复的缺陷——而是关于是否接受该情况的问题。标记为决策项，并说明具体问题。
  4. 确保描述体现后果。如果一个发现结果可以从调用者/消费者无法完成的操作角度描述，会得到真正的修复；如果从内部计数器错误的角度描述，只会得到一行字面意义上的补丁。如果两种描述方式都可行，优先采用体现后果的描述。
  5. 不要修改发现结论。严重程度和留存与否由你判断，但缺陷本身需按审查者的描述报告。不要弱化你保留的结论。此规则仅适用于面向调用者的报告——第8阶段向作者发布内容时遵循相反的规则。

Phase 7: Critique the synthesis (
deep
mode)

第7阶段：批判整合结果（仅
deep
模式）

Everything so far judged findings one at a time. Nothing has read the assembled report as a whole, and you assembled it — the same self-review problem this skill exists to avoid, one level up.
Dispatch one reviewer with 
references/synthesis-critic-prompt.md
, the assembled report, and the diff. It attacks the report, never the code: a root cause split across separate symptoms, a finding leading with the wrong half instead of the durable one, ranking that contradicts itself, an unproven clause still riding along, a decision filed as a defect, and at most one area nobody covered. It cannot add findings.
Apply what it returns, or say why not. It reads a report rather than a repository, so it is the cheapest agent in the run — and the only one that sees the findings as a set.
到目前为止，所有判断都是针对单个发现结果的。还没有人从整体上读取整合后的报告，而报告是你整合的——这正是本skill要避免的自我审查问题，只是层级更高了。
调度一位审查者，提供
references/synthesis-critic-prompt.md
、整合后的报告和差异内容。它会针对报告本身进行审查，而非代码：比如根本原因被拆分为多个独立症状、发现结果的描述重点错误、排序自相矛盾、仍包含未验证的条款、决策项被标记为缺陷，以及最多一个未覆盖的审查领域。它不能添加新的发现结果。
应用其返回的建议，或说明不应用的原因。它读取的是报告而非仓库，因此是本次审查中成本最低的Agent——也是唯一能将发现结果视为整体的审查者。

Report

报告格式

A title, a signal line, a paragraph stating the defect, and a 
Concretely:
list of what happens versus what should happen. No field labels — a reader should be able to understand and fix the issue from the prose alone.
undefined
包含标题、信号行、描述缺陷的段落，以及
具体表现：
列表，说明当前行为与预期行为的差异。不要使用字段标签——读者应仅通过文本就能理解并修复问题。
undefined

<one-line claim, stated as the defect>

<一行描述的问题，以缺陷形式呈现>

<Severity> severity, reachable by <actor>. <Confidence> confidence — <corroboration>.
<A paragraph naming the defect: what the code does, why that is wrong, and what the correct behavior is. This is the part someone fixes from. For an intent finding, quote the clause of the request it violates here, inline — the caller needs to see what was actually asked before deciding whether to fix the code or push back on the issue.>
Concretely:
  • <input or case>
    currently <what happens>. It should <what should happen>.
  • <input or case>
    currently <what happens>. It should <what should happen>.
<Any caveat that narrows the fix — what must keep working, what is out of scope.>
Look at 
path/to/file.ext:120
, 
path/to/other.ext:44
.

Rules for the shape:

- Severity is `critical` / `moderate` / `minor`; confidence is `high` / `medium` / `low`. Both sit
  in the signal line directly under the title, never in a field list.
- The actor sits in the signal line too, because it is what makes the severity legible.
- A **decision** takes the same shape with `Decision, not a defect` where the severity would go, and
  its paragraph ends in the question being asked rather than the fix. Decisions come after every
  finding, however severe they look: they need an answer, not a patch, and mixed in among defects
  they read as accusations and get closed.
- The corroboration clause counts reviewers, never names them: `one reviewer`, `corroborated by 2
  reviewers`. Which reviewer found it is a debugging detail; how many found it independently is the
  signal. Count only reviewers that actually ran.
- Say how the finding was established: `demonstrated by execution` when a reviewer or the mechanism
  lens ran the failing case, `reasoned` when it came from reading. It is the strongest thing a finding
  can carry and the best predictor of whether it survives contact with the author.
- A clustered finding reports the root as the finding and nests each symptom as its own
  `Concretely:` bullet with its own location.
- Each bullet is a self-contained sentence pair, one case per bullet however many there are.
- Write the actual-state clause as a verb phrase so it reads after "currently" — `currently parses
  without error`, not `currently accepted`.
- Locations go last. A reader triages on the claim and the severity, not on the path.
- When the finding is that something is **missing**, omit the `Look at` line. Do not name a
  plausible file: the case list already says what is missing, and a guessed path sends the fixer to
  the wrong place.
<严重程度>严重，可由<角色>触发。<置信度>置信度——<佐证情况>。
<一段文字描述缺陷：代码当前的行为、为何错误、正确行为是什么。这是修复的核心依据。对于需求匹配发现，在此处引用需求中的相关条款——调用者需要看到实际需求，才能决定是修复代码还是反馈需求问题。>
具体表现：
  • <输入或场景>
    当前<实际行为>。预期<应有的行为>。
  • <输入或场景>
    当前<实际行为>。预期<应有的行为>。
<任何缩小修复范围的说明——哪些内容必须保持正常工作，哪些内容不属于修复范围。>
查看
path/to/file.ext:120
、
path/to/other.ext:44
。

格式规则：

- 严重程度分为`critical`/`moderate`/`minor`；置信度分为`high`/`medium`/`low`。两者都放在标题下方的信号行中，绝不在字段列表中。
- 触发角色也放在信号行中，因为它是严重程度的关键依据。
- **决策项**采用相同格式，但在严重程度的位置替换为`决策项，非缺陷`，且段落结尾是提出的问题而非修复建议。决策项排在所有发现结果之后，无论看起来有多严重：它们需要的是答复，而非补丁；如果与缺陷混合在一起，会被视为指责而被关闭。
- 佐证情况仅统计审查者数量，不命名：`一位审查者`、`两位审查者佐证`。哪位审查者发现的是调试细节；有多少位审查者独立发现的才是有效信号。仅统计实际运行的审查者。
- 说明发现结果的验证方式：如果审查者或`mechanism`透镜运行了故障场景，则标注`通过执行验证`；如果仅通过读取得出，则标注`基于推理`。这是发现结果最有力的支撑，也是预测其是否能被作者认可的最佳指标。
- 聚类后的发现结果将根本原因作为主发现，每个症状作为`具体表现：`下的子项，并附带各自的位置。
- 每个子项都是独立的句子对，每个场景占一个子项，无论数量多少。
- 实际行为部分需使用动词短语，使其能接在“当前”之后——比如`当前可无错误解析`，而非`当前被接受`。
- 位置信息放在最后。读者会根据问题描述和严重程度进行分类，而非路径。
- 如果发现结果是**缺失内容**，则省略`查看`行。不要猜测可能的文件：场景列表已说明缺失的内容，猜测的路径会引导修复者到错误的位置。

Output

输出结构

undefined
undefined

Changes review: N findings (C critical, M moderate, m minor) · D decisions

代码变更审查：共N个发现结果（C个critical，M个moderate，m个minor）· D个决策项

Scope: <files, lines, base> · mode: <simple|standard|deep> Reviewers: cold (<model>) · cold-2 (<model>|skipped) · intent (<model>|skipped) · external (<cli>|skipped) Lenses: <lens skills that ran, or none matched|skipped> Verification: <lenses run, K findings dropped, J re-rated>
<findings, most severe first, then decisions>

Drop the `· D decisions` clause when there are none. When every reviewer returns nothing:
审查范围：<文件、行数、基准分支> · 模式：<simple|standard|deep> 审查者：无上下文审查者(<模型>) · 第二位无上下文审查者(<模型>|已跳过) · 需求匹配审查者(<模型>|已跳过) · 外部审查者(<cli>|已跳过) 透镜：<运行的透镜skill，或无匹配|已跳过> 验证环节：<运行的透镜，K个发现结果被排除，J个被重新评分>
<发现结果，按严重程度从高到低排序，最后是决策项>

如果没有决策项，省略`· D个决策项`部分。如果所有审查者都未发现问题：

Changes review: no findings

代码变更审查：未发现问题

Scope: <files, lines, base> · mode: <simple|standard|deep> Reviewers: cold (<model>) · cold-2 (<model>|skipped) · intent (<model>|skipped) · external (<cli>|skipped) Lenses: <lens skills that ran, or none matched|skipped>

A clean result is a real result. Do not pad it with observations, and do not add a section listing
what was checked and found sound — it reads as padding and nobody acts on it.

One report serves every caller. A caller wanting something shorter condenses what it got.

Then stop. Do not fix, do not offer to fix, and do not start a second round. Round policy and
triage belong to the caller. Publish only if the caller asked — Phase 8.
审查范围：<文件、行数、基准分支> · 模式：<simple|standard|deep> 审查者：无上下文审查者(<模型>) · 第二位无上下文审查者(<模型>|已跳过) · 需求匹配审查者(<模型>|已跳过) · 外部审查者(<cli>|已跳过) 透镜：<运行的透镜skill，或无匹配|已跳过>

无问题是有效的审查结果。不要添加无关的观察内容，也不要添加说明已检查哪些内容且无问题的章节——这会被视为冗余内容，没有人会关注。

一份报告适用于所有调用者。如果调用者需要更简短的内容，可自行精简。

随后停止。不要修复问题、不要主动提出修复、不要启动第二轮审查。循环策略和分类由调用者负责。仅在调用者要求时才发布内容——第8阶段。

Phase 8: Publish (on 
--comment
or 
--review
)

第8阶段：发布内容（仅
--comment
或
--review
模式）

Off by default. The report above is the deliverable; this phase turns it into correspondence addressed to the person who wrote the code. Those are different artifacts with an inverted rule. The report is unjudged on purpose; published text must be judged, because unjudged output costs its reader their time.
Two shapes, and whose branch it is decides. On your own pull request GitHub refuses a review, so publication is a single issue comment — 
--comment
. On someone else's it is a real review — 
--review
: one inline comment per finding anchored to the line it concerns, minors grouped into one, anything that fits no line in the review body, and a verdict. When the caller asked to publish but named no shape, resolve authorship with 
gh pr view --json author
against 
gh api user --jq .login
and take the one that fits.
Read 
references/publishing-a-review.md
before composing. It owns the composition rules, the length budget, the anchoring mechanics and the verdict mapping. Five steps, in order:
  1. Verify — already done, in Phase 5. A finding that phase killed is never published, and one it could not demonstrate does not get a section.
  2. Attribute — for each survivor, 
    git blame
    and 
    git diff <base>...HEAD
    to establish whether this branch introduced the blamed code. Reclassify it as pre-existing, or narrow the claim to the part that is new. Reviewers are blind to the base, so this is the first point it can happen.
  3. Compose — one section per cause, ordered by what the author should act on first, following the composition rules and the length budget in the reference. In review shape each section becomes an inline comment, and the lead and closing paragraphs become the review body.
  4. Gate — refuse any section lacking a demonstration or an attribution, and refuse a fifth section: more than four means clustering failed. Unverified residue gets one flagged sentence in the closing paragraph, never a section.
  5. Confirm, then post. Show the composed text — in review shape every inline comment, the body, and the verdict — and ask before any of it goes anywhere. The flag authorizes the phase, not the words: this is outward-facing correspondence published under the user's account, and an approving verdict is the one output that cannot be walked back gracefully. Offer post as written / edit first / discard, with post as written recommended. Where the host has no structured prompt, ask the same thing in chat as a short numbered list and wait for a reply. A caller running unattended does not get to skip this — it prints everything and stops.
The attribution footer resolves from the target repo's instruction file rather than being hardcoded. A clean run still publishes: one short paragraph, and in review shape an approving verdict.
默认关闭。上述报告是交付成果；本阶段将其转换为面向代码作者的沟通内容。这是两种不同的产物，规则相反。报告故意保持客观；而发布的内容必须带有判断，因为客观的输出会浪费读者的时间。
两种发布形式，由分支归属决定。在自己的Pull Request中，GitHub不允许提交审查，因此发布形式为单个Issue评论——
--comment
。在他人的Pull Request中，则提交正式审查——
--review
：每个发现结果对应一条锚定到相关代码行的内联评论，minor级问题合并为一条评论，无法锚定到代码行的内容放在审查正文中，并给出最终 verdict。如果调用者要求发布但未指定形式，通过
gh pr view --json author
对比
gh api user --jq .login
确定作者身份，选择合适的形式。
在撰写前请阅读
references/publishing-a-review.md
。该文档规定了撰写规则、篇幅限制、锚定机制和verdict映射方式。按以下五步顺序执行：
  1. 验证——已在第5阶段完成。第5阶段排除的发现结果绝不发布，无法验证的发现结果不单独成段。
  2. 归因——对于每个留存的发现结果，通过
    git blame
    和
    git diff <base>...HEAD
    确定该分支是否引入了被标记的代码。将其重新分类为已存在的问题，或缩小结论范围至本次新增的内容。由于审查者对基准分支无感知，这是首次能进行归因的环节。
  3. 撰写——每个根本原因对应一个章节，按作者应优先处理的顺序排序，遵循参考文档中的撰写规则和篇幅限制。在审查形式中，每个章节对应一条内联评论，开头和结尾段落作为审查正文。
  4. 验证关卡——拒绝任何缺乏验证或归因的章节，拒绝第五个章节：超过四个章节意味着聚类失败。未验证的剩余内容在结尾段落中用一句话标注，绝不单独成段。
  5. 确认后发布——展示撰写好的内容——在审查形式中包括所有内联评论、正文和verdict——并在发布前征求确认。命令行参数仅授权该阶段，而非内容：这是对外发布的沟通内容，使用用户账号发布，而认可的verdict是无法优雅撤回的输出。提供“按原文发布/先编辑/放弃发布”选项，推荐按原文发布。如果宿主没有结构化提示，在聊天中以简短的编号列表形式提出相同问题并等待回复。无人值守的调用者也不能跳过此步骤——需输出所有内容并停止。
归因页脚由目标仓库的说明文件决定，而非硬编码。无问题的审查结果仍需发布：一段简短的文字，在审查形式中给出认可的verdict。

Rules

核心规则

  • One job per reviewer. Never merge the prompts.
  • No reasoning reaches a reviewer. Not the plan, not the rationale, not a summary of intent, not a previous round's findings or verdicts.
  • Never mutate. No edits, no autofix, no commits, no stashes. Callers rely on this.
  • Concrete failure or it does not exist.
  • Severity needs an actor. A rating that does not say who can reach the defect is not a rating.
  • No manufactured findings. A reviewer returning "No findings" on sound code is correct behavior, not a failed run.
  • Publication judges; the report does not. Phase 8 is the only place this skill drops, narrows or re-attributes a finding it kept, and the only place it writes anything outward-facing.
  • 每位审查者仅承担单一任务。绝不要合并提示内容。
  • 审查者不得获取任何实现思路。包括实现计划、设计rationale、意图摘要、之前的审查结果或verdict。
  • 绝不修改任何内容。不编辑代码、不自动修复、不提交、不暂存。调用者依赖此规则。
  • 必须有具体故障，否则视为不存在。
  • 严重程度需明确触发角色。未说明谁能触发缺陷的评分无效。
  • 不得编造发现结果。如果审查者认为代码无问题并返回“No findings”，这是正确行为，而非运行失败。
  • 发布内容需带有判断；报告保持客观。第8阶段是本skill唯一可以排除、缩小或重新归因留存发现结果的环节，也是唯一对外发布内容的环节。

Error handling

错误处理

SituationAction
No changes in scopePrint 
Nothing to review.
and stop
Trivial diff onlyPrint 
Trivial changes only. Nothing to attack.
and stop
No requirement resolvesRun the cold reviewer only, say so in the report
External CLI missing or times outNote it in the Reviewers line, continue
Host cannot vary models per reviewerRun them on the default, say so in the report
Host has no subagentsRun reviewers sequentially, say they were not isolated
A verification lens failsApply the merge rule with the lenses that returned, say which is missing
A reviewer stalls or returns nothingRelaunch it once with a narrowed file list and a stated tool budget — not the same prompt again. A reviewer that goes quiet on a wide diff is usually still reading it
A native reviewer returns nothing usableReport the remaining reviewers, name the gap
Every reviewer failsSay so plainly. Do not substitute your own review — that is the one thing this skill exists to avoid
Anything fails during publicationSee the failure table in 
references/publishing-a-review.md
. Every case ends in print-and-do-not-post
场景操作
审查范围内无变更输出
无内容可审查。
并停止
仅存在微小差异输出
仅存在微小变更，无需审查。
并停止
无法确定需求来源仅运行无上下文审查者，并在报告中说明
外部CLI缺失或超时在审查者行中注明，继续运行
宿主无法为每位审查者分配不同模型使用默认模型运行，并在报告中说明
宿主没有子Agent顺序运行审查者，并说明审查者未被隔离
某个验证透镜运行失败使用返回结果的透镜应用合并规则，并说明缺失的透镜
审查者停滞或无返回结果使用缩小的文件列表和指定的工具预算重新启动一次——不要使用相同的提示。如果审查者在处理大范围差异时无响应，通常仍在读取内容
原生审查者返回无效内容报告剩余审查者的结果，并说明缺失的部分
所有审查者运行失败直接说明情况。不要自行替代审查——这正是本skill要避免的行为
发布过程中出现任何错误查看
references/publishing-a-review.md
中的错误处理表。所有情况均输出内容但不发布