# Verification Before Completion

> Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

- Skill: `zouyangxiaohao111/verification-before-completion` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zouyangxiaohao111/verification-before-completion`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zouyangxiaohao111/verification-before-completion/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zouyangxiaohao111 (https://skillmd.com/u/zouyangxiaohao111)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zouyangxiaohao111/verification-before-completion

---


# 完成前验证

## 概述

在没有验证的情况下声称工作完成是不诚实，而非高效。

**核心原则：** 证据先于声明，始终如此。

**违反规则的字面意思就是违反规则的精神。**

## 铁律

```
没有新鲜的验证证据，不得声称完成
```

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

## 关卡函数

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

1. 识别：什么命令能证明这个声明？
2. 运行：执行完整命令（新鲜的、完整的）
3. 阅读：完整输出，检查退出码，计算失败数
4. 验证：输出是否确认声明？
   - 如果否：陈述实际状态并附证据
   - 如果是：陈述声明并附证据
5. 只有这样：做出声明

跳过任何步骤 = 撒谎，不是验证
```

## 常见失败

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

## 危险信号 - 停止

- 使用"应该"、"可能"、"看起来"
- 在验证之前表达满意（"太好了！"、"完美！"、"完成！"等）
- 在没有验证的情况下即将提交/推送/PR
- 信任代理成功报告
- 依赖部分验证
- 认为"就这一次"
- 疲惫并想结束工作
- **任何暗示成功但未运行验证的措辞**

## 借口预防

| 借口 | 现实 |
|------|------|
| "现在应该可以了" | 运行验证 |
| "我有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "Linter 通过了" | Linter ≠ 编译器 |
| "代理说成功了" | 独立验证 |
| "我累了" | 疲惫 ≠ 借口 |
| "部分检查就够了" | 部分证明不了什么 |
| "措辞不同所以规则不适用" | 精神高于字面 |

## 关键模式

**测试：**
```
✅ [运行测试命令] [看到：34/34 通过] "所有测试通过"
❌ "现在应该通过了" / "看起来正确"
```

**回归测试（TDD 红-绿）：**
```
✅ 编写 → 运行（通过）→ 还原修复 → 运行（必须失败）→ 恢复 → 运行（通过）
❌ "我写了一个回归测试"（没有红-绿验证）
```

**构建：**
```
✅ [运行构建] [看到：退出码 0] "构建通过"
❌ "Linter 通过了"（linter 不检查编译）
```

**需求：**
```
✅ 重读计划 → 创建检查清单 → 验证每一项 → 报告差距或完成
❌ "测试通过，阶段完成"
```

**代理委托：**
```
✅ 代理报告成功 → 检查 VCS diff → 验证更改 → 报告实际状态
❌ 信任代理报告
```

## 为什么这很重要

来自 24 个失败记忆：
- 你的合作伙伴说"我不相信你" — 信任破裂
- 未定义的函数被发布 — 会崩溃
- 缺失的需求被发布 — 不完整的功能
- 时间浪费在虚假完成 → 重定向 → 返工
- 违反："诚实是核心价值观。如果你撒谎，你会被替换。"

## 何时应用

**始终在之前：**
- 任何成功/完成声明的变体
- 任何满意的表达
- 任何关于工作状态的积极陈述
- 提交、PR 创建、任务完成
- 转移到下一个任务
- 委托给代理

**规则适用于：**
- 确切短语
- 释义和同义词
- 成功的暗示
- 任何暗示完成/正确性的沟通

## 底线

**验证没有捷径。**

运行命令。阅读输出。然后声称结果。

这是不可协商的。