review-loop

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review Loop

审查循环

Run an implement → test → independent review → fix loop. The main agent only coordinates; delegate every implementation and review pass to a fresh worker.

This skill uses only portable Agent Skills metadata and refers to other skills by name in plain language. Do not assume that

$name

/name

invocation syntax works in every harness.

运行“实现→测试→独立审查→修复”循环。主Agent仅负责协调；将每一次实现和审查任务都委托给全新的工作Agent。

本技能仅使用可移植的Agent Skills元数据，并以自然语言引用其他技能的名称。请勿假设

$name

或

/name

调用语法在所有环境中都能生效。

Inputs

输入参数

Use user values or these defaults: goal = current conversation (ask only if absent); implementation harness/model = current; review harness/model = current; review parallelism = 1; greenfield = false; test lifecycle =

parallel

; max cycles = unlimited;

propose_improvements

= false;

fix_scope

root_cause

(alternative:

immediate

Treat

greenfield: true

as permission to make breaking changes. Otherwise, preserve compatibility; ask before a breaking change.

“Unwrap the onion” means

fix_scope: root_cause

: solve at the root so extra layers are unnecessary. If the user says that phrase, use

root_cause

even if

immediate

was set earlier.

When

propose_improvements: true

, collect candidate changes to this skill's reusable implementation and review instructions that could prevent similar review findings in future delegated runs. Do not collect them when false. These proposals are advisory only; do not modify the skill or repository instructions unless the user separately asks.

使用用户提供的值或以下默认值：目标=当前对话（仅当缺失时询问）；实现环境/模型=当前环境；审查环境/模型=当前环境；审查并行度=1；全新项目（greenfield）=false；测试生命周期=

parallel

；最大循环次数=无限制；

propose_improvements

=false；

fix_scope

root_cause

（备选值：

immediate

）。

当

greenfield: true

时，允许进行破坏性变更。否则，需保持兼容性；进行破坏性变更前需先询问用户。

“逐层拆解问题”（Unwrap the onion）意味着

fix_scope: root_cause

：从根源解决问题，避免不必要的额外层级。如果用户使用该表述，即使之前设置的是

immediate

，也要改用

root_cause

。

当

propose_improvements: true

时，收集可复用的实现改进建议以及审查指令优化方案，以避免未来委托任务中出现类似的审查问题。若为false则不收集这些建议。这些建议仅作参考；除非用户单独要求，否则不得修改本技能或仓库指令。

Clarify decisions

决策澄清

If implementation details require user intent, invoke the

user-decision

skill before proceeding. If the user explicitly or implicitly requests noninteractive work, choose each best long-term option without asking. Use quick options only when the user requests them for the entire review loop.

若实现细节需要明确用户意图，需先调用

user-decision

技能再继续。若用户明确或隐含要求非交互式工作，则无需询问，直接选择最符合长期利益的方案。仅当用户要求整个审查循环使用快速选项时，才采用快速决策。

Worker selection

工作Agent选择

For

current

, use a fresh native subagent when the current harness supports one. Otherwise, invoke a fresh noninteractive process of the current harness through the

invoke-harness

skill. For any named external harness, use

invoke-harness

. Each worker must receive the goal and required context in its initial prompt; do not rely on conversation state shared by a previous worker. State the worker's role (implementer, reviewer, or critic) and that it is performing that pass only. Instruct it not to re-enter this skill, invoke a nested harness, or wait on stdin.

Interpret “review loop with X” as X reviews while the current harness's fresh native subagents implement, unless the user explicitly assigns implementation to X. Honor explicit role assignments such as “X implements; Y reviews.”

Scale review effort to the affected surface and uncertainty, honoring user settings; use reasoning controls only if supported. With multiple reviewers, assign complementary focuses (implementation correctness; affected consumers and lifecycle paths), while all check the claimed invariants. Require explicit completion, findings or an explicit clean result for reviews, and the applicable brief's evidence. Empty, interrupted, or malformed output is an invalid pass: inspect any partial edits, retry once with a fresh worker, then stop as incomplete if still invalid.

对于“当前环境”，若当前支持原生子Agent，则使用全新的原生子Agent；否则，通过

invoke-harness

技能调用当前环境的全新非交互式进程。对于指定的外部环境，使用

invoke-harness

技能调用。每个工作Agent的初始提示中必须包含目标和所需上下文；不得依赖前一个工作Agent共享的对话状态。需明确说明工作Agent的角色（实现者、审查者或评判者），且该Agent仅负责当前阶段的任务。指令其不得重新进入本技能、调用嵌套环境或等待标准输入。

将“与X一起进行审查循环”理解为：由当前环境的全新原生子Agent负责实现，X负责审查，除非用户明确指定由X负责实现。需遵守明确的角色分配，例如“X负责实现；Y负责审查”。

根据受影响范围和不确定性调整审查工作力度，遵循用户设置；仅在支持的情况下使用推理控制。若有多个审查者，需分配互补的审查重点（实现正确性；受影响的消费者和生命周期路径），同时所有审查者都需检查声明的不变量。审查需明确完成，提供审查结果或明确的无问题结论，并附上适用的证据。空白、中断或格式错误的输出视为无效审查：检查任何部分编辑内容，使用全新工作Agent重试一次，若仍无效则终止并标记为未完成。

Implementer brief

实现者说明

Include this brief verbatim in every implementation worker prompt:

For each addressed finding, provide
```
Class sweep: scope searched; affected sites; enforcement point; verification; remaining exceptions
```
. Under
```
root_cause
```
, fix the full class within the goal's scope. If the instance is the full class, justify that bound. Checks or warnings close a finding only if they prevent the prohibited behavior; otherwise the unmet requirement stays open unless explicitly deferred.
Maintain a compact coverage table for each changed invariant:
```
site / operation | holds, violates, or unknown | evidence
```
. Include consumers and siblings, plus entry, exit, bypass, failure, timeout, shutdown, and re-entry paths where relevant. Give the search scope, queries and results, or structural bound establishing completeness. Group sites only when the same proof covers them; update the artifact incrementally.
For shared-state changes, document ownership and lock/permit order; a terminal state is not a lock. For crash/restart-sensitive changes, persist required state and show durable intent before recoverable external effects. Do not add mechanism to compensate for an incomplete inventory.
Run assigned validation commands, honoring
```
test lifecycle
```
and
```
skip
```
; report commands, results, and gaps. Coordinate resource-heavy commands with the coordinator. First-pass tests cover the empty/default case and primary action; regression checks must exercise the defect.

需将以下说明原封不动地包含在每个实现工作Agent的提示中：

针对每个需解决的审查问题，提供
```
类别排查：搜索范围；受影响站点；执行点；验证方式；剩余例外情况
```
。在
```
root_cause
```
模式下，在目标范围内修复整个类别问题。若当前实例即为完整类别，需说明该边界的合理性。只有当检查或警告能够阻止违规行为时，才能关闭该审查问题；否则，未满足的要求将保持开放状态，除非明确延期处理。
为每个变更后的不变量维护一个简洁的覆盖表：
```
站点/操作 | 符合、违反或未知 | 证据
```
。需包含消费者和关联组件，以及相关的入口、出口、绕过、失败、超时、关闭和重入路径。说明搜索范围、查询语句及结果，或确保完整性的结构边界。仅当同一证明适用于多个站点时才进行分组；逐步更新工件。
对于共享状态变更，记录所有权和锁/许可顺序；终端状态并非锁。对于崩溃/重启敏感的变更，在产生可恢复的外部影响前，需持久化所需状态并展示持久化意图。不得添加机制来弥补不完整的清单。
执行指定的验证命令，遵循
```
test lifecycle
```
和
```
skip
```
设置；报告命令、结果和缺口。与协调者协调资源密集型命令。首次测试需覆盖空/默认情况和主要操作；回归检查必须针对缺陷场景。

Reviewer brief

审查者说明

Include this brief verbatim in every review worker prompt and in the critic prompt:

Independently verify coverage for each changed invariant using
```
site / operation | holds, violates, or unknown | evidence
```
. Check consumers beyond the diff, and the search scope, queries and results, or structural bound establishing completeness. Group sites only when the same proof covers them. Missing bounds or unknown coverage require a blocking
```
enumeration incomplete
```
finding; an assertion of exhaustiveness is insufficient. Report every violating row this pass, grouped by root cause.
Include entry, exit, bypass, failure, timeout, shutdown, re-entry, and sibling paths where relevant from the first review. For persisted state machines, cover durable states, transitions, and reachable callers across success, retry, and conflict; a required transition with no production trigger is blocking. Later reviews must also inspect newly changed code and affected consumers, not just prior findings.
For shared-state changes: check object identity vs recycled ids; who owns the write after cancel/timeout; and lock/permit order of both the current code and any remedy. For recoverable external effects, durable intent precedes the effect. Do not treat a terminal or success state as a lock without proving mutual exclusion and ownership. Do not recommend a lock strategy you have not checked against existing acquisition sites. State the invariant and the missing proof, not a patch recipe.
Use executable validation results for build/type/syntax claims; request a targeted check when needed, and label unavailable checks unverified. Inspect whether tests would fail on the claimed defect, even when they pass now.
Do not change established observable ordering (authz, error kind) unless
```
greenfield
```
is true or the goal says to.
For partial enforcement, distinguish prevented violations from detected or still-possible violations. An unmet required invariant remains required. Attach further bypass evidence to the same class; reopen it if closure is disproved. Only explicit deferral changes a required item to accepted remaining risk.
Report each finding at its root cause and name the full class or causal chain it belongs to, with code evidence. When one root cause surfaces across several layers or sites, file it once as a root-cause finding, not a series of surface instances. Reuse the finding ledger's ID when the class matches; otherwise mark it as a new class.

需将以下说明原封不动地包含在每个审查工作Agent和评判者的提示中：

使用
```
站点/操作 | 符合、违反或未知 | 证据
```
独立验证每个变更后不变量的覆盖范围。检查差异之外的消费者，以及确保完整性的搜索范围、查询语句及结果或结构边界。仅当同一证明适用于多个站点时才进行分组。缺失边界或未知覆盖范围需标记为阻塞性的
```
枚举不完整
```
问题；仅断言完整性是不够的。报告本次审查中所有违反情况，按根本原因分组。
需包含首次审查中相关的入口、出口、绕过、失败、超时、关闭、重入和关联组件路径。对于持久化状态机，需覆盖成功、重试和冲突场景下的持久状态、转换及可调用方；若存在无生产触发条件的必要转换，则视为阻塞性问题。后续审查还需检查新变更的代码和受影响的消费者，而非仅关注之前的问题。
对于共享状态变更：检查对象标识与回收ID的区别；取消/超时后谁拥有写入权限；当前代码及任何修复方案的锁/许可顺序。对于可恢复的外部影响，持久化意图需先于影响产生。若未证明互斥性和所有权，不得将终端或成功状态视为锁。不得推荐未针对现有获取站点检查过的锁策略。需说明不变量和缺失的证明，而非补丁方案。
使用可执行的验证结果来支持构建/类型/语法相关声明；必要时请求针对性检查，并标记无法获取的检查为未验证。检查测试是否会在存在声明缺陷的情况下失败，即使当前测试通过。
除非
```
greenfield
```
为true或目标明确要求，否则不得更改已确立的可观察顺序（授权、错误类型）。
对于部分执行的情况，区分已阻止的违规、已检测到的违规和仍可能发生的违规。未满足的必要不变量仍需满足。将进一步的绕过证据附加到同一类别；若关闭结论被推翻，则重新开放该问题。只有明确延期才能将必要项改为已接受的剩余风险。
每个问题需按根本原因报告，并说明其所属的完整类别或因果链，附上代码证据。当一个根本原因在多个层级或站点出现时，需作为一个根本原因问题提交一次，而非一系列表面实例。若类别匹配，复用问题台账中的ID；否则标记为新类别。

Loop

循环流程

Keep a cumulative ledger:

ID | invariant/class | required? | open, closed, or deferred | latest evidence

. Preserve IDs and closure evidence; assign a new ID only to a new class. Independent review must confirm closure. Blocking findings and code validation failures stay required until closed or explicitly deferred. Environment/tooling failures block verified readiness but are not code findings. Only the user may defer required code items, except the coordinator may do so in noninteractive runs; record every deferral and reason. Non-required open findings do not drive cycles. Do not expand the design while required work remains unless the redesign is a prerequisite.

Before implementation, select repository-supported fast build/type/syntax checks covering affected code and changed tests where applicable, plus broader relevant tests. Implementers may run them. Serialize resource-heavy checks when needed and reuse results for unchanged inputs. The fast gate runs after every implementation/fix pass before semantic review; broader tests follow

test lifecycle

skip

skips both and must be reported as unverified; do not invent a gate when none applies.

For each cycle, until no required open items remain or

max cycles

is reached:

Delegate an implementation pass with the goal,
```
greenfield
```
,
```
fix_scope
```
, ledger, coverage artifact, validation commands/lifecycle, latest results, and implementer brief verbatim. Close required items and cheap non-required items. Full class repair is not design expansion. For
```
immediate
```
, fix only the reported instance and record remaining layers as deferred required items.
Capture the complete task diff against a fixed baseline, including new files, and identify the revision/snapshot reviewed and tested. Collect or run the fast gate; return code failures to implementation before semantic review. Record unavailable gates as unverified. For broader tests, wait with
```
before_review
```
, start without waiting with
```
parallel
```
, or defer with
```
after_review
```
. Confirm filters selected the intended tests; otherwise use the package's own command or report full-package results. Do not duplicate valid implementer checks.
Delegate
```
review parallelism
```
independent reviews with the goal,
```
greenfield
```
, complete diff, ledger, coverage artifact, repository context, available validation results, and reviewer brief verbatim. Ask for actionable correctness, compatibility, security, maintainability, or missing-test issues. Require code evidence (
```
path:line
```
, symbol, or check result); label unverified objections as concerns. List out-of-scope suggestions separately. When
```
propose_improvements
```
is true, separately propose reusable instruction changes that would have prevented findings; exclude project-specific advice.
Have one fresh critic adjudicate findings, closure evidence, and coverage gaps against the goal, diff, repository, available validation results, ledger, coverage artifact, and reviewer brief; it may also raise missed findings. Its response must end with exactly one verdict line:
text
```
AGREE
DISAGREE_EVIDENCE: <code citation or test result>
DISAGREE_CONCERN: <specific unverified objection>
```
```
AGREE
```
preserves all findings.
```
DISAGREE_EVIDENCE
```
may add, revise, or reject findings only as supported by the cited evidence.
```
DISAGREE_CONCERN
```
cannot suppress a finding: delegate one concise evidence-resolution pass using the worker-selection rule, then retain only claims grounded in code or tests. Do not continue reviewer–critic debate beyond this pass.
Collect
```
parallel
```
results or run
```
after_review
```
tests; run none for
```
skip
```
. Merge evidence-backed findings and code validation failures by class; one clean review cannot override another's blocker. Accept only when no required open items remain and all assigned reviews, the critic, and applicable checks validly cover the final revision. If checks were unavailable or skipped, report the review outcome as unverified, not ready. Any later edit requires renewed review and validation of its effects. Otherwise pass the updated ledger, coverage artifact, and latest results to the next implementer.

If the same class remains unresolved across two successive fix passes without new closure evidence, require a different approach in the next pass. If that pass also makes no progress, stop as incomplete with the unresolved evidence. This includes fast-gate repair passes.

max cycles

bounds implementation passes, including gate repairs; invalid-pass limits also apply. None of these stops imply approval.

On completion, summarize the implementation, review outcome, validation, risks, deferrals, open findings, and any incomplete stop reason. List out-of-scope suggestions separately. If

propose_improvements

is true, add a concise Potential skill improvements section to the end report. Each item must state the reusable instruction change and the category of review iteration it is expected to prevent; omit empty or project-specific suggestions. Do not add the proposals to

AGENTS.md

CLAUDE.md

, or the skill unless the user separately asks.

维护一个累积台账：

ID | 不变量/类别 | 是否必要 | 开放、已关闭或已延期 | 最新证据

。保留ID和关闭证据；仅为新类别分配新ID。独立审查必须确认问题已关闭。阻塞性问题和代码验证失败需保持必要状态，直至关闭或明确延期。环境/工具故障会阻碍验证就绪，但不属于代码问题。只有用户可延期必要的代码项，除非在非交互式运行中由协调者处理；需记录每一次延期及原因。非必要的开放问题不会驱动循环。在必要工作完成前，不得扩展设计，除非重新设计是必要前提。

在实现前，选择仓库支持的快速构建/类型/语法检查，覆盖受影响的代码和变更的测试（如适用），以及更广泛的相关测试。实现者可运行这些检查。必要时序列化资源密集型检查，并复用未变更输入的结果。快速检查需在每次实现/修复后、语义审查前运行；更广泛的测试遵循

test lifecycle

设置。

skip

会跳过这两类检查，需报告为未验证；若无适用检查，则无需创建检查环节。

在每个循环中，直至无必要的开放项或达到

max cycles

限制：

将目标、
```
greenfield
```
、
```
fix_scope
```
、台账、覆盖工件、验证命令/生命周期、最新结果以及实现者说明原封不动地委托给实现环节。关闭必要项和低成本的非必要项。完整类别修复不属于设计扩展。在
```
immediate
```
模式下，仅修复报告的实例，并将剩余层级记录为已延期的必要项。
捕获相对于固定基线的完整任务差异，包括新文件，并确定已审查和测试的版本/快照。收集或运行快速检查；若代码失败，返回给实现环节再进行语义审查。记录无法获取的检查为未验证。对于更广泛的测试，选择
```
before_review
```
（等待完成）、
```
parallel
```
（不等待直接启动）或
```
after_review
```
（延期执行）。确认过滤器选择了预期的测试；否则使用包自身的命令或报告全包结果。不得重复执行有效的实现者检查。
将目标、
```
greenfield
```
、完整差异、台账、覆盖工件、仓库上下文、可用的验证结果以及审查者说明原封不动地委托给
```
review parallelism
```
个独立审查环节。要求提供可操作的正确性、兼容性、安全性、可维护性或测试缺失问题。需提供代码证据（
```
路径:行号
```
、符号或检查结果）；将未验证的异议标记为关注点。单独列出超出范围的建议。当
```
propose_improvements
```
为true时，单独提出可复用的指令变更建议，以避免出现此类问题；排除项目特定的建议。
安排一个全新的评判者，针对目标、差异、仓库、可用的验证结果、台账、覆盖工件和审查者说明，对审查结果、关闭证据和覆盖缺口进行裁决；评判者也可提出遗漏的问题。其回复必须以恰好一条裁决语句结尾：
text
```
AGREE
DISAGREE_EVIDENCE: <代码引用或测试结果>
DISAGREE_CONCERN: <具体未验证异议>
```
```
AGREE
```
保留所有审查结果。
```
DISAGREE_EVIDENCE
```
可根据引用的证据添加、修改或驳回审查结果。
```
DISAGREE_CONCERN
```
无法压制审查结果：需根据工作Agent选择规则委托一次简洁的证据确认环节，然后仅保留基于代码或测试的声明。不得让审查者与评判者进行超出此环节的争论。
收集
```
parallel
```
模式下的测试结果或运行
```
after_review
```
测试；
```
skip
```
模式下不运行任何测试。按类别合并有证据支持的审查结果和代码验证失败；一次无问题的审查无法覆盖另一次的阻塞性问题。仅当无必要的开放项，且所有指定的审查、评判和适用检查都有效覆盖最终版本时，才接受结果。若检查无法获取或被跳过，需将审查结果报告为未验证，而非就绪。任何后续编辑都需重新审查并验证其影响。否则，将更新后的台账、覆盖工件和最新结果传递给下一个实现者。

若同一类别问题在连续两次修复环节中未解决且无新的关闭证据，下一次环节需采用不同方法。若该环节仍无进展，则终止并标记为未完成，附上未解决的证据。这包括快速检查修复环节。

max cycles

限制实现环节的次数，包括检查修复；无效环节限制同样适用。这些终止都不代表批准。

完成时，总结实现内容、审查结果、验证情况、风险、延期项、开放问题以及任何未完成的终止原因。单独列出超出范围的建议。若

propose_improvements

为true，在最终报告末尾添加一个简洁的潜在技能改进点部分。每个改进项需说明可复用的指令变更以及预期避免的审查迭代类别；省略空白或项目特定的建议。除非用户单独要求，否则不得将这些建议添加到

AGENTS.md

、

CLAUDE.md

或本技能中。