---
name: definition-of-done
description: Enforce a written, observable definition of done before any build starts and before any work is called complete. Use when starting a task, when about to claim work is done, and when reviewing whether a deliverable is actually finished.
---

# Definition of Done

"Basically done" is the most expensive phrase in technical work. It hides the
distance between something that runs and something a team can rely on. This
skill closes that distance: no build starts without a written definition of
done, and no build is called done until the definition says so.

From the operating philosophy at https://anthonyday.ai/philosophy (principle
04: builders need a definition of done). Built from operator knowledge.
By Anthony Day.

## Before any build starts

Require a done statement before writing code or producing the deliverable.
If one does not exist, write it and confirm it with the person who asked for
the work. A done statement has four parts:

1. **The decision or outcome it unblocks.** One sentence. If nothing is
   waiting on this work, question whether it should start.
2. **The owner who receives it.** A named person or role who takes the result
   when it is finished. Work with no receiver is not ready to start.
3. **Observable criteria.** Two to five checks a person outside the team
   could verify without asking the builder. "Works" and "looks good" do not
   qualify. "Returns the correct total for the three sample files in
   /fixtures" qualifies.
4. **An end date.** The date the work is delivered, archived, or escalated.
   Work without an end date does not end.

Record the done statement at the top of the task, plan, or pull request so it
travels with the work.

## Before claiming any work is complete

Never say "done," "complete," "finished," or "ready" until you have checked
the work against each observable criterion and can show the evidence. Report
results criterion by criterion:

- Met: state the evidence (test output, file, URL, measurement).
- Not met: say so plainly. An unmet criterion reported honestly is cheaper
  than a false "done" discovered later.
- Never substitute effort for evidence. "I made the changes" is a statement
  about activity. Done is a statement about verified results.

If the criteria were never written down, stop and write them with the
requester before claiming anything. Do not backfill criteria to match
whatever the work happens to do.

## Banned phrases

Do not use these to describe work status: "basically done," "mostly done,"
"should work," "done except," "practically finished." Either the criteria
are met with evidence, or the work is not done and you say what remains.

## Template

```
DEFINITION OF DONE
Build:        <one line describing the work>
Unblocks:     <the decision or outcome waiting on it>
Owner:        <who receives the result>
Done means:   1. <observable check>
              2. <observable check>
              3. <observable check>
Not done if:  <known failure mode worth naming up front>
End date:     <date delivered, archived, or escalated>
```

## Using this skill outside Claude Code

The discipline is tool-agnostic. For Cursor, paste the sections above into
your project rules. For any other agent, include this file in the system
prompt or rules directory. For humans, the same four parts run as a
one-page worksheet: https://anthonyday.ai/resources