القائمة
当即将声明工作已完成、已修复或通过验证时，在提交代码或创建 PR 之前必须使用；要求先运行验证命令并确认输出，再做出任何成功声明；永远先拿证据，再做断言
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在开展任何创造性工作之前必须使用：创建功能、构建组件、添加能力或修改行为。在动手实现前，先探索用户意图、需求并制定设计。
当同时面对 2 个及以上相互独立、无共享状态且无顺序依赖的任务时必须使用本技能
当需要在一个独立会话中执行已撰写的实现计划，并通过检查点进行复核时必须使用
当实现完成、所有测试通过且需要决定如何集成工作时必须使用——通过呈现结构化的本地合并、创建 PR 或清理工作树等选项，指导开发工作的收尾
当收到代码审查反馈、准备采纳建议前必须使用，尤其当反馈表述不清或技术上可疑时——要求技术严谨与验证，禁止表面附和或盲目执行
当完成任务、实现主要功能或在合并前需要验证工作是否符合要求时必须使用
| name | verification-before-completion |
| description | 当即将声明工作已完成、已修复或通过验证时，在提交代码或创建 PR 之前必须使用；要求先运行验证命令并确认输出，再做出任何成功声明；永远先拿证据，再做断言 |
在未经验证的情况下宣称工作完成，这不是高效，而是不诚实。
核心原则： 永远先拿证据，再做声明。
违背规则的字面含义，就是违背规则的精神实质。
没有新的验证证据，就不得声明完成
如果你在当前对话中尚未运行验证命令，就不能声称它通过。
在声明任何状态或表达满意之前：
1. 识别：什么命令能证明这个声明？
2. 执行：运行完整命令（全新、完整）
3. 阅读：查看完整输出，检查退出码，统计失败数
4. 验证：输出是否证实了声明？
- 否：基于证据说明实际状态
- 是：带着证据做出声明
5. 只有完成后：才做出声明
跳过任何一步 = 说谎，而不是验证
| 声明 | 需要 | 不足够 |
|---|---|---|
| 测试通过 | 测试命令输出：0 失败 | 上次运行过、"应该能过" |
| 代码规范通过 | Linter 输出：0 错误 | 只检查了部分、推测 |
| 构建成功 | 构建命令：退出码 0 | Linter 通过、日志看起来正常 |
| Bug 已修复 | 测试原始症状：通过 | 代码改了，默认已修复 |
| 回归测试有效 | 红绿循环已验证 | 测试只通过一次 |
| Agent 已完成 | VCS diff 显示变更 | Agent 报告"成功" |
| 需求已满足 | 逐条核对清单 | 测试通过 |
| 借口 | 现实 |
|---|---|
| "现在应该能用了" | 去运行验证 |
| "我很自信" | 自信 ≠ 证据 |
| "就这一次" | 没有例外 |
| "Linter 通过了" | Linter ≠ 编译器 |
| "Agent 说成功了" | 要独立验证 |
| "我累了" | 疲惫 ≠ 借口 |
| "部分检查就够了" | 部分证明不了什么 |
| "换种说法就不算" | 精神高于字面 |
测试：
✅ [运行测试命令] [看到：34/34 通过] "所有测试通过"
❌ "现在应该能过" / "看起来对了"
回归测试（TDD 红-绿）：
✅ 编写 → 运行（通过）→ 回退修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我已经写了回归测试"（未经过红绿验证）
构建：
✅ [运行构建] [看到：退出码 0] "构建通过"
❌ "Linter 通过了"（linter 不检查编译）
需求：
✅ 重读计划 → 创建核对清单 → 逐项验证 → 报告缺口或完成情况
❌ "测试通过，阶段完成"
Agent 委派：
✅ Agent 报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 轻信 Agent 报告
来自 24 条失败记忆：
在以下情况之前，永远适用：
规则适用于：
验证没有捷径。
运行命令。阅读输出。然后再声明结果。
这一点没有商量余地。