---
name: done-means-verified-checklist
description: "Stops premature 'it works' claims by listing what is being claimed, running the checks, reading the output and stating the evidence. Use when work is about to be called finished and every claim of success needs proof from commands actually run. Do not use for planning the work or reviewing code style. Related topics: coding, productivity."
---

# Done-Means-Verified Checklist

Stops premature 'it works' claims by listing what is being claimed, running the checks, reading the output and stating the evidence.

## When to use

Use this skill when work is about to be called finished and every claim of success needs proof from commands actually run. Do not use it for planning the work or reviewing code style.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. List every claim the finished work implies, from passing tests to a bug no longer reproducing.
3. Run a fresh command for each claim and read its real output instead of reusing earlier results.
4. Mark each claim verified, failed or unverified with the quoted evidence or reason.
5. Compare the verified results against the requester's done criteria one by one.
6. Report what is proven, what is not, and what remains, leading with any failure.

## Inputs

- **What was changed** (longer free text)
- **Claims to verify** (longer free text)
- **Commands available** (longer free text)
- **Done criteria** (longer free text)
- **Evidence depth** (choose one: Quick, Standard, Exhaustive)

## Output

A claim table with columns claim, command, result and status, followed by a short plain statement of what is proven and what is outstanding.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Done-Means-Verified Checklist

Before I call this work complete, verify it and report only what the evidence supports.

- What was changed: {{What was changed}}
- Claims to verify: {{Claims to verify}}
- Commands available: {{Commands available}}
- Done criteria: {{Done criteria}}
- Evidence depth: {{Evidence depth}}

List every claim the work implies, such as 'tests pass', 'the build succeeds', 'the bug no longer reproduces', 'the page renders'. For each claim pick the command that would show it, run it fresh, and read the output rather than assuming it from memory or from an earlier run. Mark each claim as verified with the evidence quoted in a line, failed with the output, or unverified with the reason it could not be run. Check the done criteria one by one against the result. Report in plain words: what is proven, what is not, and what remains. Never use the words done or fixed for anything unverified, and if a check fails, say so first and plainly.

## Pitfalls

- Quoting a test result from before the last edit, which can be stale by the time of the claim.
- Treating a command that exited quietly as a pass when it never ran the relevant tests.
- Burying a failed check under a long list of passes.