Verification Before Completion

核心用法

该技能是一种强制性的自我检查协议，要求在声称工作完成、修复或通过之前，必须执行验证命令并确认输出结果。其核心流程为：识别验证命令 → 完整执行 → 读取输出 → 核实确认 → 才允许声明。

关键执行模式：

• 测试通过：必须运行测试命令，确认 0 失败
• 回归测试：必须完成红-绿周期验证（写测试→运行通过→回退修复→必须失败→恢复→通过）
• 构建成功：必须确认 exit 0，而非仅看 linter
• 需求完成：逐行核对清单，而非仅测试通过
• 代理完成：必须检查 VCS diff 独立验证

显著优点

• 根本性防错：从流程上消灭"应该有效"的幻觉，将诚实嵌入工作流
• 信任修复：解决"我不相信你了"的历史信任破裂问题
• 成本前置：避免"虚假完成 → 重定向 → 返工"的浪费循环
• 非例外设计：明确"违反字面即违反精神"，封堵所有绕行借口
• 多场景覆盖：涵盖测试、构建、回归、代理委托等全部宣称场景

潜在缺点与局限性

• 执行摩擦：每次声称前强制等待验证，可能打断心流
• 疲惫冲突：明确标注"累了想结束"是红旗场景，需对抗人性
• 无豁免机制：即使"就这一次"也不允许，极端情况可能僵化
• 代理开销：代理报告必须独立核实，增加协调成本
• 工具依赖：需有可行的验证命令，某些探索性工作可能难以定义

适合人群

• AI 助手/Agent：防止幻觉性完成声明
• 开发者：养成证据驱动的工作习惯
• 团队协作场景：建立可验证的交付标准
• 高信任要求环境：如安全关键、金融系统开发

常规风险

• 认知过载：24 条失败记忆的心理负担
• 规则绕过：尝试用"不同措辞"规避监管（已被封堵）
• 执行衰减：长期可能松懈，需持续强化
• 验证盲区：若验证命令本身设计不当，可能产生虚假安全感

核心用法

verification-before-completion 是一款纯文档型纪律约束 Skill，核心功能是阻断未经验证的成功声明。它强制要求在宣称"完成"、"修复"或"通过"之前，必须：

1. 识别验证命令——明确用什么命令能证明该声明
2. 完整执行——运行完整验证流程（非部分检查）
3. 阅读输出——检查 exit code、失败计数、实际输出
4. 证据锚定——仅当输出确认后才允许声明，并附带证据
5. 失败透明——若验证失败，必须如实报告实际状态

典型场景覆盖：单元测试（需看到 0 failures）、构建（需 exit 0）、回归测试（需红绿循环验证）、需求清单（需逐条核对）、Agent 委托（需独立 diff 验证）。

显著优点

• 根治虚假完成：通过"无验证不声明"的铁律，消灭"should work now""looks correct"等自欺欺人话术
• 信任修复机制：特别针对 Agent 报告、部分验证、疲劳作业等高风险场景设置红灯警示
• TDD 回归保障：强制要求红绿循环（故意 revert 看失败），防止伪回归测试
• 零执行成本：纯 Markdown 文档，无代码、无依赖、零性能开销
• 精神高于文字：明确声明"违反字面即违反精神"，封堵同义词/换说法的漏洞

潜在局限

• 人工执行依赖：本质为纪律文档，无法强制技术拦截，依赖使用者自律或外部审查
• 无自动化集成：未提供与 CI/CD、Git hooks 的自动绑定，需手动触发
• 情绪对抗设计：对疲劳、赶工等真实人性弱点缺乏缓冲机制，硬性排斥可能降低采纳意愿
• 上下文切换成本：严格流程可能拖慢快速迭代节奏，在探索性阶段显得过重

适合人群

• AI Agent 使用者：频繁委托子任务、需独立验证 Agent 报告的开发者
• TDD/严格测试实践者：需要红绿循环纪律保障的工程团队
• 信任受损场景：曾被"undefined function shipped""missing requirements"等问题教训过的项目
• 高可靠性要求领域：金融、医疗、基础设施等无法接受虚假完成的场景

常规风险

• 流程疲劳：长期严格执行可能导致机械走过场，形式化执行反而掩盖真实问题
• 例外合理化："just this once""I'm tired"等借口是文档明确标注的高危模式
• 过度验证：对无需严格验证的草稿/探索阶段过度应用，降低创造性效率

> 安全认证：S+ 顶级，纯文档无代码，零依赖零网络，GDPR/CCPA 合规。