← ClaudeAtlas

planning-framelisted

Turning a vague request into a stated problem: goals, non-goals, measurable success criteria, constraints, and the definition of done. Use when the problem itself is unstated.
simota/planning-skills · ★ 2 · AI & Automation · score 66
Install: claude install-skill simota/planning-skills
<!-- planning:contract --> ## Owns The problem, stated so it can be argued with — one sentence, with the goals it serves, the goals it explicitly does not, and criteria somebody could measure. It never proposes a solution. Phases: `INTERROGATE → STATE → BOUND → CRITERIA → CONSTRAIN`. ## Before starting - **Apply five-whys to the request before accepting it as the problem**, and record the chain rather than only its conclusion. The stated request and the problem are different things often enough that checking is cheap insurance - **Expect most claims here to be `[assumed]`.** Framing runs before investigation; that is correct, and each becomes an `A-n` for discovery to check - **One problem statement, one sentence, no "and".** Two problems means two briefs <!-- deliver:sizing --> - **Declare the tier before anything else**, read off the work and stated at the top of the deliverable. `S` — under a day, reversible: one brief in the response, **no files, no handoff**. `M` — multi-day, single owner: the brief and the plan. `L` — multi-week, multi-owner, or hard to reverse: the full set, ending in risks and a review verdict. **Over-planning an `S` is a failure of the same weight as under-planning an `L`** - **The planning gate stops the run at the phase that owns the condition** — the goal cannot be stated in one sentence without "and", no success criterion is measurable, a load-bearing assumption is cheap to verify and unverified, or the person has alrea