| name | sp-plan |
| description | Use when the design is approved — breaks the work into bite-sized tasks (2–5 minutes each), with exact file paths, complete code, and verification steps for each task. Produces a plan a junior engineer with no taste and no context can follow. |
| license | MIT |
| metadata | {"author":"Adapted from JZKK720/superpowers (obra/superpowers, MIT)","source":"https://github.com/JZKK720/superpowers","source_skill":"writing-plans","version":"1.0.0"} |
Writing Plans
A design without a plan is a wish. A plan without bite-sized tasks is a deck. This skill produces a plan a junior engineer with no taste and no context can follow.
The contract
Every task in the plan has:
- Exact file paths (not "the user service" —
src/services/user.ts).
- Complete code (not "implement the validation" — the actual function body).
- Verification steps (not "test it" — the exact command and expected output).
- A 2–5 minute estimate (anything longer is two tasks).
- A commit boundary (when the task is done, the commit is ready).
Structure
# <Plan Title>
## Overview
<2–3 sentence summary. The why.>
## Tasks
### Task N: <verb + object>
**Files:**
- Create: <path>
- Modify: <path>
**Step 1: <verb>**
<complete code block>
**Step 2: Verify**
Run: <command>
Expected: <output>
**Step 3: Commit**
<git command>
---
(repeat for each task)
Task ordering
Order tasks by dependency, not by importance:
- Skeleton first — empty modules, empty functions, the wiring that connects them.
- Leaf data — types, schemas, fixtures.
- Leaf behaviour — pure functions, no I/O.
- I/O — adapters, gateways, side effects.
- Integration — wire the leaves into the I/O.
- Smoke test — end-to-end.
The first task should run a no-op end-to-end (start, do nothing, exit clean). Each subsequent task adds observable behaviour.
Hand-off
When the plan is written:
- Save to
docs/plans/YYYY-MM-DD-<topic>-plan.md.
- Announce: "Plan written. Invoking
cubecloud-execute next."
- The
cubecloud-execute skill takes over (executing-plans).
Plan review before execution
Before executing, run a quick self-review:
- Is every task 2–5 minutes? If not, split.
- Is every step complete? If not, fill in.
- Is every verification step runnable? If not, write the command.
- Is the order optimal? If not, reorder.
- Does the smoke test cover the user-facing outcome? If not, add a final task.
If the self-review fails, fix the plan. Don't execute a broken plan.
Anti-patterns
- "Implement the feature" — not a task. A task has a file path, a code block, and a verify step.
- Multi-hour tasks — split them. A junior engineer can't hold a 4-hour task in their head.
- "Refactor the codebase" — not a task. Refactor what, in which file, verified by which test?
- "Run the tests" as the only verification — the tests should be specific to the change.
- No commit boundary — every task should be a green commit. If a task leaves the tree in a broken state, the plan is wrong.
Related skills
cubecloud-brainstorm — the design step that precedes planning.cubecloud-execute — batch execution with checkpoints.cubecloud-tdd — every code-producing task in the plan must follow TDD.gstack-plan-ceo-review, gstack-plan-eng-review, gstack-plan-design-review — for reviewing an existing plan.
Source / license
Adapted from JZKK720/superpowers · writing-plans, MIT.
