Definition of Done: figure it out for any task

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.