Assembling the prompt

The fifth part of the brief introduces nothing new. The implementation prompt gathers the four parts that came before — references, requirements, topology, agent stories — into one runnable instruction.

A prompt is the assembly point of the whole brief. Each prior part it carries is a guarantee it can give: name the sources and the agent reads the right thing first; pin the topology and the build order and the boundary are fixed. Each part it omits is a guarantee it cannot give. Toggle the figure on the right to see which of the four parts the Portal's real f6.1.llms.md prompt carries, and the fragment that carries each.

The gather-point Drop a part, lose a guarantee On the Portal References

Which prior parts the prompt carries · select a part

References — carried into the prompt: yes (4 of 4 prior parts carried). The prompt opens by naming the sources to read first: f6.1.md, f6.1.stories.md, f0.md. The prompt is the gather-point of the whole brief.

The gather-point

A5.1 through A5.4 each produced one part of the brief: the references the agent reads, the numbered and traced requirements, the runtime topology and build order, and the agent stories with their gates. The fifth part — the implementation prompt — adds no sixth idea. It gathers those four into one instruction an agent runs top to bottom.

Read the prompt as an assembly. It opens by naming the sources to read first (the references). It states the boundary the change must not cross and the order the work is built in (the topology). It runs the agent stories, each closing on its gate, satisfying the numbered requirements. The prompt fixes no decision the spec has not already fixed; it only folds the parts the brief already holds into a single runnable pass.

The prior parts

References, requirements, topology, and agent stories — each its own part of the brief, each carrying one guarantee the agent depends on.

The prompt

Gathers all four into one instruction: name the sources, state the boundary and order, run the stories on their gates. Nothing new is decided; the parts are folded in.

The next dive walks the order the prompt runs the parts in — the task DAG turned into numbered build steps that keep the tree compiling after each one.

Drop a part, lose a guarantee

Because the prompt assembles the four prior parts, each part it omits removes a specific guarantee. Drop the references and the prompt no longer tells the agent which sources to read first — the agent improvises a source. Drop the topology and the prompt no longer fixes the build order or the unchanged-code boundary — the agent picks an order and may edit code the spec pinned as untouched. Drop the requirements and the prompt names no checks the build must satisfy; drop the stories and the prompt names no units of work with closing gates.

Toggle the figure below to drop one part and read the guarantee the prompt can no longer give. A complete prompt carries all four; an incomplete one is missing a guarantee, not merely a paragraph.

Drop a part · see the guarantee the prompt loses

Drop nothing — all four prior parts carried (guarantees kept: 4 of 4). The prompt names the sources, fixes the order and the boundary, and runs each story on its gate. A complete prompt is the four prior parts gathered into one runnable instruction.

A complete prompt carries all four prior parts — each part it omits is a guarantee it cannot give.

On the Portal

The Portal's web bootstrap ships from a real brief, f6.1.llms.md. Its ## Comprehensive implementation prompt opens with directives that are the prior parts folded in. The instruction to read three sources first is the references part. The unchanged-facade boundary and the deps-placement rule are the topology's boundary. The prompt then runs the agent stories over the build order, satisfying the numbered requirements. The opening lines, quoted verbatim:

# f6.1.llms.md — the implementation prompt's opening directives (verbatim)
#
You are implementing spec F6.1 (Bootstrap the Phoenix Portal) as a NEW umbrella app
apps/portal_web in the existing Elixir umbrella. Read specs/phoenix/f6.1.md,
specs/phoenix/f6.1.stories.md, and specs/design/f0.md first.    # <- references
Do not change anything under the Portal facade: the engine (Portal.Engine), the store,
the contexts, and the Portal facade stay exactly as F5 left them.                 # <- topology: the boundary
Phoenix deps go ONLY in apps/portal_web/mix.exs, so apps/portal/mix.exs
stays Phoenix-free (the master invariant, compiler-enforced at the app level).        # <- topology: file scope

Read those lines first, the prompt is the references and the topology boundary, gathered. Read on, and it runs F6.1-AS1 through F6.1-AS4 in task order, satisfying F6.1-R1 through F6.1-R8 — the agent stories and the requirements, gathered. The endpoint the foundation step builds is the request lifecycle's front door, taught in the companion course. Across the whole prompt, no part of the brief is introduced fresh; every part is carried in.

The principle

The prompt assembles the brief's parts; each part it omits is a guarantee it cannot give. A complete prompt gathers all four into one runnable instruction.

On the Portal

f6.1.llms.md's prompt opens by naming the sources to read, the unchanged-facade boundary, and the Phoenix-deps-only-in-portal_web constraint — references and topology, folded in — then runs AS1–AS4 on their gates.

The implementation prompt does not write the brief over again; it gathers the four parts the brief already holds into one instruction the agent runs.

Recap — the prompt gathers, it does not invent

The fifth part of the brief is an assembly, not an addition. The implementation prompt carries the references, requirements, topology, and agent stories into one runnable instruction, and fixes no decision the spec has not already fixed. Each part it omits is a guarantee it cannot give — drop the references and the agent improvises a source; drop the topology and it loses the build order and the boundary. The next dive takes the gathered prompt and walks the order it runs the parts in.

Next in A5.5: Task order — the prompt runs the agent stories in the task-DAG order, keeping the tree compiling after each step.

References

Primary sources for assembling one complete, runnable instruction for an agent, and where the prompt's prior parts and the rung it builds are defined in the course.

Sources

Anthropic — Claude Code best practices — assembling a single, complete prompt a coding agent runs in order, not an open-ended goal.
llmstxt.org — The /llms.txt convention — the links-first machine-brief form the prompt gathers its references from.
Hunt, A. & Thomas, D. — The Pragmatic Programmer — pin every decision the builder must not have to invent.

Related in this course

A5.5 · The implementation prompt — the module hub.
A5.4 · Agent stories — the fourth part the prompt runs.
A5.3 · Execution topology — the third part the prompt folds in.
A5 · The agent brief — the chapter landing.
Companion · Phoenix request lifecycle — the F6.1 rung whose prompt this dive grounds on.