技能介绍

要解决什么问题

把代码改到「能合并」往往不是靠一次生成就能结束：测试红、lint 报错、评审意见来回，Agent 若只输出一版就停，负担会回到人身上。更糟的是无边界重试——同一 diff 跑两轮仍失败，继续「再试一次」只是在空转。

Verification Loop 针对的是有可机械验证信号的改动：在提交前用闭环把实现、自检、自动化检查与（可选）委派评审串起来，并留下可审计记录（测了什么、何时、由谁触发），收敛后再交给 commit-gate。

如何工作

核心思路是 modify → verify → fix → re-verify，每一轮都要消费当轮反馈，而不是把多轮评审意见攒到最后一次性改。

三条反馈通道：

自动化检查（快）：npm/cargo/vitest/tsc 等测试、构建、lint、类型检查，每轮必跑，失败即停在本轮修复
委派评审（深）：自动化全绿后再调 boundary-auditor 或 qa-verifier，看架构边界、质量与覆盖率
自检（等价于人眼扫 diff）：确认无 scope creep、无残留 debug、无意外副作用

完成定义必须是可机械判定的条件（例如「全部测试通过且覆盖率 ≥ X%」），不能写「看起来没问题」。默认最多 8 轮；若连续两轮 git diff 实质相同，必须立刻进入 stuck 诊断，而不是重复同一招。

典型流程：澄清 done 条件 → 实现首版 → 循环（实现 / 自检 / 测试 / 评审 / 修复）→ 更新 exec-plan 勾选与决策日志 → 收敛后输出摘要（做了什么、如何验证、已知限制）→ 交给 harness-commit-gate 提交。

适用边界与硬约束

适合：用户明确要求推进到可合并状态；可验证任务反复失败需要迭代；要建立提交前自检流程。

不适合：单行配置或 typo（直接 commit-gate）；项目没有任何测试/构建/lint（循环没有反馈，只会空转）；纯探索无代码产出；改动极小且已有 gate 时不必开 8 轮。

硬约束包括：不可逆操作、产品权衡、安全敏感决策必须升级给人；不得改架构文档或 exec-plan 目标（只动业务代码与测试）。未在轮次上限内收敛时，必须写清卡在哪、缺什么能力，禁止假装完成。 flaky 测试要先复现模式再记入 known limitations，避免把间歇失败当回归。