Slash command: Write Superpowers Plan

---
description: Write a Superpowers plan from an existing spec, split into small per-task files
argument-hint: [path to the spec/design doc, or the feature it describes]
allowed-tools: Read, Glob, Grep, Edit, Write, TodoWrite, Task, Bash(git status:*), Bash(git diff:*)
---

Use the Superpowers writing-plans skill to produce an implementation plan for: $ARGUMENTS

Brainstorming is already done. Do NOT invoke the brainstorming skill, do not re-open
requirements, and do not ask clarifying questions. Read the spec/design doc and plan
from it as written. If the spec is silent on something, make a reasonable choice and
record it under Global Constraints in 00-overview.md rather than stopping to ask.

Follow the Superpowers writing-plans workflow:

- Map which files get created/modified BEFORE defining tasks
- Structure every task for TDD (red -> green -> refactor)
- Each step must be a single concrete action, ~2-5 minutes

## Plan location - let Superpowers decide, but write a DIRECTORY

Do NOT hardcode a plan path. Use whatever location and filename the Superpowers
writing-plans skill would use by default. Then apply one override:

Where the skill would write a single plan file:

    <its-plan-dir>/<its-plan-name>.md

instead create a directory of the SAME name and write the plan inside it:

    <its-plan-dir>/<its-plan-name>/
    ├── 00-overview.md
    ├── 01-<kebab-noun-phrase>.md
    ├── 02-<kebab-noun-phrase>.md
    └── 03-<kebab-noun-phrase>.md

The skill's own docs state that user preferences for plan location override its default.
This is that preference: same directory, same plan name, one file per task.

Before writing, state the resolved plan path you are using.

## Sizing - decide before writing, never after

All sizing decisions happen ONCE, while building the task index in 00-overview.md.
After the index is written it is final.

A task is one test cycle (writing-plans "Task Right-Sizing"): a reviewer could
reject it while approving its neighbours. Draw task boundaries so that each task:

- creates or modifies at most 3 files (tests excluded)
- has at most 6 steps: the 4 TDD steps (failing test, run-fail, implement,
  run-pass) plus at most 2 more. There is no commit step - see "No commit steps".
- ends with an independently testable deliverable

If a candidate task needs more than that, it is two tasks. Give both their own
number in the index (03, 04). Never use sub-folders or 03a/03b suffixes -
renumbering before anything is written is free; splitting afterwards is not.

Once the index is final:

- Write 00-overview.md FIRST, then task files one at a time, in index order.
- Write each file in its OWN separate Write call. Never emit multiple tasks in one call.
- Write each task file exactly once. Do NOT read files back to count lines,
  and do NOT split, merge or renumber tasks after writing has started.
- Length is not a metric. If a task file feels long, it contains code bodies.
  Keep signatures, test names and assertions; drop the bodies
  (writing-plans "Proportion" rule). Do not split it.

Naming: the plan directory name comes from the skill. INSIDE it, files are zero-padded
two digits. Numbers give ORDER, not scheduling - dependencies live inside the files.
Slug is a short noun phrase, no verbs. Filenames under ~40 chars.
Never encode dependencies or waves in filenames.

## 00-overview.md

Carries the Superpowers plan header and project-wide context ONLY:

- The required Superpowers agentic-worker header block (REQUIRED SUB-SKILL:
  superpowers:subagent-driven-development or superpowers:executing-plans)
- Goal: one sentence
- Architecture: 2-3 sentences
- Tech Stack: key technologies/libraries
- Spec: path to the spec/design doc this plan implements
- Global Constraints: project-wide requirements, exact values copied verbatim from the spec.
  Every task's requirements implicitly include this section.
- Review Focus: the failure modes the spec implies but no task's tests exercise,
  one line each; each one gets a test added to the task that owns the code
- Task index: | file | one-line goal | depends-on | files touched |

Do NOT restate task contents here. Keep it short.

## Each task file

Standard Superpowers task structure, one task per file:

- Depends on: (task numbers, or "none")
- Files:
  - Create: exact/path/to/file.py
  - Modify: exact/path/to/existing.py:123-145
  - Test: tests/exact/path/to/test.py
- Interfaces (omit any line that would be empty):
  - Consumes: what this task uses from earlier tasks (exact signatures)
  - Produces: what later tasks rely on (exact names, params, types)
- Steps: checkbox `- [ ]` syntax, TDD order (write failing test -> run, expect fail ->
  implement -> run, expect pass), each step a single 2-5 minute action.
  The last step of every task is "run tests, expect PASS". Nothing comes after it.
  Test steps carry the test as code with the spec's exact values. Code steps carry
  the exact signature and file; a body only for an algorithm the tests do not determine.
- Review checkpoint: at most 3 bullets on what the code-reviewer should verify

Each task file must be independently followable by someone who has read 00-overview.md
and nothing else.

## Self-review - one pass, fix inline

After all files are written, run the writing-plans self-review ONCE against the spec:
spec coverage, step scan, type consistency across tasks, review focus, proportion.
Fix problems with targeted Edits in the file where they live. Do not re-review,
do not rewrite files wholesale, do not revisit task boundaries.

## No commit steps

This overrides the writing-plans skill. Its task template ends with
"Step 5: Commit" and its overview says "Frequent commits". Do NOT follow that here.

- No task may contain a commit step, a `git add`/`git commit` command, a commit
  message, or any mention of committing, staging, pushing or branches.
- Do not replace it with a substitute ("save your work", "checkpoint here").
  The task simply ends at "run tests, expect PASS".
- Committing is handled outside the plan by the run command and is not a
  concern of any task. Do not mention this policy inside the plan files either.

Self-review check (add to the single pass below): grep every task file for
`commit` and `git`; any hit is a bug - delete the step.

## Constraints

- Lint and format after making any file changes
- Do NOT commit anything while planning - not the plan, not any other files

When done, print the resolved plan path and the task tree with one-line goals,
so I can see where it landed and the shape of the plan.