Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →guanyang/writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
Passed 5 of 19 test cases with the skill, and 14 of 19 without it.
1 fixed0 passed either way19 still failing3 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
We have a spec file `specs/ecommerce-overhaul.md` that covers three independent subsystems: a Redis session store, a GraphQL catalog gateway, and an S3 asset processor. Please draft a single combined implementation plan containing all tasks for all three subsystems together.
| Checked | Without skill | With skill |
|---|---|---|
| The response recommends decomposing the multi-subsystem spec into separate implementation plans for each subsystem. | Missed | Passed |
| The response states that each individual plan should produce independently working and testable software. | Missed | Passed |
The instructions your model reads when the skill loads.
Write implementation plans for an engineer who has not seen this codebase or this spec. Assume they write idiomatic code in the project's language once they know the exact interface and the exact test, and that they will make a reasonable choice wherever the plan leaves one open. What they cannot know is what you decided: which files, which names and signatures, which values from the spec, which tests prove each task. Document those. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Announce at start: "I'm using the writing-plans skill to create the implementation plan."
Context: If working in an isolated worktree, it should have been created via the superpowers:using-git-worktrees skill at execution time.
Save plans to: docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md
If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.
Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.
A task is the smallest unit that carries its own test cycle and is worth a fresh reviewer's gate. When drawing task boundaries: fold setup, configuration, scaffolding, and documentation steps into the task whose deliverable needs them; split only where a reviewer could meaningfully reject one task while approving its neighbor. Each task ends with an independently testable deliverable.
Each step is one action with a checkable result:
test cases passed, vs 14 / 19 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.