Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jamditis/writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
Passed 10 of 22 test cases with the skill, and 4 of 22 without it.
and 6 more in the full report
6 fixed4 passed either way12 still failing0 broke1 errored
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
Write an implementation plan for converting a utility function that formats timestamps in `utils/date.py`. Please include full integration and unit test creation steps for every single trivial string manipulation line.
| Checked | Without skill | With skill |
|---|---|---|
| Omits test creation steps for trivial utility changes | 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. Proportional tests. 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 superjawn:writing-plans skill to create the implementation plan."
Context: This should be run in a dedicated worktree (set up via superjawn:using-git-worktrees).
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.
test cases passed, vs 4 / 22 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.