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, so read this as a description of how the product works, not as instructions you can follow tonight.
/coldstart is how a session begins. It reads a small saved file that says where the last session
stopped, walks from that file to the plan the work belongs to, states in three or four lines what
this session is about, and then starts working. /go is the same command under a shorter name.
[Visual 1.1 — The session ring from the section opener, with the Start arc lit. Same four arcs (Plan, Start, Build, Close) in the same positions; Start is filled in the accent red and the other three drop to thin outline. The pointer card stays drawn at the Close-to-Start seam, and a short arrow runs from it into the lit arc, labelled "read first, before anything else". The two off-ring arrows to "the harness itself" are present but greyed, tagged "off-ring, see 1.5".]
The problem it solves
A conversation with a coding agent ends when you close the terminal. The next one starts empty. The agent does not remember which part of the project was in progress, what was deliberately left alone, which decision you made last week and would not want revisited, or what was already checked.
The usual repair is to paste a summary at the top of every new session. That works until the summary and the project disagree, which happens quickly and quietly. A summary is written from memory of a conversation; the project moves on in files.
The start verb replaces the pasted summary with a read. Everything it needs was written to disk by the previous session's close, so beginning a session is an act of reading current state rather than recalling an old conversation.
What it does during a real session
The walk has a fixed order.
It declares the kind of session on disk first. Before anything is read or written, the verb records that this is a build session. That declaration is a single field in the saved pointer and touches nothing else. It matters because other parts of the product read it: a session that has declared itself a build session is treated differently from one that has declared itself a planning session. Doing it first means the declaration is on disk before the first edit, not inferred afterwards from what happened.
It reads the pointer. The pointer is a short header at the top of the project's progress file. It carries the active section, the session mode, the next action, any blockers, and a short reading list. It is written by the machine at every close, which is why it can be trusted as the single resume truth: no human is asked to keep it accurate by hand.
It walks from the pointer to the plan. The pointer names a section. A section has a folder of its own holding the plan card for the work: the goal, the files to read, the build steps, the files expected to change, and the checks that would establish the result. The verb reads that card.
It commits to a reading list out loud. The pointer's reading list is the declared set of files for this session. The verb states that list before reading, so anything read outside it is visible to you as it happens rather than discovered later in a diff.
It announces the scope in three or four lines: the goal in one sentence, the read list, and any blockers. The one-sentence goal doubles as a sizing test. If the sentence needs an "and" to be true, that is usually two sessions wearing one name, and the right response is to stop and say so rather than start both.
Then it builds. It continues into the plan's steps and stays inside the scope the announcement named. Work that turns out to fall outside that scope is a pause and a question, not a quiet extension.
The inventory, when the picture is what you want
There is a second, separate print available at this door: a five-block inventory of what the installed harness actually is. Where you left off, the always-loaded core, the dock, the rules that must fire, and the stored project record. Every number in it is read from the component that owns that number rather than restated from documentation.
It is worth running when you are returning after a gap, when one of the steps above reports something missing, or when your real question is "what is installed here" rather than "what is next". It renders and decides nothing, so it never substitutes for the pointer walk and the announcement. That distinction is deliberate: an earlier version of this product's front door printed a picture and stopped there, which looked informative and started no work.
When the project has nothing to resume
A fresh project has no pointer. A project mid-setup may have a pointer but no active section, or an active section whose plan card is still a stub, or a session block already marked done.
In each of those cases the verb prints one line saying what is actually on disk and suggests planning before building. It does not invent a plan to proceed with. An invented plan is the worst of both outcomes: the session starts confidently and the confidence is unfounded.
When to use it, and when not
Use it to begin any working session on a project that already has a plan, and use it again mid-session when you want the scope announcement repeated. An explicit invocation always re-announces, even if the same orientation was injected automatically when the terminal opened.
Do not use it to look around. Reading the pointer, walking into the plan and starting work are one motion here, and that is the point of it. When you want to see where things stand without committing the session to work, the read-only verb on the next page exists for exactly that.
Do not use it to plan. If the work has no plan yet, this verb sends you to the planning pass rather than improvising one.
Limits
The announcement is a statement of intent, not a guarantee of behavior. It says what the session understands its scope to be. It cannot promise that nothing outside that scope will be touched; what it does is make a departure visible to you at the moment it happens, which is a weaker and more honest claim.
The pointer can be stale or wrong. It is written at the close of the last session, so it reflects what that session believed when it ended. A concurrent session, a manual edit, or a close that recorded an optimistic next action all produce a pointer that reads confidently and points at something that has moved.
The one-sentence goal test is a heuristic. Some coherent jobs contain the word "and", and some oversized jobs hide behind a short sentence.
Nothing here measures whether the work is good. The verb establishes where you are and what the agreement is. Verification is a separate responsibility that belongs at the close.
Next
The same walk, with the building deliberately removed, is looking without touching.
How current this page is
Checked on 10 August 2026 against the product's current start behavior and its recorded release state. It describes what the command does, not evidence that sessions started this way produce better results. To ask whether a claim here still holds, or to report one that does not, write to [email protected].