review

Review Skill

概述

对完整集成差异（功能分支与 main 的差异）进行一次对抗性审查。由一位具有全新上下文的审查者同时评判规范符合度、代码质量和测试充分性——不分阶段进行先审规范、再审质量。此轮审查只给出一个结论（reviews.review.status）。

**审查立场：**你是一位对抗性审查者。你的任务是找出问题，而不是确认正确之处。

**强制要求：**在接受任何“无需完整验证即可批准”的合理化说辞之前，先查阅 references/rationalization-refutation.md。其中列出了每种常见借口、相应的反驳理由和正确做法。

执行上下文

此技能在编排器启动的子代理中运行，而非内联运行——子代理是一位干净的审查者，没有作者的对话记录，并会获得差异和规范。

编排器：

1. 生成一次集成差异：exarchos_orchestrate({ action: "review_diff", baseBranch: "main" })（或 git diff main...HEAD）。
2. 在派发提示中传入差异内容、状态文件路径（用于解析产物）以及意图依据。

意图依据（预期与交付）

编排器会将预期变更记录为 artifacts.intent，并通过 intentGrounding 指令将其传入派发内容。若存在，请据此核验交付的差异：

• 预期但缺失——意图要求的界面或结果未在差异中实现。将其标记为 spec 问题。
• 已交付但非预期（范围蔓延）——变更超出预期范围，且没有规范依据。将其标记为 spec 问题。

若未提供 intentGrounding，则仅依据差异进行审查——不要臆造意图。

此轮审查涵盖内容

先选择审查方法：exarchos_orchestrate({ action: "runbook", id: "review-strategy" })——根据差异大小和此前修复周期的次数，决定采用单轮还是双轮审查。

在一个视图中审查所有任务的合并差异——这样可以发现跨任务接口不匹配、单独审查时看不到的错误，以及不一致的模式。在同一轮审查中涵盖以下三个视角：

1. 规范符合度——功能完整性、与规范的一致性，以及预期与交付的对照。参见 references/spec-compliance-checklist.md。
2. 测试充分性——基于结果，并按层级调整（不要求先写测试再实现）。结算过程已针对其验证的每项任务运行了杀伤探测，基准为该任务冻结的基线。读取记录的结论；不要再次运行探测：

   exarchos_event({ action: "query", stream: "<featureId>", filter: { type: "gate.executed" }, limit: 200 })
   

   每条 gateName: "test-adequacy" 的记录对应一项任务的结论：details.taskId、passed 和 details.verdict（details.skipped 表示按策略跳过）。passed: false 的结论表示该任务存在问题。只有在某项任务没有此类记录时，才自行运行探测；运行时应使用该任务分出的分支。传入 repoRoot: "auto" 和该任务的工作树。探测会先还原、再恢复其运行所在工作树的源代码。若缺少这两个字段，该工作树会是服务端所在目录，通常也就是你自己的检出目录：

   exarchos_orchestrate({
     action: "check_test_adequacy",
     featureId: "<featureId>",
     taskId: "<taskId>",
     branch: "<branch>",
     baseBranch: "<integration branch>",
     repoRoot: "auto",
     worktreePath: "<worktreePath>",
     riskTier: "<low|medium|high>",
     phase: "review"
   })
   

3. 代码质量——正确性、SOLID、错误处理、安全性、性能、可维护性，以及测试要求（行为导向、不依赖结构、确定性、具体）。参见 references/code-quality-checklist.md、references/security-checklist.md、references/typescript-standards.md。

门禁执行

通过 runbook 运行质量评估门禁 — exarchos_orchestrate({ action: "runbook", id: "quality-evaluation" }) — 然后执行由 MCP 提供的质量检查目录。签名详见 references/gate-execution.md。

1. check_static_analysis — lint + 类型检查（D2）。必须通过。
2. check_security_scan — 安全模式检测（D1）。
3. prepare_review — 返回确定性的检查目录（grep / 结构检查 / 启发式检查）和 pluginStatus。针对已更改的文件执行每项检查；将发现汇总为 pluginFindings。
4. 可选的 D3–D5 门禁（check_context_economy、check_operational_resilience、check_workflow_determinism）— 仅供参考；将结果纳入收敛视图。

mutation-adequacy（仅适用于 HIGH 等级）：这是一个独立的必需维度，在 /review 边界处为 HIGH 风险等级设置门禁 — 详见 @skills/mutation-adequacy/SKILL.md。不要在此技能中运行变异测试；最接近范围内的替代检查是 Specific 测试期望属性，以及委派时的 check_test_adequacy 门禁。

不变量符合性 — 审计模式的判断由你负责

只要 .exarchos.yml: invariants.catalogs 下注册了目录，就对差异运行 check_invariant_conformance。它会机械地判定 mode: check 不变量，并将结果纳入 findings。它完全无法判定 mode: audit 不变量 — 这需要审阅者（也就是你）作出判断。

exarchos_orchestrate({
  action: "check_invariant_conformance",
  featureId: "<id>",
  phase: "review",
  diff: "<integrated diff>"
})

响应中包含审计模式交付内容对：

• auditPrompt — 渲染后的判断问题，每个适用的审计模式不变量对应一个区块。
• auditInvariantIds — 提示词中包含的不变量 ID。这是你的检查清单，也是你必须负责核查的分母。
• auditProjection — rendered、no-audit-entries 或 no-subject。no-subject 并不表示审计通过：该投影未解析出任何适用条目，因此没有评估任何内容。应将其视为尚未解决的门禁（目录未注册、投影范围过窄），并在结论中说明 — 绝不能将其视为通过。

回答 auditInvariantIds 中的每个 ID。 对每个 ID，阅读其在 auditPrompt 中对应的区块，根据它审查差异，并执行以下操作：

• 违反 → 生成一项发现，并通过 check_review_verdict 的 pluginFindings 传入，将 dimension 设为不变量 ID，并根据不变量自身的严重级别设置 severity（blocking → HIGH，advisory → MEDIUM）。
• 满足 → 在结论摘要中记录，使该 ID 得到明确说明。

未作答的审计模式不变量不算通过 — 它属于未运行的检查。如果不阅读 auditPrompt，目录中整个审计模式部分就会沦为摆设，而这正是该目录旨在防止的情况。

结论与修复循环

对合并后的发现集只计算一次结论。通过决策操作手册进行路由 — exarchos_orchestrate({ action: "runbook", id: "review-escalation" })。参见 references/convergence-and-verdict.md。

check_review_verdict 接收发现项计数和 pluginFindings，发出门禁事件，并返回 APPROVED 或 NEEDS_FIXES：

exarchos_orchestrate({
  action: "check_review_verdict",
  featureId: "<id>",
  high: nativeHighCount,
  medium: nativeMediumCount,
  low: nativeLowCount,
  pluginFindings: catalogFindings,
})

修复循环受共享升级策略限制（可通过配置解析的 escalation.maxIterations，默认为 5）——与 shepherd 循环使用相同的限制。check_review_verdict 会读取事件溯源的修复周期计数，并返回循环必须遵守的升级决策：

• 自动修复（未达到上限，机械性发现） — escalate 缺失或为假值：将发现项重新分派给实施者并重新审查。
• 升级给用户 — escalate: true：呈现发现项和 escalationReason，并询问如何继续；当达到上限或发现项涉及意图（会改变用户要求内容的 spec 问题——应由人工决定，而不是循环决定）时，均执行此操作。

**配套插件（取决于平台）：**在支持 skill 的平台上，编排器还可以针对前端差异调用 impeccable:critique；将其发现项作为额外的 pluginFindings 提供。

**门禁事件：**不要手动发出 gate.executed — check_review_verdict 会发出该事件。手动发出会造成重复。

必需的输出格式

子 Agent 必须返回一个结构化 JSON 结论。任何其他格式都属于错误。

{
  "verdict": "pass | fail | blocked",
  "summary": "1-2 sentence summary",
  "issues": [
    {
      "severity": "HIGH | MEDIUM | LOW",
      "category": "spec | tdd | coverage | security | solid | dry | perf | naming | test-quality | other",
      "file": "path/to/file",
      "line": 123,
      "description": "Issue description",
      "required_fix": "What must change"
    }
  ],
  "test_results": { "passed": 0, "failed": 0, "coverage_percent": 0 }
}

状态与转换

将结论记录为一个带有 status 字段的对象（扁平字符串会被守卫静默忽略）：

APPROVED：

exarchos_workflow({ action: "update", featureId: "<id>", updates: {
  reviews: { "review": { status: "pass", summary: "...", issues: [] } }
}})
exarchos_workflow({ action: "transition", featureId: "<id>", target: "synthesize" })

然后调用 synthesize。

NEEDS_FIXES：

exarchos_workflow({ action: "update", featureId: "<id>", updates: {
  reviews: { "review": { status: "fail", summary: "...", issues: [{ severity: "HIGH", file: "...", description: "..." }] } }
}})

然后调用 delegate --fixes。

守卫：review → synthesize 要求 all-reviews-passed — 每个必需维度的 reviews.{name}.status 都必须是通过值（不区分大小写的 pass | passed | approved | fixes-applied）。功能清单为 review（HIGH 层级时还包括 mutation-adequacy）。review → delegate 会在 any-review-failed 时触发。

所有转换都会自动进行——这不是人工检查点。参见 references/auto-transition.md。

反模式

不要	应改为
确认正确之处	寻找错误之处（采取对抗性立场）
不执行击杀探针就批准	阅读每项任务记录的 test-adequacy 结论（或对 settlement 未验证的任务运行 check_test_adequacy）——无法失败的测试不算覆盖
将审计模式中未回答的不变量视为通过	回答 auditInvariantIds 中的每个 id；未运行的检查不算通过
因为合理化说辞而照单全收	查阅 references/rationalization-refutation.md
放任范围蔓延	将预期与交付之间的偏差标记为 spec 问题
因低优先级的小问题而阻止流程	记录并跟踪；仅将 HIGH 问题作为阻断项

架构发现

使用 exarchos_workflow({ action: "describe", actions: ["update"] }) 和 exarchos_orchestrate({ action: "describe", actions: ["check_static_analysis", "check_security_scan", "check_test_adequacy", "check_review_verdict", "check_invariant_conformance", "prepare_review"] }) 获取当前参数架构。