| name | project-planning |
| description | MANDATORY planning protocol. You MUST invoke this skill when turning a decided goal into an execution plan — breaking a project or feature into sequenced tasks, milestones, or a roadmap; "plan this out", "what's the build order", "break this into steps". Do NOT hand back a flat to-do list. Do NOT bury the riskiest work in the middle. Invoke BEFORE presenting any multi-step plan. Does NOT apply to estimating effort (use estimation) or choosing between approaches (use decision-analysis).
|
Project Planning Protocol
EXTREMELY_IMPORTANT: This is a MANDATORY protocol, not a suggestion. Follow every step.
Do not skip steps. Do not combine steps. Do not summarize. Work through each gate in order.
A plan is not a list of things to do — it is a sequence chosen so that failure is cheap,
progress is visible, and nothing starts before what it depends on exists. A flat to-do
list ordered by what came to mind first is the failure this protocol prevents.
STEP 1 — Decompose into done-able tasks
Break the goal into tasks. Apply the test to EACH: "Can I write a testable done-criterion
— a state someone else could confirm is reached?" ("done when a request to /login returns
a session cookie"). A task you cannot write a done-criterion for is not a task yet — split
it, or if it is an open question move it to an unknowns list and mark it for a spike.
STEP 2 — Make dependencies explicit
For each task, name what must already exist before it can start. This ordering is forced
by the work, not by preference. A task with no stated dependency is either genuinely
foundational (say so) or you have not looked hard enough (look again).
STEP 3 — Pull the riskiest task to the front
Name the single task with the most uncertainty or the highest cost-if-wrong — the one
most likely to invalidate the rest of the plan. It goes FIRST, or a timeboxed spike for it
does, so a wrong assumption is caught while it is cheap to fix. If your sequence puts it
late, re-sequence it or state explicitly why it cannot move earlier.
STEP 4 — Group into demonstrable milestones
Group tasks into milestones. Each milestone must be a state you could SHOW someone — "a
user can log in and see their orders" — never an internal-progress label like "phase 1" or
"auth 50% done". A milestone with no observable deliverable is a schedule, not a plan.
STEP 5 — Report
PLAN: [goal]
├── Tasks: [task → done-criterion, one line each; unknowns flagged]
├── Dependencies: [what-blocks-what, or "foundational" where none]
├── Riskiest-first: [the task/spike sequenced first, and why it dominates]
├── Milestones: [each a demonstrable state, in order]
└── Confidence: [HIGH / MEDIUM / LOW]
Confidence: HIGH — tasks all done-able, dependencies clear, riskiest work de-risked
early. MEDIUM — some tasks rest on unknowns now scheduled as spikes. LOW — the
riskiest task cannot be pulled forward, or several tasks resist a done-criterion.
Do NOT present the plan until:
- Every task has a testable done-criterion, or is a named unknown routed to a spike
- The single riskiest task is sequenced first (or spiked), with that choice stated
- Every dependency is explicit — no task's prerequisites are left implied
- Every milestone is a demonstrable state, not an internal-progress label
A flat task list with no done-criteria and no risk-driven ordering is a protocol
violation, even if the user asked for "just the steps".
Red flags that this skill catches:
- "I'll just list the obvious steps in order" — order by risk and dependency, not by
recall. That reordering IS the plan.
- "The done-criteria are obvious, I don't need to write them" — unwritten done-criteria
are where 'I thought that was finished' comes from. Write them.
- "We'll tackle the hard part once the easy parts are done" — that is exactly backwards;
the hard part decides whether the easy parts were worth doing.
- "Milestone 1 is 'set up the project'" — set up toward what demonstrable state? Name it.
Handoff
Once the plan is accepted, hand each milestone to execution. If effort or dates are
needed, run estimation on the task breakdown first; if a task is a named unknown, run
its spike before committing the milestones that depend on it.
