plan-trackinglisted

## Purpose A multi-step task loses steps when its plan only exists in working memory — a subtask gets implicitly dropped, a "come back to this" note never gets revisited, or the scope quietly drifts without anyone noticing it drifted. Writing the plan down, and updating it as steps complete, makes progress and remaining work visible to the user and to any agent picking the task back up. ## When to use it Any task that will take more than roughly 3 sequential steps, spans multiple files or subsystems, or is likely to be interrupted and resumed. Not needed for a single, self-contained edit — the overhead isn't worth it for something that's done in one pass. ## Steps / checklist 1. **Write the plan before starting**, as a short ordered list of concrete steps — not vague phases like "implement the feature" but specific, checkable actions ("add the `visibility` column + migration", "update `authorize_access` to check it", "add tests for the new denial case"). If the environment has a structured todo/plan tool, use it; otherwise a plain markdown checklist in the working notes is fine. 2. **Keep exactly one step marked in-progress at a time.** This makes it obvious, at a glance, what's actually being worked on right now versus what's queued. 3. **Update state as you go, not in a batch at the end.** Mark a step complete the moment it's actually done (built, run, confirmed) — not before, and not deferred until a later "cleanup the tracking" pass that may not happen. 4. **Surface