/SKILL.md

name, description

name	description
verification-before-completion	在声称工作已完成、已修复或已通过、提交代码或创建 PR 之前使用——需要运行验证命令并确认输出后，才能做出任何成功声明；始终先有证据，后有断言

完成前验证

概述

未经验证就声称工作已完成，这不是高效，而是欺骗。

核心原则： 始终先有证据，后有断言。

违反本条规则的文字表述，就是违反本条规则的精神实质。

铁律

未经最新验证证据，不得做出完成声明

如果你没有在当前消息中运行验证命令，就不能声称它已通过。

关卡函数

在声称任何状态或表达满意之前：

1. 识别：什么命令能证明这个声明？
2. 运行：执行完整的命令（全新、完整）
3. 读取：完整输出，检查退出码，统计失败数
4. 验证：输出结果是否确认了该声明？
   - 如果否：用证据说明实际状态
   - 如果是：用证据支撑声明
5. 然后才能：做出声明

跳过任何一步 = 欺骗，而非验证

常见失败场景

声明	需要什么	不足以证明
测试通过	测试命令输出：0 个失败	之前的运行结果、"应该能通过"
代码检查通过	检查器输出：0 个错误	部分检查、外推推断
构建成功	构建命令：退出码 0	代码检查通过、日志看起来没问题
Bug 已修复	测试原始症状：通过	代码已改、假设已修复
回归测试有效	红-绿循环已验证	测试通过一次
代理已完成	VCS diff 显示有变更	代理报告"成功"
需求已满足	逐项检查清单	测试通过

危险信号——立即停止

• 使用"应该"、"可能"、"看起来"
• 在验证之前表达满意（"太好了！"、"完美！"、"搞定了！"等）
• 即将提交/推送/创建 PR 但未验证
• 相信代理的成功报告
• 依赖部分验证
• 心想"就这一次"
• 累了，想赶紧结束工作
• 任何暗示成功但未实际运行验证的措辞

合理化预防

借口	现实
"现在应该能行了"	运行验证
"我很确信"	确信 ≠ 证据
"就这一次"	没有例外
"代码检查通过了"	代码检查 ≠ 编译检查
"代理说成功了"	独立验证
"我累了"	疲惫 ≠ 借口
"部分检查就够了"	部分验证证明不了任何事
"用了不同的词，所以规则不适用"	精神实质优先于文字表述

关键模式

测试：

✅ [运行测试命令] [结果：34/34 通过] "所有测试通过"
❌ "现在应该能通过了" / "看起来没问题"

回归测试（TDD 红-绿）：

✅ 编写 → 运行（通过）→ 撤销修复 → 运行（必须失败）→ 恢复修复 → 运行（通过）
❌ "我写了一个回归测试"（未经红-绿验证）

构建：

✅ [运行构建] [结果：退出码 0] "构建通过"
❌ "代码检查通过了"（代码检查不检查编译）

需求：

✅ 重新阅读方案 → 创建检查清单 → 逐项验证 → 报告差距或完成情况
❌ "测试通过了，阶段完成"

代理委派：

✅ 代理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 相信代理的报告

为什么这很重要

来自 24 条失败记录：

• 你的人类伙伴说"我不相信你"——信任已破裂
• 未定义的函数已发布——会崩溃
• 缺失的需求已发布——功能不完整
• 时间浪费在虚假完成上 → 重新定向 → 返工
• 违反："诚实是核心价值观。如果你撒谎，你将被替换。"

何时应用

在以下场景之前始终执行：

• 任何形式的成功/完成声明
• 任何形式的满意表达
• 任何关于工作状态的正面陈述
• 提交代码、创建 PR、完成任务
• 进入下一个任务
• 委派给代理

本规则适用于：

• 确切的措辞
• 转述和同义词
• 暗示成功
• 任何暗示完成/正确的沟通

底线

验证没有捷径。

运行命令。读取输出。然后才能声明结果。

这是没有商量余地的。