Task order

The prompt does not list its work as a set. It lists it as a sequence — the task DAG turned into seven numbered steps, each leaving the tree compiling.

Assembling the prompt gathered the four prior parts; this dive teaches the spine that holds them in line. The prompt's one governing instruction is build in this order, keeping the umbrella compiling after each step. Follow it and the agent never holds a half-compiling tree. Step through the seven steps on the right to see each one's task and the requirement it closes — then move one out of order in the figure below and watch a dependency break.

The build order Out of order On the Portal References

The prompt's seven steps · step through T1 to T7

Step 1 of 7 — Foundation (T1): create apps/portal_web, add the Phoenix deps and the entrypoint, telemetry, and endpoint config. The umbrella compiles after this step. The prompt runs the stories in the task-DAG order, T1 to T7.

The build order

A5.5.1 assembled the prompt from the four prior parts — references, requirements, topology, agent stories. This dive is about the prompt's spine: the order it runs them in. The prompt does not hand the agent its work as a pile to pick from; it hands it as a sequence. In f6.1.llms.md that sequence is seven numbered steps, and they are exactly the topology's task DAG — T1 through T7 — flattened into instructions a person can paste and an agent can run top to bottom.

One line governs all seven: build in this order, keeping the umbrella compiling after each step. That is not advice; it is the DAG's invariant restated. Each step satisfies a numbered requirement and depends only on steps before it, so every prefix of the build compiles. Foundation (T1) lays the new app; Endpoint (T2, satisfies R1) raises the front door; Supervision (T3, R2) wires it into the tree after the engine; Router (T4, R3, R6) adds the :browser pipeline, the courses route, and GET /health; Controller (T5, R4, R8) calls Portal.courses_of/1; View (T6, R5) renders from assigns; Verify (T7) closes on the gates.

The principle

The prompt runs the agent stories in the task-DAG order, so the tree compiles after every step. Each step depends only on a step already built.

On the Portal

f6.1.llms.md's prompt builds Foundation → Endpoint → Supervision → Router → Controller → View → Verify, keeping the umbrella compiling and tracing each step's [R…].

The router step (4) is the one the controller step (5) leans on — the companion course builds it at Phoenix · routing · routes, the route that dispatches to the controller action.

Out of order, a dependency breaks

The order is not a preference; it is a dependency graph. Step 5, the Controller, is dispatched to by the route the Router step (4) defines, and it runs through the :browser pipeline the same step declares. Build the controller before the router and the action it answers has nothing to call it, and the pipeline it expects is not there. The prompt's one-line invariant — the umbrella compiles after each step — no longer holds.

Toggle the figure between the written order and a swap that moves the controller (step 5) ahead of the router (step 4). As written, every prefix compiles: zero broken dependencies. Swapped, one edge points backwards — a step depends on a step that has not been built yet — and the tree breaks.

As written, or controller before router · toggle the order

As written: the tree compiles after every step. Broken dependencies: 0 of 6 — each step depends only on a step already built. The prompt is the task DAG topologically sorted into a list the agent runs top to bottom.

Task order in the prompt is the task DAG made into instructions — follow it and the build never holds a broken tree.

On the Portal

The Portal's web bootstrap ships from f6.1.llms.md, and its implementation prompt spells the order out as seven numbered steps under one heading: build in this order, keeping the umbrella compiling after each step. Each step carries its task and the requirements it closes, so the order is not only runnable but traceable — a reviewer reads which requirement is satisfied at which step.

# f6.1.llms.md — the implementation prompt, in task order (T1 → T7)
#
1) Foundation  → T1          # apps/portal_web: phoenix deps (NO ecto), entrypoint, telemetry, endpoint config
2) Endpoint    → T2  [R1]    # PortalWeb.Endpoint: the plug stack + the LiveView socket
3) Supervision → T3  [R2]    # PortalWeb.Application [Telemetry, Endpoint]; Portal.Application drops Bandit (Store retained)
4) Router      → T4  [R3,R6] # :browser pipeline + get "/courses/:user_id" + GET /health → 200 "ok"
5) Controller  → T5  [R4,R8] # index/2 over Portal.courses_of/1 only; a domain error → 422  (needs step 4)
6) View        → T6  [R5]    # CourseHTML + index.html.heex + error.html.heex, from assigns only
7) Verify      → T7  [R7,R8] # compile, boot, /health, render + empty state, 422, self-heal, invariant grep + DoD

The dependency the swap exposes is between steps 4 and 5: CourseController.index/2 is the action that get "/courses/:user_id" dispatches to. Build the controller first and the route is not there to reach it; the agent holds a tree that names an action no route answers. Run the steps as written and every prefix compiles — the property the prompt's one line promises.

The principle

A prompt's task order is a topological sort of the dependency graph; a step may run only after the steps it needs, so no prefix of the build is broken.

On the Portal

f6.1.llms.md orders the seven steps so the Endpoint precedes the Supervision wiring, the Router precedes the Controller, and the Controller precedes the View — the umbrella compiling after each.

The prompt's numbering is the build order written down: the agent runs it top to bottom and never has to decide what comes next.

Recap — the order is the DAG, made runnable

The implementation prompt runs the agent stories in the task-DAG order — Foundation, Endpoint, Supervision, Router, Controller, View, Verify — under one governing line: build in this order, keeping the umbrella compiling after each step. Each step satisfies a numbered requirement and depends only on the steps before it, so every prefix of the build compiles; reorder the controller ahead of the router and a step dispatches to a route that does not exist yet. The next dive closes the prompt on its gates — the Definition of Done the agent self-checks against, and why a prompt missing them is incomplete.

Next in A5.5: Definition of Done — the verification step the prompt ends on, and why a prompt without it is incomplete.

References

Primary sources for ordering an agent's work as a runnable sequence and for the build-order discipline, and where the task DAG and the rung this prompt builds are defined in the course.

Sources

Anthropic — Claude Code best practices — giving a coding agent an ordered, incremental plan so each step builds on a known-good state.
Hunt, A. & Thomas, D. — The Pragmatic Programmer — tracer bullets and small, always-running increments: keep the build compiling at every step.
llmstxt.org — The /llms.txt convention — the links-first machine brief whose task order this prompt makes runnable.

Related in this course

A5.5 · The implementation prompt — the module hub.
A5.3.2 · The task DAG — the build order this prompt turns into instructions.
A5.4 · Agent stories — the stories the prompt runs in task order.
Companion · Phoenix request lifecycle (F6) — the rung this prompt builds.
Companion · Phoenix routing · routes — the router step the controller step depends on.