neeeophytee/finding-unknowns-skills

implementation-plan

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.

First seen Jul 5, 2026

Installation

$ npx skills add neeeophytee/finding-unknowns-skills --skill implementation-plan

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from neeeophytee/finding-unknowns-skills · top by installs.

npx skills add neeeophytee/finding-unknowns-skills

Browse all from neeeophytee/finding-unknowns-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 326
License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,019 B
  • docs SUMMARY.md 261 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 109 installs

SKILL.md

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.