Implementation plan
Skill Neeeophytee/finding-unknowns-skills/skills/implementation-plan
8 installable skills for Claude Code and OpenAI Codex, for finding your unknowns before they get expensive: blindspot pass, brainstorms, interviews, references, plans, notes, pitches, and a merge quiz. Community distillation, not official Anthropic.
npx -y skills add Neeeophytee/finding-unknowns-skills --skill implementation-planAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
2.0 KB, as published. Nobody here has run it
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
- Open with a three-line summary: what is being built, the approach chosen, and the single riskiest assumption.
- 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.
- 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.
- 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.
- End with the review request: the 2-4 specific items you want a yes/no or a pick on before starting.
- 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.