Coldstart is in final cutover and has not been released. The commands on this page run in the development build; there is no release you can install today.
/done closes a session. It walks the checks the plan named, then hands a single tool every write
to the project's live state: the pointer the next session reads, the one-line record of what
happened, the regenerated maps, and the note that carries anything worth knowing forward.
[Visual 1.4 — The session ring with the close segment lit. The same four-arc ring, Close filled in the accent red. Flowing out of the lit Close arc, three stacked bands drawn left to right as a single pipeline. Band one, "Walk the checks", holds a small list with three states drawn as distinct marks: passed, could not run, failed. A red stop bar sits at the end of that band, labelled "a failed critical check ends the close here". Band two, "One tool writes", is drawn as a single funnel: several arrows converge into one nozzle labelled with the tool's name, and out of the nozzle a fan of short arrows reaches the pointer card, a one-line session record, a regenerated map, and a memory file. Band three, "Hand off", shows two small cards labelled decisions and gotchas being placed into a drawer, plus a staged file list and a suggested commit line. Caption: "nothing writes to live state except through the funnel".]
The problem it solves
Two things reliably go wrong at the end of a working session, and they compound.
The first is that "done" gets decided by the wrong evidence. The code is written, the conversation reads like success, and the session ends. Whether the thing actually works was never established, because writing the code and demonstrating the result feel like the same event from inside the conversation.
The second is that everything the session learned evaporates. Which check was run, which was skipped and why, what the next action should be, which assumption turned out to be wrong: all of it was in a conversation that is about to be closed. The next session begins by reconstructing it, or more often by not reconstructing it.
The close is the point where both are addressed, and it is deliberately a distinct act rather than a natural consequence of stopping.
What it does
It walks the check list from the plan card, item by item. Not a summary. Each check named in the plan is reported with what actually happened to it: passed, could not be run, or failed. An unrun check stays unrun in the record rather than being folded into a general impression.
A failed critical check stops the close. The session either fixes it now or is recorded as blocked. Writing "done" over a red check is the specific outcome this step exists to prevent.
It composes the writeback. A short structured description of the session: which section, which session number, what it did in under a hundred characters, what the next action is in under eighty, the plan card the work lives at, the reading list for the next session, any blockers, and optionally one human-readable resume note. Closing a whole section adds a one-line status entry for the master plan and hands the pointer on to the next section.
The length limits are not decoration. The pointer is the file every future session reads first, and a pointer that grows into narrative stops being a pointer.
It runs one tool, and that tool owns every write. The pointer, the session record, rolling old history out of the live plan, regenerating the generated maps, the memory branch, and clearing the session trace all happen inside a single program. Nothing else edits those surfaces. That is what makes the pointer trustworthy enough for the next session to read without checking: it has exactly one author.
It reports the outcome faithfully, including refusal. The tool can refuse. A refusal names a specific defect in the project tree, and the response is to fix what it names and run it again. It is never to hand-edit the machine-written file so the check passes. A separate, more serious exit means the harness itself is broken, and the right response there is to stop and say so rather than work around it.
It answers the handoff question with cards, not prose. Things worth carrying forward are written as small records in their own places: decisions in one folder, gotchas in another. They do not go into the pointer. The finished session's block is rolled out of the live plan card into a dated history file, so the plan card stays a description of live work rather than an archive.
It stages the changed files by name and suggests a one-line commit message. Never a blanket "stage everything", because a blanket stage is how an unrelated file joins a commit and how a secret leaves a machine.
When to use it
At the end of every working session, including one that achieved less than intended. A session that ran into a blocker and stopped has something worth recording precisely because it stopped, and the record of why is what stops the next session repeating the attempt.
Also use it when you are about to switch context for long enough that you will not remember the details. The close is cheap compared with the reconstruction it prevents.
Do not use it to declare success you have not established. It is a recording mechanism, and it will faithfully record an unverified claim if you give it one.
Limits
The tool enforces structure, not truth. It checks that the writeback is well-formed, that the project state is consistent, and that the machine-owned surfaces are regenerated. It cannot check that "did" is an accurate description of the session or that the next action is the right next action. Honest input remains a human responsibility.
Walking the check list is a discipline, not a proof. The checks are only as good as the plan that named them, and a weak check that passes is still a check that passed.
The pointer narrows the route back to current state. It is not a memory of the session. Detail that was never written into a decision card, a gotcha, or the plan is gone when the terminal closes, and no part of the close can recover what was not recorded.
Coldstart has not demonstrated that closing sessions this way improves the quality of the work. The claim it does make is narrower: the next session starts from a written record with one author rather than from recall.
Next
Two verbs act on the harness rather than on the work: sweeping and re-deriving.
How current this page is
Checked on 10 August 2026 against the product's current close behavior and its recorded release state. To ask whether a claim here still holds, or to report one that does not, write to [email protected].