Steering a running task
You are allowed to interrupt. A task that is going the wrong way will not fix itself, and the cheapest moment to say so is now.
A running task shows you what it is doing as it goes: the step it is on, the files it has touched, and anything it is waiting for. You can add a message at any point, and it is read as soon as the current step finishes.
What is worth saying mid task
| Situation | What to send |
|---|---|
| It is working on the wrong files | Name the right ones. Do not re-explain the whole job |
| It is about to produce the wrong shape | Say the shape. "One row per product per month, not per order" |
| It found a real problem and carried on | "Stop and show me those rows before continuing" |
| It is doing more than you asked | "Skip the charts. The sheet and the summary only" |
Short and specific beats a rewritten brief. The task already knows the job; it needs a correction, not a restatement.
Stopping
Stopping is always available and always safe in the sense that nothing half written gets hidden from you. What has already happened has happened, though. A file that was written two steps ago is still written, and a message that was sent is still sent, which is the argument for approval modes in lesson 15.
Knowing when not to interrupt
Two things look like problems and are not. A long pause usually means it is running something rather than thinking about it. And a first attempt that looks wrong is often an intermediate file it is about to use, not the result.
- Start a task, let it plan, then change one requirement while it works.
- Note how far it had already got. That distance is what a better brief would have saved.
Every expert started right here.