implementation-plan

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.

From Neeeophytee/finding-unknowns-skills, MIT.

More from Neeeophytee/finding-unknowns-skills