Your agents have roles, a board to pull from, and a ledger that records what happened. What is still improvised is the part in between: how a task actually gets done. Ask for the same kind of work twice and you get two different routes, and the thinking behind both dies when you close the window. This chapter pins the route down.
9.15.1What happens in the session does not survive it
Most of what a working session produces is not the code. It is everything around the code: why that approach and not the other one, what the agent checked, what it ruled out, what broke on the first attempt. Close the window and all of it is gone.
A task workflow fixes that. It is one path every request walks, where each stop leaves a file behind. If a stop produced nothing on disk, it did not happen. The chat is where work gets discussed; the repository is where it gets kept.
9.15.2One path, six stops
Every request, however small, walks the same path:
- Ticket. Open one on the board before anything else, so the work exists outside the chat.
- Research. Read the code, the docs, and the decisions that already cover this, then write the findings down.
- Spec. State what will change and what done looks like, and get your yes before any code.
- Build. Implement only what the spec says, in slices.
- Verify. Run the tests and the app. A green run is the proof, not the agent's opinion.
- Record. Close the ticket, log any real choice as a decision, and note the outcome.
A one-line fix walks it in minutes and a feature takes a week. The path does not change, only the size of each stop.
9.15.3Three kinds of work walk it differently
Almost everything you will ever ask for is one of three things. The difference shows up at stops two and three:
| Kind of work | Research means | Written down before building | The trap |
|---|---|---|---|
| Feature. Add, change, or remove something users see | Read the spec and the decisions that already cover it | What changes, and what done looks like | Building before anyone wrote down what done means |
| Bug. Something is wrong and you want it right | Reproduce it, then find the cause | The cause, and a failing test that proves it | Fixing the symptom you can see instead of the cause |
| Improvement. Nothing is broken, something could be better | Measure the thing you want to improve | The number to beat, taken before you touch anything | Changing code because it feels untidy, with nothing to compare |
Removing a feature is a feature change, not a cleanup, and it takes the same path. Deletions break things exactly as often as additions do.
Improvement is the one people run wrong. Speed, security, readability, scale, and stale documentation all live here, and every one of them needs a before-number or a named weakness first. Without one you cannot tell improvement apart from churn, and neither can your agent.
9.15.4Who starts it does not change the path
Work reaches the path three ways: you ask for it, something in the system reacts to an event, or the clock starts a scheduled run. The last two get built later in this part.
None of them is a shortcut. An agent woken by a schedule at three in the morning opens a ticket, researches, and records the outcome exactly like you would. The whole value of the path is that a week later you cannot tell which work was yours.
Here is the whole thing on one page, from whatever started it to the records it leaves behind:
The ticket is the hub. Everything the work touches hangs off it: the change that shipped, the reasoning behind it, and the feature document that now describes how the thing behaves.
9.15.5Demand evidence, not recall
Research is the stop people cut first, and it is the one that saves the most rework. An agent that has not opened your code will cheerfully invent how it works, and everything built on that invention has to come out again.
So write the standard down: every claim about your system names the file it read or the command it ran. No "should be", no "probably". If it did not check, it says it did not check.
9.15.6Write the path into the rules file
A path you have to remember to ask for is not a path. It belongs in the file your agent reads before every session, as a procedure it follows without being told:
9.15.7Put your agents on the path
Do this now: paste the prompt so the path lands in your rules file, then run your next task through all six stops without skipping the research.
