implementation-planninglisted

# Implementation Planning ## Purpose Translate an accepted outcome into the **smallest credible execution path** for the actual repository. A useful plan reduces avoidable rework, makes dependencies and verification visible, and still leaves the coding agent free to adapt when implementation reveals new evidence. ## When to use Use this capability when: - a change spans multiple files, layers, packages, services, schemas, or verification steps; - ordering matters; - an unfamiliar repository or hidden dependency makes direct editing risky; - the task has explicit acceptance criteria that should trace into implementation and tests. For a trivial local edit with obvious verification, use a one- or two-step mental plan rather than generating ceremony. ## Inputs Prefer: - repository map or equivalent local understanding; - acceptance criteria; - applicable project instructions; - known risks, constraints, and unresolved questions. Do not plan from the user prompt alone when the repository can materially change the right approach. ## Core principles ### Plan outcomes, not keystrokes A plan should explain **what must become true and how it will be proven**, not predict every line of code. ### Minimize simultaneous uncertainty Sequence work so that uncertain interfaces, reproduction steps, schemas, or external assumptions are resolved before downstream work depends on them. ### Prefer reversible steps When two approaches are otherwise comparable, prefer the one that