| name | verifying-before-shipping |
| description | Use when about to declare any piece of work done, complete, shipped, or finished - in any domain |
| kind | discipline |
| audience | anyone |
| ai-tools | any |
| complexity | simple |
| time | 2-10 min |
| version | 1.0.0 |
| source | bundled |
If you were dispatched as a subagent for a specific task, skip this skill and complete your assigned task. The parent already invoked discipline.
Verifying Before Shipping
What this does
Forces a verification pass before any "this is done" declaration. Works for shipped code, sent docs, published posts, completed tasks, and finished plans.
When to use
- About to mark a task done in a tracker
- About to send a "this is shipped" message
- About to close a ticket / PR / case
- About to tell someone "all set"
What you bring (Inputs)
- The work being declared done
- The original definition of done (or an inferred one if none was set)
What you get (Output)
Either: confirmation the work is genuinely done (and a "done" declaration), or a list of the specific gaps that must close first.
How it works (Steps)
This is a discipline. The behavioral structure is: a non-negotiable rule (below), an excuses-and-counters table to defeat rationalizations, warning signs to spot the moment of risk, and a hard gate that fires before any "done" declaration. Apply the gate; verify each acceptance criterion against actual evidence; declare done only on a clean pass.
The non-negotiable rule
Before declaring any work done, run the verification — actually run it, do not assert it from memory.
Excuses and counters
| If you think... | Reality |
|---|
| "I just finished it, of course it works" | Just-finished work has the highest bug density. Verify. |
| "I already manually checked everything" | Manual checking is unreliable. Run the verification step. |
| "The user is in a hurry" | The user is more in a hurry to not have a regression. Verify. |
| "It's a tiny change" | Tiny changes break things in small ways that are hard to find later. Verify. |
| "I'll verify and ship in parallel" | "In parallel" usually means "ship now and verify if there's a complaint." Verify first. |
| "Verification is overkill for this" | Then you don't actually know it's done. Verify. |
Warning signs
- About to type "done" or "shipped" or "all set" in a message
- Reasoning includes the words "it should work" or "it must be working"
- About to close a ticket without re-reading the original ticket
- About to send a doc without re-reading it end-to-end
- Time pressure is high and the verification step is the easiest one to skip
Hard gates
Before declaring this done, name the verification step you ran (a command output, a re-read, a smoke test, a checklist) and what it returned. If you cannot name it, you have not verified. Run it now.
Quality bar
- Verification step is named and was actually run (not skipped, not "implied")
- Output of verification is captured in your reasoning
- If verification surfaced gaps, they were addressed before declaring done
- "Done" declaration references the verification step
Variations
- Code shipping: verification = "tests passed AND smoke test on staging AND error budget intact"
- Doc shipping: verification = "re-read end to end AND links work AND examples are accurate"
- Task closing: verification = "re-read the original ticket AND every acceptance criterion is met"
- Decision shipping: verification = "the alternative was named and its rejection reason still holds"
Example
Input: Just finished a doc draft, about to send to manager.
Without skill: "Sent! Let me know what you think." (manager finds 3 broken links and a placeholder paragraph)
With skill: STOP. Verification step = re-read end to end + click every link. Re-read finds: placeholder still in paragraph 3. Two links broken. Fix both. Verify again. Now send.
