SKILL 执行结果验证器

要解决什么问题

其它 skill 跑完后，输出往往是一批文件或一段结论：数量一多，很难确认有没有漏改、写错路径、边界 case 没覆盖，或者和任务描述对不上。人工 spot check 容易漏；让执行同一个 skill 的模型「再检查一遍」又容易变成替结果辩护。这个验证器把质控当成独立环节：发现问题就写进报告，不粉饰。

它怎么工作

用口语触发即可，例如「验证一下」「帮我检查对不对」，默认从当前会话里推断被验证的 skill、任务和输出路径。若上下文不够，会先追问再动手。

分层策略（按批量文件总数自动选，无需你记规则）：

• L1 全查：文件 ≤10，逐个核查
• L2 抽样：11～100 个，约 30%，至少 3 个，并尽量覆盖多种类型
• L3 深度：100+ 个，约 10%，至少 20 个，偏重核心数据

流程上大致是：明确上下文 → 定层级 → 按文件类型走专项检查表 → 再做 5 维度逐项核对 → 按模板输出带编号的验证报告。严重问题（❌）只报告、等你指示，不静默改库；轻微问题（⚠️）会附建议并询问是否处理；全过（✅）则简短确认。

首次使用还会在报告末尾问你是否希望其它 skill 执行完后自动挂本验证器；若选「是」，会在 SOUL.md 工作标准区追加自动验证规则（已有则跳过）。

边界与注意

验证器不会对自己再跑一遍验证，避免死循环。skill 本身的设计缺陷会在报告里点出，但不会擅自改被验证的 skill 定义。验证是帮忙找遗漏和边界问题，不是找茬否定整次任务；修复建议会给具体步骤，是否执行仍由你决定。