dod · an Agent Skill by SkillEra for Claude Code, Codex, Cursor and any agent that reads SKILL.md
Define what complete means before your AI agent builds a feature. dod evaluates the feature's requirements layer by layer, writes a plan whose every item can be checked, has it independently reviewed — approval needs READY on the current revision — and produces a standard set of project artifacts to go with the plan. At the close, one number: how much of the work the plan foresaw.
The Performance tab of a real page dod wrote, for the plan behind its own pm-views work: each measure against its target, read from the plan's own records. The page itself (opens in a new tab) is one HTML file — download it and open it in any browser.
The rest of the feature
Ask an AI coding agent for a feature and you get the main path: the form, the button, the happy case. The rest — the empty state, the second user, the bad input, the service that is down, the way back if it goes wrong — turns up during the build, one surprise at a time, and each surprise is rework.
dod moves that discovery to the start. Before any code is written, the agent works through layers of questions about the feature, asks you only what it cannot find out from your code, and writes a plan whose every item can be checked. An outside reviewer reads the plan and has to agree it is complete. Then the plan is frozen, the build is tracked against it, and anything the plan missed is recorded as it is found.
It only runs when you ask: /dod, the skill's name, or “a definition of done” for a feature. An ordinary “make a plan for dark mode” does not start it unless your project opts into automatic triggering, and it never interrupts to ask whether it should.
A plan is not ready because it reads well. It is ready when every applicable requirement layer has an answer that points into the plan, no gating probe or decision is open, and an independent reviewer has returned READY on the current revision. Anything still unknown is a Gap, never assumed done.
1
Size
S, M, L or Epic. Smaller than S — a typo, a one-line fix — and the skill says so and stops.
2
Recon
It reads the modules the feature touches, the tests, the schema, auth and routing, and records the commit it read. It never asks what the code can answer; in a new project it states each assumption it would otherwise have looked up.
3
Layer pass
Fifteen layers, forty-nine probes. Each probe is answered from the brief plus recon with a pointer into the plan, or it is a Gap.
4
Questions
One batch, grouped by layer, at most about eight, gaps only — each with why it matters and a recommendation you can accept in one word, and what happens if you take it or not.
5
Draft
The Definition of Done comes first: checkable statements D1…Dn, each with an evidence type — test, cmd, file or manual. The Build plan is numbered steps an agent that never saw the conversation can follow.
6
Independent review
An independent reviewer gets a copy with the scores removed and returns findings with READY or REVISE. Each finding is accepted or rejected with a reason; up to three rounds, then a person decides.
7
Approve
Ready needs every applicable layer and probe answered, no gating probe open, no open decision, and READY on the current revision. The items are copied into the Baseline, never edited again.
8
Build
Follow the Build plan; check an item only with evidence; anything unforeseen is an amendment before it is built, typed by its cause: the plan should have caught it, you changed scope, nobody could have foreseen it, the code was wrong, or the world changed.
9
Close
Every item verified, every excluded amendment shown to you, then the report and its prediction rate: of the work that turned out to be needed, how much the plan foresaw.
Fifteen layers, nine gating probes
Every applicable layer needs an answer before a plan can be approved. Nine probes are gating: a plan with one open is never ready.
layer holds a gating probe
1Purpose & typical use
2Actors & permissionsGating: 2.1 who can reach it
3Inputs, outputs & dataGating: 3.3 what is kept and for how long
4Business rules & invariantsGating: 4.4 which rule wins
5Internal interfaces
6External dependencies & contractsGating: 6.2 a dependency that fails
7States & lifecycle
8Minimal stretch
9Maximal stretch
10Security & privacyGating: 10.1 authorization on every path · 10.3 secrets
11Design & UX
12Failure handling & observabilityGating: 12.4 a failing case for every check
13Performance & scale
14Rollout & compatibilityGating: 14.3 rollback · 14.4 every path the change touches
15Out of scope
Questions worded for you
Plans are read by people who are technical but not fluent in every technology their product uses. The audience profile fixes that once per project: it changes only how questions and plans are worded, per technology — never what they decide. Every recommendation, at every level, says what happens if you take it and if you do not.
expert
Terms of art bare.
working
A term specialised to that technology gets one “— which means …” clause the first time.
familiar
Every term of art is followed by “— here, that means …”: its consequence for this decision.
new
Plain words first, the term in brackets after, and one “For example, …” per decision.
Calibrated to what the project got wrong before
Five additions make a plan's evidence match the misses already on record.
Dry-run notes
Before approval, every test and cmd item's command is run once on the draft and the output is recorded.
Miss history
The probes this project's finished plans kept missing — in two or more of them — and a new plan must show an observed dry run on an item that answers each one.
Rework
An amendment that fixes an earlier amendment's fix says so, and the report counts it beside the prediction rate.
Host
The project profile records the machine the checks ran on: platform and tool versions, each measured and dated.
Effort
When a work package finishes, its active time and tokens are measured from this folder's Claude Code session records — the times and token counts only, never a message. A value nobody measured says “not recorded”, never zero.
The number at the end
That report is real: it is the close of index-leak-guard, the first plan taken through the whole lifecycle, and it came in at 75 %, under its target. The walkthrough (opens in a new tab) tells the story.
A real close report, set out as rows and cut after its missed probe.
Standard project artifacts, with the plan
Everything dod writes is Markdown and HTML in your own repository — no account, no service, no database. Each plan comes with its reviews and two pages; the project gets a dashboard, a self-audit and an index, and a benchmark compares projects side by side.
The five pages are single HTML files that work offline and load nothing — no fonts, no scripts from elsewhere, no tracking. They share one look, so a page from any project reads the same. They are drawn on request with /dod page, and the work breakdown exports as CSV or Markdown with wbs --export.
A referee script with no dependencies checks every plan's rules after each write, builds the reviewer's prompt, and can fail a push on a stale index.
With each plan
The plandocs/dod/<slug>.md
The single tracker: the checkable items, the build steps, every change, the log.
The reviewsdocs/dod/<slug>.reviews.md
Each review round: the findings, the verdict, and what was done about each one.
The plan pagedocs/dod/<slug>.html
Overview, analysis, KPIs, work breakdown with its schedule, items, changes, log.
The review pagedocs/dod/<slug>.review.html
Every planning question and the plan's own answer, with no score, for the reviewer.
Across the project
The project dashboarddocs/dod/dod-dashboard.html
Every plan in the project, its rate and its effort.
The self-auditdocs/dod/dod-audit.html
The project's health, with a numbers-only block you can paste into a “Field audit” issue.
The benchmark<folder>/dod-benchmark.html
Every dod project under a folder, side by side, with their mean and median.
The indexdocs/dod/README.md
Every plan with its status and rate, regenerated, never hand-edited.
Install
Then run /dod setup in a project. It creates the plan store and shows you the pointer block before writing it into your agent's instructions file — nothing is written silently.
Or copy the skill folder to ~/.claude/skills/dod/, ~/.codex/skills/dod/ or ~/.cursor/skills/dod/. The helper scripts need Node 20 or later. Without Node, list and status still work from the plan files, but the plan's rules are not checked, and the skill says so each time.
Any agent that reads SKILL.md
Claude Code, Codex, Cursor and others, through the skills installer.
npx skills add KDavidP1987/dod-skill
Claude Code plugin
Add the marketplace once, then install the plugin.
Unknown is a Gap. Never considered, never checked, never done, on inference.
The author never grades alone. Author and reviewer scores are shown side by side, never averaged.
The Baseline is never edited. Scope moves through amendments only — relabelling a planning gap to protect the rate is the exact failure this skill exists to prevent.
The plan must survive the conversation: paths, commands, schemas; no “as discussed”.
Show, then run. Each evidence command is displayed before it runs, and it asks before anything that is not a recognisable test, build, lint or read-only command.
Do not hijack. It runs only when you ask for it, unless your project opts into automatic triggering.
Some limits of this version
One plan per file, one store per project, and git as the way two sessions stay in step — no locks.
Hook reminders, the audit and enhance commands, scoring rules that sort a reversal by its cause, and a second reviewer from another model family are planned, not shipped.
A plan over 1 MB or over 500 items gets a warning and is still read; a line over 10,000 characters is a problem the check reports.
The review loop does not settle on its own: three rounds is the cap, and a person decides after that. Expect real findings in every round.
Effort is measured only from Claude Code's session records on this machine; anywhere else it says “not recorded”.
What comes next
Now
The five pages in one look, a short-or-full detail preference, and the fixes found in the field.
Next
Planning checks learned from field reports — parts that must add up to the whole, and look-alike items.
After that
A second reviewer from another model family, scoring that sorts a reversal by its cause, hook reminders, and the audit and enhance commands.
1.0, under consideration
Once dod has been used on outside projects with a prediction rate at or above 75 %.
The walkthrough tells the story of one plan from request to close, and the example page is the plan behind dod's own pm-views work. The skill is MIT licensed; issues and pull requests are welcome on GitHub.
