Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →getcrew44/writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
Passed 9 of 20 test cases with the skill, and 11 of 20 without it.
and 3 more in the full report
4 fixed2 passed either way15 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
Draft an implementation plan to add S3 file uploading capability to a NestJS microservice. Make sure every command and test step is explicitly written.
| Checked | Without skill | With skill |
|---|---|---|
| The plan details expected terminal outputs for test runs. | Passed | Passed |
| The plan includes git commit commands within task sequences. | Missed | Passed |
The instructions your model reads when the skill loads.
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
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.
Each step is one action (2-5 minutes):
test cases passed, vs 11 / 20 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.