mcpField
V
verification-before-completion

verification-before-completion

github.com/legoutTesting & quality038 installsUpdated 1w ago
Repository

About verification-before-completion

A verification skill for agents that requires evidence matching the surface of each completion claim before reporting success, committing, or opening a PR. It also directs agents to inspect changes, assess findings, and report what remains unverified.

Key features

  1. 01Claim-specific verification evidence
  2. 02Checks run against the claimed surface
  3. 03Output and exit-status review
  4. 04VCS diff inspection
  5. 05Finding disposition and evidence-based reporting

Use cases

  1. 01Verify a bug fix before reporting completion
  2. 02Check a build or test claim on its target surface
  3. 03Review delegated file changes before a commit
  4. 04Report failures and remaining unverified work

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/legout/skills --skill verification-before-completion

After installing, type/verification-before-completionin Claude Code to confirm it loaded.

Details

From the project README

Adapted from obra/superpowers at commit b36e0829c6d0140e93cfef2ca599b1b07d4a7797 (MIT).

Same-surface proof discipline is adapted from Cursor's poteto-mode at commit 93b00b89ef425a9c1bac0d0b317dfc49c930ac99 (MIT, Copyright (c) 2026 Cursor).

Verification before completion

NO COMPLETION CLAIMS WITHOUT VERIFICATION EVIDENCE MATCHING THE CLAIM

Before a success claim, commit, or PR:

  1. Identify the command or observation that proves each claim, exercised on the same surface the claim names.
  2. Base the claim on applicable evidence: run that focused check now, or reuse verified evidence whose relevant code, tests, inputs, and environment still match — an identical tree is a sufficient case, not the only one. Add no test or command without a named reachable scenario; coverage percentage and duplicate evidence are not goals. Required project checks still apply. Current-state claims (a service running now, an artifact present now) need current observation; past results do not establish them.
  3. Read its full relevant output and check exit status and failure counts.
  4. Inspect the VCS diff for delegated or file-changing work.
  5. Restate the approved task in one sentence, compare the result against its requirements and written conventions, and choose accept / fix / hand back / ask. Extra ideas get one line, not code. Disposition reviewer findings before repairing: reject failed gates, fix small in-scope violations, hand large/out-of-scope work to the human. One fix pass and one delta recheck; unresolved findings go to the human rather than another round.
  6. Report the actual result with evidence. If a check fails or was not run, say so, and name what remains unverified. Handoffs, commits, and identical-content merges do not invalidate still-applicable evidence; a rerun needs a relevant delta or a specific hypothesis, not a "final" label.

Evidence must match the claim's surface: compilation proves compilation, and a unit test proves only the behavior it exercises. Match examples to their claim — rendered UI for UI claims, a built or installed CLI for CLI claims, a restart-and-read for persistence claims, and transformed data plus stale-path checks for migration claims. Tests do not prove a build, lint does not prove types, code changes do not prove a bug is fixed, and an agent report does not prove its work. A regression test is credible only after the intended red/green behavior is observed when practical.

Never weaken assertions, skip failing checks, present stale or never-run checks as proof, or use “should”, “probably”, or “seems” as a substitute for evidence. A failing check does not authorize broader suites, relaxed expectations, or repeat-until-green: investigate the named failure, then stop or escalate.

Comments

Markdown supported