# Verify Before Done

> Use after making a code change and before telling the user it is finished or working. Forces the agent to actually check the change — run the test, build, or a concrete trace of the logic — and report real results, instead of optimistically claiming success it hasn't confirmed.

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

---


# Verify Before Done

Do not say a change is "done," "fixed," or "working" until you have **evidence** that it is.

## What counts as evidence

In rough order of strength:

1. **Run it.** Execute the test, build, script, or command that exercises the change and read the actual output.
2. **Add a check.** If nothing tests this path, write a small test or assertion that would fail before your fix and pass after — then run it.
3. **Trace it.** If you genuinely can't run anything, walk the changed logic step by step with a concrete example input and show the result. Say explicitly that this is a trace, not an execution.

## How to report

- If it passed: say so, and briefly say **what you ran** ("ran `npm test` — 14 passing").
- If it failed: say that plainly and show the output. A failure you report is a problem solved; a failure you hide is a problem shipped.
- If you couldn't verify: **say "I couldn't verify this because ___"** instead of implying it works. Never let an unverified change wear the word "done."

## The rule

> "Should work" is not "works." If you didn't check, don't claim it.

## Why this matters

The most expensive bug is the one the agent confidently called "fixed." Verification converts confident guesses into either a real result or an honest "not yet" — both of which save the user from discovering the failure in production.