Prickles
Prickles
Case file P3
PProcess

Definition of Done

Done means the checklist passed.

Done means the checklist passed. Coverage, lint, type-check, format, dup-check, AC, a11y: written down, machine-checked, signed off. Judgement is too lenient on a Friday afternoon. The list is the gate and the gate does not flex.

ByAdam LewisPublished3 May 2026Revised13 Oct 2026Reading12 minVersionv1.2ConfidenceHigh
§0b

Opinion

Every team I have worked with that didn't have a written Definition of Done shipped half a feature and called it done at the same rate and the rate did not fall with seniority. The most senior engineer on a Friday afternoon shipped a half-typed change with the same conviction as the most junior on Monday. Gawande's point about ICU central lines is the same point about feature merges: the experts know all the steps, the experts skip steps when they're tired and the checklist they hate at first is the checklist that saves them later.1

I want to plant a flag on this: the DoD is the back half of P2 Spec-First Execution. The AC at the start is the brief. The AC at the end is the gate. If the AC was written verifiably per AI4 Verifiable Specs, the DoD has something machine-readable to verify against. If not, the DoD becomes judgement, which is the failure mode the row is built to displace. The DoD without a verifiable AC is theatre. The AC without a DoD is aspiration.

The row earns its weight at the agent layer. An LLM left unchecked will declare itself done at the moment the code compiles. That is the prior, and no amount of CLAUDE.md scolding changes the prior. The fix is not to ask the agent to be more careful. The fix is to give the agent a list it has to tick.10 Reflexion, Self-Refine, CRITIC: all the same shape. The checklist is the external signal the model corrects against.2 Without it the agent grades itself. With it, the agent has something it cannot fake.

Copy a note and link

Grab this short comment and drop it into a PR comment or an LLM chat to prompt the right change.

Done means the checklist passed. Coverage, lint, type-check, format, dup-check, AC verified, a11y verified: every row machine-checked, every row signed off. Judgement is too lenient on a Friday afternoon. The list is the gate and the gate doesn't flex.

/tenet/definition-of-done/P3
Copy for paste
§0c

AI eyes only

Rule: done means the checklist passed. Define done as a single command.

Reject: declaring done because the build is green. Reject: declaring done before lint, type- check, tests, format, duplication, coverage all pass. Reject: skipping the script “to save time”.

Generate: run npm run quality (or the project equivalent) before handing back. Paste the result. If the script fails, fix and re-run. Done is the script's exit code, not the agent's opinion.

Diagnostic: cite the exit code of the quality script in every handover. No exit code, no done.

§0d

Why?

  • A written checklist is more reliable than personal judgement. Senior engineers on Friday afternoons skip the same steps as junior engineers on Monday mornings. The list is the corrective.
  • The AC is the bookend. P2 Spec-First Execution writes the AC at the start; P3 verifies it at the end. The two rows compose. Without P3, the AC is aspiration.
  • Total coverage is one row on the list rather than a tenet of its own. Promoting it inflated the canon. Absorbing it sharpens the list and matches Fowler and Marick on coverage as diagnostic, not target.
  • The DoD is the agent's grader. The model declares itself done when the build compiles; the list is what stops it. CRITIC and the evaluator-optimizer pattern both ground the agent in something machine-checkable.
  • PRs merge faster when the reviewer can read down the DoD instead of reverse-engineering the intent. Each row of the list is a row the reviewer doesn't have to think about.
  • DORA / Accelerate names the DoD as one of the capabilities that predicts delivery-performance. The list isn't bureaucracy. It's a measured driver of throughput.
  • The DoD is what “done” means on this team. New starters know what to verify; existing members can't lower the bar without a conversation. The floor moves up over time, not down.
The receipts
Origins, quoted passages, evidence, the strongest counter-argument and the reply.
§1

Origins

The agile-era origin is Scrum. Ken Schwaber and Jeff Sutherland's Scrum Guide has used the term “Definition of Done” since at least its November 2009 edition. The current edition treats the DoD as “a formal description of the state of the Increment when it meets the quality measures required for the product.”5 Mike Cohn's Succeeding with Agile (Addison-Wesley, 2010) ch.10 is the practitioner playbook for assembling one.6 Robert C. Martin's The Clean Coder ch.3 (“Saying Yes”) and ch.8 (“Testing Strategies”) hold the discipline-first flavour: the checklist defines what a professional commitment means.7

The older intellectual root is Atul Gawande's Checklist Manifesto (Metropolitan Books, 2009).1 Gawande's case is built on aviation pilot checklists and Peter Pronovost's ICU central-line checklist (Johns Hopkins, 2001): experts on hard problems beat their own judgement when they read from a list. Gawande's claim transfers directly to engineering: the senior engineer on a Friday afternoon is the ICU doctor at the end of a shift. The checklist is the corrective.

The DORA / Forsgren research programme makes the DoD a measured driver of delivery performance. Accelerate (IT Revolution, 2018) names the 24 capabilities of high performers. The DoD checklist sits inside several: continuous testing, test automation, deployment automation.8 The 2024 DORA report continues to list these as predictors. The Microsoft Engineering Playbook codifies the same shape for an industrial team and is the most-cited operational template on GitHub.9

The total-coverage row in the previous canon merges into the DoD here. Brian Marick's coverage taxonomy and Martin Fowler's “Test Coverage” bliki entry both argue the same point: coverage is a metric rather than a target.4 Promoting it to a tenet inflated the list. Absorbing it into the DoD as one row with named exclusions (.types.ts, .spec.ts, .stories.tsx, .config.*, __mocks__/) is the move P4 Continuous Quality Feedback and the canonical literature both prefer.

§2

Quotes

Good checklists, on the other hand, are precise. They are efficient, to the point, and easy to use even in the most difficult situations. They do not try to spell out everything—a checklist cannot fly a plane. Instead, they provide reminders of only the most critical and important steps …

Atul Gawande · The Checklist Manifesto (2009)

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.

Schwaber & Sutherland · The Scrum Guide

Professionals don't make commitments unless they know they can achieve them. It's really as simple as that.

Robert C. Martin · The Clean Coder (2011)

Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.

Martin Fowler · Test Coverage (2012)
§3

Evidence

20 external sources, ranked by author authority. The first five are the canon; expand to see the rest, including the qualifiers and the named opposers. Each links out to its primary source.

  1. 01
    The Checklist ManifestoSupports
    Atul Gawande · 2009
    The intellectual root. Aviation pilot checklists and Pronovost’s ICU central-line checklist. Experts on hard problems beat their own judgement when they read from a list.
  2. 02
    The Scrum Guide (current edition)Supports
    Ken Schwaber & Jeff Sutherland · 1995 onwards
    The agile-era origin of the term. The DoD as a formal description of the state of the Increment when it meets the quality measures required for the product.
  3. 03
    Succeeding with AgileSupports
    Mike Cohn · 2010
    Ch.10 is the practitioner playbook for assembling a DoD. Walks through team-level vs release-level definitions and the difference each makes.
  4. 04
    The Clean CoderSupports
    Robert C. Martin · 2011
    Ch.2 “Saying Yes” and ch.8 “Testing Strategies”. The checklist defines what a professional commitment means. The discipline-first flavour.
  5. 05
    Accelerate: The Science of Lean Software and DevOpsSupports
    Forsgren, Humble & Kim · 2018
    Names the 24 capabilities of high-performing teams. The DoD sits inside continuous testing, test automation, and deployment automation. An empirical case for the row.
  1. 06
    Microsoft Engineering Fundamentals PlaybookSupports
    Microsoft · 2020 onwards
    The most-cited operational template for engineering DoDs on GitHub. Codifies the row-by-row checklist shape for industrial teams.
  2. 07
    DORA: State of DevOps Report 2024Supports
    DORA / Google Cloud · 2024
    Continues to list test automation, deployment automation, and continuous testing as drivers of delivery performance. The DoD is the per-change enforcement of these.
  3. 08
    Continuous DeliverySupports
    Jez Humble & David Farley · 2010
    The deployment-pipeline idea. Each stage of the pipeline is a row on a machine-readable DoD. The manual checklist becomes the human-readable parallel.
  4. 09
    Lean EnterpriseSupports
    Jez Humble, Joanne Molesky & Barry O'Reilly · 2014
    The team-level DoD scaled up to enterprise delivery. Useful as the bridge between team-level checklists and organisational-level governance.
  5. 10
    How Google Tests SoftwareSupports
    James Whittaker, Jason Arbon & Jeff Carollo · 2012
    Google’s testing playbook. The “100% with explicit exclusions” idea for coverage. The source of the named-exclusion convention the DoD uses for coverage.
  6. 11
    “Test Coverage” bliki entryQualifies
    Martin Fowler · 2012
    Coverage targets are a smell. Coverage is a diagnostic, not a goal. The qualifier inside the DoD’s coverage row.
  7. 12
    The Craft of Software TestingQualifies
    Brian Marick · 1995
    Marick’s coverage taxonomy. Coverage is a metric, not a target. The DoD treats coverage as the diagnostic with named exclusions.
  8. 13
    The Principles of Product Development FlowOpposes
    Donald G. Reinertsen · 2009
    The lean-throughput steelman. Every checklist row is overhead. Batch-size discipline does more for delivery throughput than list discipline.
  9. 14
    Lean Software Development: An Agile ToolkitQualifies
    Mary & Tom Poppendieck · 2003
    The Poppendiecks’ qualification: every checklist row is a queue, every queue is delay. The DoD must be revisited regularly to remove dead rows.
  10. 15
    A Philosophy of Software Design, 2nd ed.Opposes
    John Ousterhout · 2018, 2021
    Checklists are bureaucracy. The time spent on the list is time not spent on the design. The broadest opposing view. The reply argues the DoD must be pruned, not abandoned.
  11. 16
    Building Effective AgentsSupports
    Anthropic · 2024
    Names the evaluator-optimizer pattern. The agent generates, an external check evaluates. The DoD is the canonical evaluator.
  12. 17
    “Verifiability”Supports
    Andrej Karpathy · 2025
    Three conditions a task must satisfy to be agent-optimisable: resettable, efficient, rewardable. The DoD must satisfy them or the agent grades itself.
  13. 18
    Pronovost et al.: “An Intervention to Decrease Catheter-Related Bloodstream Infections”Supports
    Peter Pronovost et al. · 2006
    The Michigan Keystone ICU study Gawande draws on, led by Pronovost of Johns Hopkins. Empirical case that a five-row checklist cut catheter-related bloodstream infections by up to 66% across 103 ICUs, taking the median rate to zero within three months. The medical analogue for the engineering DoD.
  14. 19
    Reflexion: Language Agents with Verbal Reinforcement LearningSupports
    Noah Shinn et al. · 2023
    Empirical case for grounding the agent in machine-checkable feedback. HumanEval pass@1 lifts from ~80% to 91%. The DoD is the canonical machine-checkable feedback in code work.
  15. 20
    CRITIC: Large Language Models Can Self-Correct with Tool-Interactive CritiquingSupports
    Zhibin Gou et al. · 2024
    Tool-interactive critiquing. The verification signal must come from running tools (tests, linters, type-checkers) exactly the rows the DoD enumerates.

Twenty sources, three stances. The supporters are Gawande, Schwaber & Sutherland, Cohn, Martin's Clean Coder, and Forsgren: the checklist canon. The qualifiers further down push the line that coverage and DoD rows are diagnostics, not goals. The opposers argue checklists are bureaucracy. The steelman the case has to address.

§4b

Enforcement

Viewing: TypeScript.

Apply these rules in eslint.config.mjs. The full enforcement across every tenet lives on the implementation page.

RuleToolCatches
vitest --coveragevitest --coveragethe coverage row of the DoD. Configure thresholds.lines / branches / functions to fail the script when coverage drops below the team floor.
tsc --noEmitTypeScript compilerthe type-check row. Strict mode plus noUncheckedIndexedAccess plus exactOptionalPropertyTypes catch the silent contract failures.
eslint .ESLint corethe lint row. Every error in the config is a row on the DoD; warnings are the rows the team chose not to enforce yet.
jscpd .jscpdthe dup-check row. Threshold 0 in this repo; non-zero is a refactoring task before merge.
prettier --check .Prettierthe format row. Format failures are auto-fixable but never auto-merged.
husky pre-pushHusky pre-pushthe gate. Runs the quality script on every push; the merge button doesn’t accept a red pre-push.
lint-stagedlint-stagedthe per-commit subset. Runs the DoD on the staged files only so the loop stays under a second.
no-warning-commentsESLint coreTODO / FIXME / WIP markers: the unfinished-work signal that wasn’t triaged before merge.
eslint.config.mjsconfiguration snippet
import { defineConfig } from 'eslint/config';
import tseslint from 'typescript-eslint';

export default defineConfig({
  files: ['**/*.{ts,tsx}'],
  rules: {
    'no-warning-comments': ['error', { terms: ['todo', 'fixme', 'wip'], location: 'anywhere' }],
    'no-restricted-syntax': ['error', {
      selector: "CallExpression[callee.name='it'][arguments.length=1]",
      message: 'Tests without an implementation block are pending, finish before merge.',
    }],
  }
});
§4c

AI rules

File.cursor/rules/p3-definition-of-done.mdc
---
alwaysApply: true
---

## Prickles P3: Definition of Done

Don't call work done until every row of the checklist passes: coverage, lint, type-check, format, dup-check, AC verification and accessibility, each machine-checked and signed off.

The list is the gate and never a guideline. The moment a row is treated as advisory, the row is dead.

Revisit the list every quarter. Remove rows that haven't caught anything. Add rows that catch failures the team is paying for.

The AC at the end is the AC at the start (P2 Spec-First). Without P2's AC, the DoD has nothing to verify against.

Repo layout, CI, and ESLint wiring for these paths live on /implementation, not repeated on every tenet.

§5

Counter-argument

Counter

The strongest steelman is the lean-throughput reading: every checklist row is a unit of overhead and the team that releases fastest is the team that has stripped its DoD to the bone. Donald Reinertsen's Principles of Product Development Flow argues that batch-size discipline does more for delivery throughput than list discipline.3 Marick's coverage taxonomy is the qualifier inside the row: target-driven coverage produces local optima.4 Ousterhout's critique is broadest: checklists are a bureaucratic answer to a design problem. The time spent on the list is time not spent on the design.

§6

Counter-argument retort

Reply

Reinertsen is right about lean throughput when the DoD has become a backlog of compliance items the team can't justify item-by-item.3 The reply is to keep the list short, every row justified, every row tied to a measurable failure mode. The six-row npm run quality script in this repo is the working example: lint, sonar, type-check, format, dup-check, test+coverage, plus the AC verification on the PR. Each row catches a class of failure that has cost the team an hour in the past quarter. The list is short because the list is empirical.

Marick's coverage argument qualifies the row rather than refuting it. Coverage as a target produces local optima: the engineer adds a meaningless test to the file with low coverage. The suite grows. Nothing is checked. Coverage as a diagnostic surfaces the file with no tests at all, which is a different question. The DoD treats coverage as the diagnostic, with named exclusions for files that are already covered by the surrounding code ( .types.ts, .config.*) and a floor (90%) that the team has chosen because the cost of dropping below it is measurable.

Ousterhout's critique, that checklists are bureaucracy, is true for the DoD that has grown without pruning. The fix is not to drop the DoD. It is to revisit the DoD every quarter and remove the rows that haven't caught anything. A short DoD is a working DoD. A long DoD is theatre. The discipline survives Ousterhout. The bureaucratic growth doesn't.

In production work, the DoD is the row that lets the team merge to main on a Friday afternoon without holding the breath of every reviewer. P2 writes the AC; P4 runs the gates as the change is being written; P3 is the final read of the list before the merge button is pressed. The three rows compose. Collapsing them loses one of the three failure modes each catches.

§7

Notes

  1. [1]Atul Gawande: The Checklist Manifesto: How to Get Things Right (Metropolitan Books, 2009). Built on aviation pilot checklists and Peter Pronovost’s ICU central-line checklist. Experts on hard problems beat their own judgement when they read from a list.
  2. [2]Noah Shinn et al.: “Reflexion: Language Agents with Verbal Reinforcement Learning”, NeurIPS 2023. The agent grounded in machine-checkable feedback improves. The agent grading itself does not. Generalised by Madaan (Self-Refine) and Gou (CRITIC).
  3. [3]Donald G. Reinertsen: The Principles of Product Development Flow (Celeritas, 2009). The lean-throughput steelman: every checklist row is overhead, and batch-size discipline does more for delivery throughput than list discipline.
Disagree? Found a hole in the argument? Take issue with this tenet →
Last revised: 2026-10-13