review_mode 控制 build 阶段的自动代码审查强度。它形成一条真实梯度——off（零审查）→ standard（风险触发的每任务审查）→ thorough（每任务审查）——决定 Comet 何时加载 Superpowers 的 requesting-code-review、给哪些任务派审查者、做几轮自动修复。
这个机制的设计目标，是让低风险任务不被审查拖慢，同时让高风险变更能拿到即时的、聚焦的每任务审查，而不是拖到批次边界才抓问题。
review_mode 只管流程内的自动审查。此外还可以随时手动调用
/comet-review，对当前 change 做一次只读按需审查；它独立于
review_mode，也不推进工作流。详见
Skill 的类型与用途。模式选择
核心规则：review_mode 接管默认审查流，不双重审查
与 Superpowers SDD 的边界
Comet 的subagent-driven-development 扩展现在只依赖 Superpowers 公开的 task reviewer 合同：实现者完成任务后，协调者按任务材料、真实 diff、测试证据和风险信号决定是否派审查者。Comet 不读取、不写入、也不要求 Superpowers subagent-driven-development 的内部脚本名、workspace 路径或私有实现细节。
这意味着：
- Superpowers 仍提供连续任务调度、预检 plan review、文件型 handoff、reviewer 中立提示、“材料不足无法验证” 的反馈语义，以及 progress reconciliation。
- Comet 只接管 reviewer 触发策略和 review-fix 预算，也就是
review_mode决定哪些任务要 task reviewer。 - 文档、恢复和测试都以公开行为为准，不把 shipped Skill 文案绑定到 Superpowers 内部目录结构。
从用户角度看，你只需要在 build 阶段选择
off、standard 或 thorough。底层 Superpowers SDD
技能可以升级自己的实现，只要继续满足公开 task reviewer 合同，Comet 的审查策略就不需要改。build 阶段审查预算表
这张表只覆盖 build 阶段，且只派这些审查者，不额外增加：verify 阶段的审查不在这张表里。verify 阶段的审查由
verify_mode
（light/full）驱动，review_mode 只决定 verify 是否触发自动代码审查（off
跳过；standard/thorough 在 light 验证下跑一次轻量代码审查，在 full
验证下依赖 openspec-verify-change）。verify 阶段没有单独的 per-
review_mode”完整”代码审查——权威行为见 verify 阶段文档。
review_mode 是一条真实梯度：越往右审查越强，时间和 token 成本也越高
三种模式一图看懂
三种模式对比
off 模式（最低强度）
不派发任何自动 spec 审查者、代码质量审查者、最终审查者或审查修复 agent。任务是否完成，由实现者的自测、构建/测试证据、当前 worktree 确认和任务勾选验证决定。 off 模式必须在持久化产物（tasks.md、commit body、验证报告草稿等）里记录跳过自动代码审查的原因。- hotfix 和 tweak 预设默认
off。 - full workflow 也可以显式选
off，但离开 build 前必须确认这个选择并记录原因。
standard 模式（中等强度）
standard 不再是”只在最后审一次”。它形成一个风险触发的每任务审查 + 一次最终轻量审查的组合。build 阶段
- 默认不派发每任务审查者。实现者自测、提交、报告证据（包括风险信号自报）；coordinator 做针对性的勾选验证。
- 风险触发：读完实现者自报 + 审 diff 后，只有当自报命中任何风险信号，或 coordinator 的 diff 审查发现任何风险信号时，才给这个任务派一个每任务审查者，同时检查 spec 合规和代码质量。
- 风险任务的 CRITICAL/IMPORTANT 发现进入 1 轮 review-fix（最多 1 轮），复审未通过 → 标记 BLOCKED，暂停交给用户。
- 命中风险信号的任务直接走针对性勾选验证。
- 全部任务完成后，仍派发恰好 1 次最终轻量代码审查，范围限定在正确性、安全、边界条件。
- 最终审查发现 CRITICAL/IMPORTANT → 派最多 1 个修复 agent 并复审一次；仍未通过 → BLOCKED。非 CRITICAL 可接受并记录原因。
风险信号列表
命中以下任意一条即标记为风险任务（实现者自报 + coordinator diff 审查共同判定）：- 跨模块 / 跨子系统协调改动
- 安全敏感面：认证、授权、加密、SQL、外部输入处理、密钥/凭据
- 并发、锁、共享可变状态
- 数据或 schema 迁移
- 公共 API 契约或外部接口变更
- 实现者返回
DONE_WITH_CONCERNS - 单任务 diff 超过 200 行
thorough 模式（最高强度）
thorough 不再做”按批次合并审查”。高风险变更要求每个任务都拿到即时的、聚焦的审查——拖到批次边界才抓问题代价太大。build 阶段关键规则
- 每个任务都派一个每任务审查者（spec 合规 + 代码质量）：实现者自测、提交、报告证据后，coordinator 给这个任务派一个全新后台审查者。
- CRITICAL/IMPORTANT 发现进入 review-fix（最多 2 轮）；仍未通过 → 标记 BLOCKED，暂停交给用户。
- 全部任务后，派 1 个最终完整审查者。
- 最终审查最多 2 轮自动修复 + 复审；仍未通过 → BLOCKED。
thorough 不跑批次审查——高风险变更需要对每个任务
做即时、聚焦的审查。把问题拖到批次边界再抓代价太高。
为什么 thorough 慢且费 token
thorough 的开销是结构性的：N 个任务就会派 N 个每任务审查者 + 1 个最终审查者，每个审查者都可能触发最多 2 轮修复。对于 12 个任务的变更，standard 可能只给少数风险任务派审查者 + 1 次最终审查，而 thorough 会跑 12 次每任务审查 + 1 次最终审查——审查 + 修复的 agent 数量是 standard 的数倍。standard 和 thorough 的核心差异
每任务派发的模型选择（强制）
每一次实现者/修复者/审查者派发都必须显式指定模型。省略模型会静默继承会话里最贵的模型，拖慢执行并抬高成本。遵循 Superpowerssubagent-driven-development 的 Model Selection 规则：
省略模型 = 让它跑会话里最贵的模型，直接违背这条规则的目标。
与 build_mode 的配合
executing-plans review gate（按 review_mode 缩放）
executing-plans 下主会话直接执行任务（没有隔离的实现者子代理），所以没有 subagent-driven-development 那样的每任务审查者。代码审查针对已完成 diff，并按 review_mode 缩放：
review_mode: off：不做自动代码审查，不加载requesting-code-review。在验证报告草稿或 tasks.md 记录跳过原因。review_mode: standard：全部任务完成后、build → verify phase guard 之前，用 Skill 工具加载requesting-code-review做一次轻量代码审查（正确性、安全、边界），范围是整个变更。review_mode: thorough：除最终一次审查外，每 3 个任务做一次分段代码审查（按该段 diff 范围）。总任务 ≤ 3 时跳过中间分段，只做最终审查。每段审查用requesting-code-review针对该段 commit 区间。这是executing-plans能提供的、最接近subagent-driven-development每任务审查的等价物，因为它没有隔离实现者可逐任务审查。
requesting-code-review必须在comet-guard build --apply之前加载。- 如果 skill 不可用，跳过审查门禁，但在 tasks.md 记录
<!-- review skipped: skill unavailable -->。 - CRITICAL 发现（安全漏洞、数据丢失风险、构建/测试失败）必须在 verify 前修复。
- 非 CRITICAL 发现可以接受，但必须把原因和影响记录到持久化产物。
审查者怎么工作
在subagent-driven-development 下，审查者是全新的后台 agent，不是实现者的延续。审查者拿到的是完整任务、实现 commit/diff 和（开启 TDD 时）RED/GREEN 证据——审查者不能只看实现者的摘要就下结论。这保证审查基于真实代码而不是自述。
修复 agent 也是全新后台 agent，根据审查反馈独立修改代码。
进度检查点
coordinator 维护.comet/subagent-progress.md，记录每个任务的实现 commit、改动的文件、RED/GREEN 证据、所选 review_mode、已过的审查阶段、未解决的审查反馈、当前 review-fix 轮数（standard 最多 1、thorough 最多 2、off 为 0），以及 standard 模式下该任务是否已触发过风险每任务审查（恢复时不重复派发已完成的每任务审查）。
怎么设置
优先级
review_mode 的解析优先级：
.comet.yaml；hotfix/tweak 直接硬编码为 off。
从 0.4.0-beta.1 起，运行时 fallback 从
null（关闭）改为 standard
。也就是说，当 change 的 .comet.yaml、环境变量和项目配置都没有显式设置
review_mode 时，默认按 standard
（风险触发的每任务审查）处理，而不再是无审查。这适用于 init 模板、
classic-state-command.ts 运行时 fallback 和冻结的 0.3.9 契约 fixture。项目默认值
编辑.comet/config.yaml：
.comet.yaml。注意：环境变量和项目配置只在 resolver 层提供默认值，不影响已写入 change 的 review_mode。
单个 change
full workflow 在 build Step 3（执行方式选择）时由用户选择，通过comet-state 写入：
环境变量
review_mode。
硬约束（full workflow 离开 build）
review_mode 是 full workflow 的硬性门禁，由两层独立检查强制：
两层都必须通过才能离开 build。hotfix/tweak 豁免这个检查（它们默认
off）。
review_mode 不在 REQUIRED_CLASSIC_KEYS 里，这样 0.4.0 之前的
.comet.yaml 文件不用迁移就能解析。强制检查发生在 build→verify 的 transition
guard，旧文件缺少该字段时走兼容路径，恢复时应回填。非法值（非 off/
standard/thorough）会被枚举校验拒绝。状态转换交互
review_mode 是 build 阶段的门禁字段。它不会改变 transition event 的字段 effects，但会在 build-complete 前作为硬性决策被检查。相关转换：
build-complete→ 调用requireBuildDecisions（含 review_mode 检查），通过后phase: verify, verify_result: pending。verify-pass→ 要求verification_report存在且branch_status: pending，然后写入phase: archive, verify_result: pass；handled由 Archive 在最终交付确认后写入。verify-fail→verify_result: fail, phase: build（回滚，下次 build-complete 时 review_mode 必须再次满足）。
怎么选
下一步
- Classic 配置 — review_mode 字段和配置优先级
- build 阶段 — review_mode 在 build 中的使用位置和 build_mode 配合
- verify 阶段 — verify 中 light 路径的审查检查（由 verify_mode 驱动）
- 上下文压缩机制 — 另一个影响执行开销的项目配置项