A5.5 · module hub
The implementation prompt
The four prior parts are inert until something runs them. The fifth part is that runner: one prompt the Author follows top to bottom, building the increment in task order and ending on the verification gates.
References, requirements, topology, agent stories — a brief that is complete but
unrun. The comprehensive implementation prompt assembles all four into one runnable
instruction, executes the agent stories in task-DAG order, and closes on the Definition of Done. It fixes
no decision the spec has not already fixed. Pick one of the five inputs on the right to see it folded into
the prompt, grounded on the Portal's real f6.1.llms.md.
The prompt's five inputs · pick one
One prompt, five inputs, one run
The first four parts of the brief leave a complete plan: the sources to read, the requirements to satisfy, the runtime shape and build order, and the agent stories with their gates. None of it runs on its own. The fifth part is the comprehensive implementation prompt — a single instruction an Author follows top to bottom, building the increment in task-DAG order and ending on the verification gates, with the spec's Definition of Done as the acceptance checklist.
The prompt's authority comes entirely from the parts above it. It restates the decisions the spec already
fixed — it adds none. The Portal's f6.1.llms.md carries one such prompt: it
opens by naming the sources to read and the unchanged-facade boundary, runs F6.1-AS1…AS4
over T1→T7, and closes on the gates. It is the same brief layer the companion
chapter F6.1 — the request lifecycle builds against; the
multi-agent variant runs the same assembly across a lead-team for a riskier rung such as
F6.6 — LiveView.
# f6.1.llms.md — the comprehensive implementation prompt (preamble + the seven steps) You are implementing spec F6.1 (Bootstrap the Phoenix Portal) as a NEW umbrella app apps/portal_web… Read specs/phoenix/f6.1.md, f6.1.stories.md, and specs/design/f0.md first. Do not change anything under the Portal facade… Build in this order, keeping the umbrella compiling after each step: 1) Foundation T1 # the new app, helpers, telemetry, config 2) Endpoint T2 [R1] # the plug stack + the LiveView socket 3) Supervision T3 [R2] # wire the endpoint; drop Bandit 4) Router T4 [R3, R6] # :browser pipeline, courses route, /health 5) Controller T5 [R4, R8] # index/2 over Portal.courses_of/1 only 6) View T6 [R5] # CourseHTML + .heex, assigns only 7) Verify T7 [R7, R8 + DoD] # the gates, reported against the DoD Stop when the Definition of Done in specs/phoenix/f6.1.md is fully checked.
The implementation prompt assembles the four prior parts into one run, in task order, ending on the gates — and fixes no decision the spec has not already fixed.
f6.1.llms.md's prompt runs F6.1-AS1…AS4 over
T1→T7 and closes on mix compile clean,
/health 200, an empty invariant grep, and endpoint self-heal — the F6.1
Definition of Done as the checklist.
The prompt is the brief made runnable — every part folded into one pass that ends when the gates pass.
Complete or incomplete
A prompt that gathers all five inputs and runs the steps still is not complete unless it ends on its gates. The seventh step — verify — is what closes the loop: it names the runnable checks the Author self-checks against and reports them against the Definition of Done. Drop it and the prompt is incomplete: the agent builds, then reports done with no evidence of done.
Toggle the verify step below. With it, the prompt ends on the four gates the F6.1 brief names. Without it, the prompt loses every gate and the readout flags it incomplete — the same check A5.5's acceptance runs: a prompt missing its acceptance gates is flagged.
The seven steps · with or without the verify step
A prompt that builds but never verifies is not done; it has only stopped — the gates are where "done" is allowed to mean done.
The three dives
Each dive takes one move in the arc assemble → order → close: how the prompt gathers the four prior parts, how it runs them in task-DAG order, and how it ends on the Definition of Done. Read them in order — A5.5.1 starts.
Assembling the prompt
The prompt gathers the four prior parts — references, requirements, topology, agent stories — into one runnable instruction; each part it omits is a guarantee it cannot give.
Task order
The prompt runs the agent stories in the task-DAG order, keeping the tree compiling after every step; build out of order and a dependency breaks.
Definition of Done
The prompt ends on the verification gates the agent self-checks against; a prompt missing them is incomplete — the agent reports done with no evidence.
After A5.5, the next module — A5.6 · Running Claude agents well — covers the practice around the prompt: brief, supervise, and review against the spec's Definition of Done. Start with the first dive, Assembling the prompt, or return to the A5 module navigation.
References
The sources on writing and running a single implementation prompt, and where the rung it builds is defined in the companion course.
Sources
- Anthropic — Claude Code best practices — how to write a single, complete prompt a coding agent runs against a fixed spec, step by step to the gates.
- llmstxt.org — The /llms.txt convention — the links-first machine-brief format the prompt closes; references first, prose only where it carries a decision.
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — the tracer-bullet discipline of running a fixed contract end to end to a built, verified increment.
Related in this course
- A5.5.1 · Assembling the prompt
- A5.5.2 · Task order
- A5.5.3 · Definition of Done
- A5.4 · Agent stories — the stories the prompt runs.
- A5 · The agent brief
- Companion · F6.1 request lifecycle — the real rung whose
f6.1.llms.mdprompt this hub grounds on.