The work loop

The previous section taught the verbs you type: /prep to plan, /coldstart to start, /orientate to look without starting, and /done to close. This section follows one change through the work those verbs organize: add a CSV export for the orders already visible under the app's filters. The approved columns are known, a background job has been rejected for now, and historical order IDs are deliberately excluded for later work.

Coldstart moves that bounded change through four handoffs. /prep writes the agreement. A session opened with /coldstart makes the change inside it. /done checks the promised result and records the outcome, then rewrites a seven-field block at the top of docs/PROGRESS.md — the resume pointer — which is the address a fresh session reads to find its way back in. That repeating sequence is the work loop.

The four stages

Why it is a loop and not a checklist

The planning pass runs once per project and once per section, not once per session. Everything after it repeats: /coldstart, one bounded piece of work, /done, close the terminal, open a new one. The pointer makes that repetition possible, because it gives the next session an address back into the files. It is not the whole handoff, though, and it is not the only file that survives — the plan files and the project's authored records outlive it.

That is the honest boundary of the whole method. The loop does not preserve a conversation, it preserves files. Anything decided out loud and never written down does not come back. And what repeats is the shape of the work, not a demonstrated improvement in how it turns out — running the four stages establishes that the handoffs happened, not that the result is better for them.

What the stages do not share

Each stage deliberately declines the others' work. The planning pass writes no code, and the product enforces that rather than requesting it: /prep writes mode: prep into the pointer before it announces anything, and a boundary check reads that field and refuses other writes while it stands. The bounded session does not decide whether the work is good; that judgment belongs at the close. The close does not extend the work; it verifies what happened and records it. The pointer holds an address, not a summary.

Keeping them separate is what stops the common failure where the first implementation choice quietly becomes the architecture, or where "the code is written" quietly becomes the finish condition.

The same export without the loop

For a small one-off app, a manual workflow can be enough: write a task note, make the export, run the tests and leave a short handoff. Nothing about Coldstart makes those ordinary steps invalid.

The cost appears when the change crosses sessions. The approved fields may live in chat, the rejected background-job idea may return as if it were new, and the historical-ID exclusion may be mistaken for forgotten work. Coldstart makes those three handoffs explicit and checks the close before it lets the work be called done.

What this section does not cover

These pages describe the shape of one unit of work. They do not describe what the project remembers between units, how the right instruction reaches a session, or which rules are enforced rather than requested. Those are later sections, and each one explains a mechanism this section depends on.

Next

Start where the work starts: the planning pass.