---

name: implementation-plan description: Write an implementation plan that leads with the decisions the user is most likely to change, and buries the mechanical work at the bottom. Use when planning is requested before a build, especially after brainstorming or an interview.

Implementation plan

A plan's job is not to prove you thought of everything. It's to put the reversible-but-expensive decisions in front of the user while changing them is still free. Order the plan by likelihood-of-tweaking, not by build order.

Steps

1. Open with a three-line summary: what is being built, the approach chosen, and the single riskiest assumption.
2. Section 1 — Decisions you'll probably want to tweak. Data model changes, new type interfaces, API shapes, anything user-facing. For each: the choice made, one alternative considered, and what changing it later would cost.
3. Section 2 — Known unknowns and how the plan absorbs them. Where ambiguity remains, state the default that will be taken and the signal that would trigger a pivot. A plan that admits its unknowns survives contact with the territory; one that doesn't just breaks quietly.
4. Section 3 — The mechanical work. Refactors, wiring, migrations, tests. Compress this; the user trusts you here and reviewing it is a waste of their attention.
5. End with the review request: the 2-4 specific items you want a yes/no or a pick on before starting.
6. If the plan is more than a screenful or the user prefers visual artifacts, offer it as a single self-contained HTML page — sections collapsible, tweakable decisions pinned to the top.

Guardrails

• If a genuinely better approach appears mid-planning, present the pivot as its own decision — don't silently re-plan.
• Keep it reviewable in minutes. A plan too long to read gets skimmed, and skimmed plans hide bad decisions.
• The plan should leave room for improvisation during implementation; over-specified plans fail exactly where the territory disagrees with the map.