agentleFS
ToussaintKnightToussaintKnight/superpowers-workbuddy/skills/superpowers-plan/SKILL.md

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.

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
  1. Distinctive:

    Write comprehensive implementation plans that any developer can execute.

    line 12
  2. Distinctive:

    Use after the design is approved (via EnterPlanMode).

    line 20
  3. Distinctive:

    Before defining tasks, map out which files will be created or modified.

    line 24
  4. Distinctive:

    After writing the plan:

    line 85
  5. Distinctive:

    After saving the plan, present it to the user.

    line 92

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. Coverage check: Can you point to a task for each requirement?
  2. Placeholder scan: Search for "TBD", "TODO", vague instructions
  3. 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.