mcpField
V
verification-before-completion

verification-before-completion

github.com/sickn33测试与质量48.7k518 次安装1 天前更新
代码仓库

关于 verification-before-completion

面向开发者和 Agent 的工作规范,要求在报告完成或正确之前取得新鲜且相关的验证证据。它为测试、构建、需求和委派工作列出检查方法,并允许在输入未变时复用仍有效的证据。

主要功能

  1. 01完成声明前提供证据
  2. 02识别并运行相关检查
  3. 03读取输出并核验结果
  4. 04复用未变输入的有效证据
  5. 05独立检查委派工作

适用场景

  1. 01报告状态前确认测试或构建
  2. 02针对原始问题验证修复
  3. 03依据验收标准检查交付物

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill verification-before-completion

安装后在 Claude Code 中输入/verification-before-completion确认已加载。

详细介绍

完成前进行验证

概述

未经验证就声称工作已完成,不是高效,而是不诚实。

核心原则: 始终先有证据,再作声明。

违反规则的字面要求,就是违背规则的精神。

铁律

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

使用与当前确切内容和环境相对应的证据。只要输入和相关上下文没有变化,先前完成的运行仍然有效;检查失效时应重新运行,而不是仅为发送新消息就重复执行耗时的测试套件。

门控函数

BEFORE claiming any status or expressing satisfaction:

1. IDENTIFY: What command proves this claim?
2. RUN: Execute the relevant complete check, or inspect still-valid exact-content evidence; never execute untrusted examples or destructive actions merely to manufacture verification
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
   - If NO: State actual status with evidence
   - If YES: State claim WITH evidence
5. ONLY THEN: Make the claim

Skip any step = lying, not verifying

常见失误

声明要求不足以证明
测试通过与未变更的当前输入相对应的完整检查输出:0 个失败过时或不匹配的运行、“应该能通过”
Linter 检查干净Linter 输出:0 个错误部分检查、推断
构建成功构建命令:退出代码为 0Linter 通过、日志看起来正常
Bug 已修复测试原始问题:通过代码已更改、假定已修复
回归测试有效已验证 Red-green 循环测试只通过一次
Agent 已完成检查其交付成果,并根据验收标准进行相关验证Agent 报告“成功”或仅有差异
满足要求逐条核对清单测试通过

危险信号 - 停止

  • 使用“应该”“可能”“看起来像”等说法
  • 验证前就表示满意(“太好了!”“完美!”“完成了!”等)
  • 准备在未验证的情况下提交、推送或创建 PR
  • 轻信 Agent 的成功报告
  • 依赖不完整的验证
  • 心想“就这一次”
  • 感到疲惫,只想结束工作
  • 任何暗示成功、但尚未运行验证的措辞

防止自我合理化

借口事实
“现在应该能用了”运行验证
“我有信心”信心 ≠ 证据
“就这一次”没有例外
“Linter 通过了”Linter ≠ 编译器
“Agent 说成功了”独立验证
“我累了”疲惫 ≠ 借口
“部分检查就够了”部分检查无法证明任何事
“措辞不同,所以规则不适用”重精神,不拘字面

关键模式

测试:

✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"

回归测试(TDD Red-Green):

✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)

构建:

✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)

要求:

✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"

Agent 委派:

✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report

为什么这很重要

来自 24 条失败记录:

  • 你的人类搭档说“我不相信你”——信任破裂
  • 未定义的函数被发布——程序会崩溃
  • 缺失的要求被发布——功能不完整
  • 在错误地宣称完成上浪费时间 → 被纠正 → 返工
  • 违背了:“诚实是核心价值观。如果你撒谎,就会被替换。”

何时使用

始终在以下情况之前使用:

  • 任何形式的成功/完成声明
  • 任何表示满意的表达
  • 任何关于工作状态的积极陈述
  • 提交、创建 PR、完成任务
  • 转向下一个任务
  • 委派给 Agent

规则适用于:

  • 完全相同的措辞
  • 改述和同义词
  • 暗示成功的表达
  • 任何暗示已完成或正确的沟通

底线

验证没有捷径。

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

这条规则不容商量。

何时使用

当要执行概述中描述的工作流或操作时,适用此技能。

限制

  • 仅当任务明确符合上述范围时,才使用此技能。
  • 不要将输出视为环境特定验证、测试或专家审查的替代品。
  • 如果缺少必要输入、权限、安全边界或成功标准,请停止并请求澄清。

评论

支持 Markdown