# Definition of Done: figure it out for any task

The coach keeps things simple. This is the deeper version. Use it when you're doing serious work and can't afford to chase mistakes. Answer these *before* you start, not after.

---

## Step 1 · What exactly changes?

Write one sentence:

> "When this task is complete, **[X]** will be true that wasn't true before."

If you can't write that sentence, the task isn't scoped yet. Stop and scope it first. A few examples of what a clean one looks like:

- "Users can reset their password without contacting support."
- "The monthly report generates in under 3 seconds."
- "The contract is signed and filed."

---

## Step 2 · What type of task is this?

Pick one. Your way of proving it depends on which it is.

| Type | Examples |
|---|---|
| **Code** | bug fix, feature, refactor, migration |
| **Document / Content** | spec, report, email, proposal, analysis |
| **Decision** | choosing a vendor, approving a design, resolving a question |
| **Ops / Process** | setting up a system, running a batch job, filing something |

---

## Step 3 · How will you prove it's done?

**Code tasks**
- [ ] There's a test that was failing before and passes now.
- [ ] The change was reviewed by at least one other person or tool.
- [ ] It works end to end in a real environment, not just in unit tests.

**Document / Content tasks**
- [ ] Every claim is backed by a source you can cite.
- [ ] Someone else read it and it was clear to them.
- [ ] It's in the right place and accessible to whoever needs it.

**Decision tasks**
- [ ] The options you considered are written down.
- [ ] The reasoning for the choice is written down.
- [ ] The decision is recorded somewhere durable, not just in chat.

**Ops / Process tasks**
- [ ] The before-state and after-state are both documented.
- [ ] You can verify the outcome directly: a file exists, a record was created, a confirmation arrived.
- [ ] Someone else could reproduce or undo this if they needed to.

---

## Step 4 · What would a critic say went wrong?

Before you call it done, ask the meanest version of the question: **"What's the most likely way this is actually broken or incomplete?"**

Then go check that specific thing. If you can't check it, write it down as a known risk instead of pretending it isn't there.

---

## Step 5 · Fill in the record

When you're done, leave a short trail so future-you (or anyone else) can understand what happened:

```
root-cause: What the actual problem or gap was, and how you know.
           (Confirmed / Deduced / Hypothesized)

review:    Who or what checked your work.

verified:  Exactly how you confirmed it works.
           (test name, action taken, before/after)

artifacts: Links to the PR, doc, file, email, or screenshot.
           Anything findable later.

refs:      File paths, URLs, record IDs you touched.
```

If a field is blank, ask yourself why. Blank with no recorded reason means it isn't done.

---

## Quick check: am I actually done?

Answer yes or no:

1. Could someone read this record in six months and know what broke, what I did, and how we know it's fixed?
2. Is the evidence findable (linked, filed, saved), not just in my head or in a chat?
3. Did someone or something other than me verify the outcome?

**All three yes? Done. Any no? Go find the gap.**

---
By **Gina Wang · Kulanet AI**.