用途：验证实现是否满足明确的验收标准，且以实际运行结果为依据，而非阅读 diff 后凭外观判断。适用于确认修复真正解决了报告的问题、为循环或阶段完成提供独立行为检查、核对每条需求是否被测试覆盖。首轮代码质量审查、设计红队审查、开工前前提核查等场景应改用其他技能。
主要能力：先执行完整测试套件、类型检查与 lint 并保存输出作为证据；为每条验收标准建立台账行（标准→证据→判定）；无执行证据的标准判为 UNVERIFIED 而非默认通过；对往返、确定性、可复现、幂等类声明，额外核对测试的操作序列是否复现生产调用路径，序列不一致则判 UNVERIFIED；由隔离的验证者仅读取标准、diff 与执行证据，不读作者的计划或理由；失败后最多修订一轮，第三轮视为结构性问题需上报人工。
使用方式：解析参数，目标可为路径、PR 引用、指定文件，缺省时默认当前变更（git diff HEAD 加暂存区）；可用 --criteria 指定验收标准文件，缺省则从上下文任务或计划中收集并回显确认。按技术栈运行套件，例如 Node/TS 用 npm test、npx tsc --noEmit、npx biome check；Python 用 uv run pytest -q、uv run ty check、uv run ruff check；Rust 用 cargo test、cargo check、cargo clippy；Go 用 go test ./...、go vet ./...。随后以 opus 模型派发单个验证者，输出绑定 LEDGER schema，包含 rows、coverage、verdict，每行含 criterion、evidence、verdict（PASS/FAIL/PARTIAL/UNVERIFIED）、sequenceMatchesProduction（yes/no/not-applicable）。整体判定为 pass 需所有行 PASS 且无序列不一致。多个独立目标可并行派发，但在 1M 上下文模型上需串行。
限制：标准列表为空时应停止并索取；不设置 context: fork，调用方需在主上下文获得台账；不编造规格未声明的要求；不因验证者沉默而反复循环。具体安装命令与收费信息暂未提供。