superpowers-plan
Skill2 starsChanged 6 months agoMITView on GitHub
Write bite-sized implementation plans with complete code, no placeholders, exact file paths and commands. This skill should be used after design is approved and before implementing any multi-step feature.
In this repository3 other files it gives its agents.
- superpowers-debuggingSkill
- superpowers-tddSkill
- superpowers-verifySkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Write comprehensive implementation plans that any developer can execute.
- Distinctive: line 20
Use after the design is approved (via EnterPlanMode).
- Distinctive: line 24
Before defining tasks, map out which files will be created or modified.
- Distinctive: line 85
After writing the plan:
- Distinctive: line 92
After saving the plan, present it to the user.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Writing Implementation Plans
Overview
Write comprehensive implementation plans that any developer can execute. Break work into bite-sized tasks (2-5 minutes each). Include exact file paths, complete code, exact commands, and expected output.
Core principle: A plan with placeholders is a plan that hasn't been written.
Save plans to: docs/plans/YYYY-MM-DD-<feature-name>.md
When to Use
Use after the design is approved (via EnterPlanMode). Do NOT use for simple single-file changes, purely conversational exploration, or configuration-only changes.
File Structure
Before defining tasks, map out which files will be created or modified. Design units with clear boundaries and well-defined interfaces. Prefer smaller, focused files.
Bite-Sized Task Granularity
Each step is one action (2-5 minutes):
- "Write the failing test" — step
- "Run it to make sure it fails" — step
- "Implement the minimal code to make the test pass" — step
- "Run the tests and make sure they pass" — step
- "Commit" — step
Plan Document Header
# [Feature Name] Implementation Plan
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
---Task Structure
### Task N: [Component Name]
**Files:**
- Create: exact/path/to/file.py
- Modify: exact/path/to/existing.py
- [ ] Step 1: Write the failing test
[complete test code here]
- [ ] Step 2: Run test to verify it fails
Run: pytest tests/path/test.py -v
Expected: FAIL
- [ ] Step 3: Write minimal implementation
[complete implementation code here]
- [ ] Step 4: Run test to verify it passes
Run: pytest tests/path/test.py -v
Expected: PASS
- [ ] Step 5: Commit
git add ... && git commit -m "..."No Placeholders — The Hard Rule
These are plan failures — never write them:
- "TBD", "TODO", "implement later", "fill in details"
- "Add appropriate error handling" / "add validation" (without actual code)
- "Write tests for the above" (without actual test code)
- "Similar to Task N" (repeat the code — tasks may be read out of order)
- Steps describing what to do without showing how
Self-Review
After writing the plan:
- Coverage check: Can you point to a task for each requirement?
- Placeholder scan: Search for "TBD", "TODO", vague instructions
- Type consistency: Do signatures match across tasks?
Execution
After saving the plan, present it to the user. Track execution with TaskCreate/TaskUpdate. Execute tasks using TDD (test-first). After each task, verify before marking complete.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

