jonnifyagile agents

A5.5.3 · dive 3/3

Definition of Done

The prompt does not end when the files are written. It ends on the gates — the verification step the agent runs and reports against. A prompt that stops at “build it” hands back an opinion; a prompt that ends on the Definition of Done hands back evidence.

The last step of the implementation prompt folds the spec's Definition of Done into the run: a set of runnable checks the agent executes and reports, one by one. That is the only place an agent's “done” is allowed to mean done — not a self-report, a passing gate. Step through the figure on the right to see the seven gates the Portal's real f6.1.llms.md prompt closes on.

The gates the prompt ends on · step through the Definition of Done

f6.1.llms.md · step 7 — the Definition of Done mix compile is clean build the app boots runtime GET /health is 200 runtime courses render + empty state render injected %Portal.Error{} renders 422 unit kill the Endpoint — it restarts restart invariant grep is empty step 1 of 7
Gate 1 of 7 — mix compile is clean (a build check). The prompt closes on a runnable Definition of Done: the agent runs each check and reports the result, it does not assert done.

Where the prompt stops

The first two dives built the prompt up: A5.5.1 gathered the four prior parts into it, and A5.5.2 ordered the build so the tree compiles after every step. This dive is about the last step — the one that decides what “done” means. A prompt that ends after the build step asks the agent to write files and stop. The agent reports “done,” and that word is an opinion: nothing was run, nothing was checked.

The fix is a closing verify step that carries the spec's Definition of Done. It names runnable checks — compile, boot, a request, a failure path, a restart, a static grep — and instructs the agent to run each and report the result. Now the agent's last act is not a claim but a list of outcomes the Operator can read. The prompt stops only when every check passes; until then, the work is not done, however finished the files look.

This is the same line A5.4.3 drew for a single agent story's Acceptance gate, raised to the whole prompt: an agent story closes on its gate, and the prompt closes on the full set of them. The Operator reads against these checks, never the agent's self-report — the discipline this course returns to whenever an agent reports its own work.

Without a verify step

The prompt ends on the build: the agent writes the files and reports “done.” Nothing was run, so the report is an opinion — the Operator has no evidence the increment works.

Ending on the Definition of Done

The prompt's last step runs the spec's checks — compile, boot, request, failure, restart, grep — and reports each. The agent stops only when every gate passes; “done” means a passing gate.

The Definition of Done is also where the seam to A6 opens: A5 produces an increment that passes its own acceptance gates; A6 is the work that keeps it passing them under production. First the gates must be part of the prompt — which is this dive.

On the Portal

The Portal's web bootstrap brief, f6.1.llms.md, ends its seven-step implementation prompt on a verify step. Step 7 does not ask the agent to assert completion; it lists the checks to run and report. The agent confirms mix compile is clean and the app boots; that GET /health returns 200; that GET /courses/:user_id renders a known user's courses and an empty state for none or an unknown or malformed id; that the 422 render path is unit-verified via an injected %Portal.Error{}; that killing PortalWeb.Endpoint restarts it under :one_for_one and a later request succeeds; and that the invariant grep is empty. The companion course builds this exact rung at the Phoenix request lifecycle.

# f6.1.llms.md — step 7 (T7 → R7, R8 + DoD): the gates the prompt ends on
7) Verify. Confirm: mix compile is clean; the app boots; GET /health is 200;
   GET /courses/:user_id renders a known user's courses and an empty state for
   none or for an unknown/malformed id; the 422 render path is unit-verified via an
   injected %Portal.Error{}; killing PortalWeb.Endpoint restarts it
   (under PortalWeb.Application, :one_for_one) and a later request succeeds. Run
   grep -rE "Portal\.Engine|Repo|GenServer\.call" apps/portal_web/lib/ and confirm it is empty.
   Report each result against the F6.1 Definition of Done.
#
# Stop when the Definition of Done in specs/phoenix/f6.1.md is fully checked.

Each check maps to a requirement and closes an agent story's Acceptance gate: the grep is F6.1-R7 (the static master invariant), the 422-not-500 and self-heal are F6.1-R8. The prompt's closing line — stop when the Definition of Done in specs/phoenix/f6.1.md is fully checked — points the agent at the spec for the authoritative list, so the brief never restates done; it defers to the spec that owns it.

The principle

The prompt ends on the Definition of Done — the verification gates the agent self-checks against and reports. A prompt missing its verify step is incomplete: the agent has work to do but no signal of done.

On the Portal

f6.1.llms.md's prompt closes step 7 on mix compile clean, /health 200, the 422 render via an injected %Portal.Error{}, endpoint self-heal under :one_for_one, and the empty invariant grep — reported against the F6.1 Definition of Done.

The Definition of Done is where the prompt stops — and the only place the agent's “done” is allowed to mean done.

Complete or incomplete

A prompt is complete when it ends on its Definition of Done and incomplete when it does not. The difference is one step, and it changes what comes back. With the verify step, the agent's last act is to run the gates and report seven outcomes; the prompt is complete and the increment carries its own evidence. Drop the verify step and the agent's last act is a bare claim; the prompt is incomplete — it built something, but signalled nothing about whether it works.

Toggle the meter below between a prompt that ends on the Definition of Done and one with no verify step, over the seven real checks of f6.1.llms.md. With the verify step, seven checks are reported and the verdict is complete; without it, none are, and the verdict is incomplete — the acceptance check A5.5 makes of every prompt.

Complete or incomplete · toggle the verify step

the prompt's seven steps — does it end on the gates? 1 foundation · 2 endpoint · 3 supervision 4 router · 5 controller · 6 view 7 verify — the Definition of Done present verdict complete checks reported 7 of 7 a prompt missing its verify step builds without a signal of done
Ends on the DoD: complete — the agent self-checks against the gates (compile clean, /health 200, the invariant grep empty, endpoint self-heal): 7 of 7 checks reported. The increment carries its own evidence.

One step decides it: end the prompt on the Definition of Done and it returns evidence; drop the verify step and it returns a claim.

Recap — the prompt is complete only when it ends on its gates

The implementation prompt gathers the four prior parts, runs them in task order, and ends on the Definition of Done — the runnable checks the agent executes and reports. That last step is what makes a prompt complete: without it, the agent writes files and reports an opinion; with it, the agent stops only when every gate passes, and “done” means done. On the Portal, f6.1.llms.md closes on a clean compile, a 200 /health, a unit-verified 422, endpoint self-heal, and an empty invariant grep, all reported against the F6.1 Definition of Done. That closes A5.5 — a brief that is now complete; what remains is the human practice of running it.

Next in A5: the module hub for The implementation prompt — the three dives gathered, then on to A5.6, the practice of running the agent the prompt drives.

References

Primary sources for ending an agent prompt on the checks it must run rather than an open-ended goal, and where the rung whose Definition of Done this prompt closes on is built in the companion course.

Sources

Related in this course