Localized reading guide
writing-plansPurpose, usage and source
Use when you have a spec or requirements for a multi-step task, before touching code
Source retrieved:
- Source repository
- obra/superpowers
- SKILL.md
skills/writing-plans/SKILL.md- Repository stars
- 309,479
- Repository updated
- 2026-10-30
- Categories
- Agent workflows
- Last collected
License: MIT
Workflow excerpts are reading aids, not executable instructions from Codez. No third-party Skill was run to produce this page.
The purpose and workflow passages below are upstream material, organized and translated for reading. They are distinct from the separately labeled Codez editorial analysis.
What this Skill does
Use when you have a spec or requirements for a multi-step task, before touching code
How the upstream workflow works
Overview
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-.md
Step Granularity
Each step is one action with a checkable result: "Write the failing test" - step "Run it to make sure it fails" - step "Implement the minimal code to make the test pass" - step
Upstream passage · L43 ↗What a Step Contains
A step is done when the implementer can write exactly one reasonable thing from it. That is the whole requirement: unambiguous, not complete. Each kind of step carries what makes it unambiguous and nothing more: A test step: the test's name and its assertions, as code, with the spec's exact values in them. A code step: the exact signature (name, parameters, return type), the file it lives in, and the specific values the spec pins. The implementer writes the body. A body appears only for an algorithm the signature and tests do not determine, or for exact copy the spec fixes. A verification step: the command to run and the output that means it passed.
Upstream passage · L140 ↗Requirements and setup
No short requirements passage was selected from this file. This does not mean the Skill has no dependencies. Check the repository setup instructions and referenced files.
Limits and quality checks
No separate limits passage was selected from this file. This does not mean the Skill is safe for every input or environment. Review the complete source and validate your own result.
Start with a safe trial
- Check the supported host and the repository installation instructions. Keep the Skill directory and its referenced scripts, assets and documentation together; SKILL.md alone may omit dependencies.
- Give the agent your real input, desired output and acceptance criteria. Invocation syntax and available tools depend on the host; this site does not assume a universal install command.
- Try the source workflow in a disposable project or on a copy. Review operations that change files, remote services or billable resources before allowing them.
- Validate the output against the source quality checks and your own requirements. A successful trigger or a high repository Star count does not establish a correct result.
Read further in the source
Related Skills
Translation and scope
This reading guide selects passages from the pinned upstream SKILL.md. Translation is assisted. It is not a complete manual or a claim of tested compatibility. Read the original and its referenced files before use.
This introduction refers to the pinned version below; current repository activity and collection time are shown separately.
- Pinned source
- Read the original ↗
- Source retrieved
- Source commit
2ce8aa15d05bd57213e6f746f953aafb7ded7a8b- Source SHA-256
a6c67c1900064347c2a329990dd3c555657c51c3ec53b259a08aa01a2c26139a