Verify Done

Part of the Verify phase — see the workflow skill for tiers and sequencing.

Claiming work is complete without verification is dishonesty, not efficiency.

The Iron Law: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.

If you haven't run the verification command in this message, you cannot claim it passes.

Why this matters more here

The user reviews outcomes, not code. Evidence — command output, test summaries, screenshots, preview URLs — is the only thing they can judge. An unverified "done" that turns out broken doesn't just cost rework; it breaks the trust the whole PM ↔ engineer division of labor depends on. One false "it works" costs more than ten honest "it's not working yet"s.

The gate function

BEFORE claiming any status or expressing satisfaction:

1. IDENTIFY: what command proves this claim?
2. RUN: the FULL command (fresh, complete)
3. READ: full output, exit code, failure count
4. VERIFY: does the output confirm the claim?
   - NO  → state the actual status, with the evidence
   - YES → state the claim WITH the evidence
5. ONLY THEN: make the claim

Skip any step = lying, not verifying.

What each claim requires

The Spec check

"It works" and "it's what was asked" are different claims. Verify both, on separate axes:

• Spec axis — does the diff match what was asked? The spec source is the brief output (or the plan file from plan). Walk the diff against it line by line and report: (a) requirements missing or partial, (b) behavior nobody asked for (scope creep), (c) requirements that look implemented but wrong.
• Standards axis — does the code follow this repo's conventions (AGENTS.md/CLAUDE.md, folder CONTEXT.md, documented standards)?

Report the axes separately and never rerank across them: passing tests cannot excuse a missed requirement, and a faithful diff cannot excuse a convention break. A change can pass one axis and fail the other — merging the reports lets one axis mask the other. If there is no brief or plan, say "no spec available" in the report; don't invent one.

At T3, the two axes MAY run as parallel subagents (see delegate) so neither pollutes the other's context; aggregate their findings without merging.

QA tiers (anything with a browser surface)

QA depth scales with the tier (see workflow). Evidence = the checks run and their results, not "the page looked fine".

A failed check is fixed before "done" or reported as a known issue — never silently shipped. For the recurring production failure modes (caching, env vars, images, third-party integrations), check references/web-bug-patterns.md.

Evidence for a non-coding reviewer

Every completion claim ships with evidence the user can judge directly:

• The exact commands run and their trimmed output (pass/fail counts, exit code).
• For UI changes: a screenshot or a preview URL they can click through.
• For behavior changes: what to do to see it working ("submit the form empty — you'll now see the error message").
• For T3 work: the checklist of spec requirements, each marked verified.

"The code looks correct" is not evidence. Show the thing working.

Red flags — STOP

• "Should", "probably", "seems to"
• Expressing satisfaction before verification ("Great!", "Done!", "Perfect!")
• About to commit/push/PR without running verification
• Trusting a subagent's success report without checking the diff
• Partial verification presented as full
• Tired and wanting the work to be over
• ANY wording implying success without having run the check

Rationalization prevention

Key patterns

✅ [run test command] [see: 34/34 pass] → "All tests pass."
❌ "Should pass now" / "Looks correct"

Regression test (red-green):
✅ Write → run (pass) → revert fix → run (MUST FAIL) → restore → run (pass)
❌ "I've written a regression test" (never seen red)

Requirements:
✅ Re-read brief/plan → diff vs each line → report gaps or completion
❌ "Tests pass, phase complete"

When to apply

Before ANY success/completion claim or expression of satisfaction; before committing, PR creation, or moving to the next task; before reporting a subagent's work as done. Applies to paraphrases and implications, not just the exact words.

Run the command. Read the output. THEN claim the result. Non-negotiable.

Adapted from superpowers (MIT, © 2025 Jesse Vincent), mattpocock-skills (MIT, © 2026 Matt Pocock), and rampstack-skills (MIT, © 2026 RampStack Co.); see ATTRIBUTION.md.