# Verification Before Completion

> 在宣称工作完成、已修复或测试通过之前使用，即使用户要求跳过验证或直接宣布成功；提交或创建 PR 之前必须运行验证命令并确认输出后才能声称成功，始终用证据支撑断言

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

---


# 完成前验证

## 概述

在没有新鲜证据的情况下宣称完成、修复或通过检查，会把假设误报为事实。

**核心原则：** 结论必须由与其范围匹配的验证证据支撑。

## 铁律

```
没有新鲜的验证证据，不许宣称完成
```

## 验证门控

在作出任何完成性结论或表达满意之前：

1. **定义结论**：明确要声称什么，以及结论覆盖哪些文件、测试、环境或需求。
2. **选择证据**：确定能直接证明该结论的命令、检查或实际操作；文档、旧日志和主观判断不能替代新鲜证据。
3. **执行验证**：重新运行适用的完整检查，不把上一次运行结果当作当前代码的证据。
4. **检查结果**：确认退出码、关键输出、失败数量和验证范围；日志很长时可聚焦摘要和错误，但不得跳过结果核对。
5. **匹配结论**：只有证据覆盖结论范围时才能宣称成功；否则明确说明已验证、未验证和失败的部分。

跳过其中任何一步，都不能作出对应的完成性声明。

## 按结论选择证据

| 结论 | 足够的证据 | 不足的证据 |
|------|------------|------------|
| 测试通过 | 目标范围内的测试命令成功，且确认失败数为 0 | 之前的运行结果、只运行部分测试、"应该能通过" |
| Linter 无报错 | 覆盖声明范围的 linter 成功，且确认错误数为 0 | 格式化成功、部分文件检查、代码阅读推断 |
| 类型检查通过 | 目标项目的类型检查成功并退出 0 | linter 通过、编辑器没有显示错误 |
| 构建成功 | 实际构建命令成功并退出 0 | 测试或 linter 通过、日志看起来正常 |
| Bug 已修复 | 原始失败场景或对应回归测试在最新代码上通过 | 代码已修改、测试未覆盖原始症状 |
| 回归测试有效 | 必要时验证红—绿过程：修改前失败、修复后通过 | 只新增测试并运行一次 |
| 代理任务已完成 | 检查实际 diff、变更文件、需求清单和相关验证证据 | 代理报告成功、只看到有 VCS diff |
| 需求已满足 | 逐项核对需求和验收标准，并为关键项提供证据 | 仅测试通过、仅代码审查通过 |
| MCP 调用结果正确 | 实际调用成功，并核对返回结构、关键字段和预期语义 | 只看到调用日志或无错误返回 |
| API 接口可用 | 在允许的验证环境中实际调用，并核对状态码、响应结构和关键业务结果 | 只看 Swagger、类型定义或 mock 结果 |

## 验证范围规则

- 验证范围必须覆盖结论范围；单文件、单包或单场景检查不能证明整个项目完成。
- 只验证了部分内容时，使用范围准确的表述，例如“目标测试通过，类型检查尚未执行”。
- 外部服务、API 和 MCP 验证必须考虑环境、权限、数据副作用和安全边界；无法安全实际调用时，应明确标记为未验证。
- 代码审查、VCS diff 和代理报告可以作为辅助证据，但不能单独替代运行验证或需求验收。
- 提交、创建 PR、标记任务完成或进入下一任务前，必须重新确认最新代码的相关验证证据。

## 验收标准

当完成结论包含“需求已满足”“验收通过”或“功能完成”时：

1. 使用已确认的需求、验收标准或测试用例作为验收依据。
2. 将验收依据拆分为可独立判断的验收项，逐项核对，不能用整体印象替代。
3. 每项验收记录结果和证据，至少区分通过、失败、未验证和不适用。
4. 验证范围不足时，只能声明已验证范围，不得扩大为整体完成。
5. 发现需求缺失、标准冲突或范围变更时，先返回方案阶段确认，不得在验收阶段自行补充。
6. 测试通过、代码审查通过或代理报告成功，均不能单独证明需求已满足。

## 红线

- 使用“应该”“大概”“似乎”等推测性结论替代验证。
- 验证前表达“太好了”“完美”“搞定”等暗示成功的措辞。
- 因为代码改动很小、代理声称成功或之前检查通过而跳过最新验证。
- 用较窄范围的检查支撑较宽范围的完成声明。
- 验证失败或未执行时，隐瞒实际状态或继续声称成功。

## 何时使用

任何传达完成、正确、已修复、已通过或可合并含义的沟通之前，包括提交、PR、任务收口和阶段切换。

## References 读取条件

| 文件 | 什么时候读 |
|------|-----------|
| `references/anti-rationalization.md` | 感到时间紧迫、疲惫，或开始寻找跳过验证的理由时 |

## 底线

**验证没有捷径。** 运行适用检查，核对新鲜输出，再根据证据准确陈述结果。