Menü
当即将声明工作已完成、已修复或通过验证时，在提交代码或创建 PR 之前必须使用；要求先运行验证命令并确认输出，再做出任何成功声明；永远先拿证据，再做断言
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
在开展任何创造性工作之前必须使用：创建功能、构建组件、添加能力或修改行为。在动手实现前，先探索用户意图、需求并制定设计。
当同时面对 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 条失败记忆：
在以下情况之前，永远适用：
规则适用于：
验证没有捷径。
运行命令。阅读输出。然后再声明结果。
这一点没有商量余地。