supersam/docs/superpowers/skills/writing-plans/SKILL.md

name	description
writing-plans	Use when you have a spec or requirements for a multi-step task, before touching code

Writing Plans

Overview

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. TDD. Frequent commits.

Assume they are a skilled developer, but know almost nothing about our toolset or problem domain.

Announce at start: "I'm using the writing-plans skill to create the implementation plan." Context: This should be run in a dedicated worktree (created by brainstorming skill). Save plans to: docs/superpowers/plans/YYYY-MM-DD--feature-name.md

Scope Check

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.

File Structure

Before defining tasks, map out which files will be created or modified and what each one is responsible for.

• Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.
• Files that change together should live together. Split by responsibility, not by technical layer.
• In this codebase, follow established patterns:
  • Components by domain: src/components/orders/, src/components/dashboard/, etc.
  • Services in src/services/ with pure functions, tests in same directory as .test.js
  • Supabase adapters in src/services/supabase/
  • Context providers in src/context/
  • Constants in src/constants/
  • Hooks in src/hooks/

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 pass" — step
• "Run the tests and make sure they pass" — step
• "Commit" — step

Plan Document Header

Every plan MUST start with this header:

# [Feature Name] Implementation Plan

> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.

**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.jsx`
- Modify: `exact/path/to/existing.jsx:123-145`
- Test: `exact/path/to/file.test.js`

- [ ] **Step 1: Write the failing test**
```javascript
test('specific behavior', () => {
  // test code
});

• Step 2: Run test to verify it fails Run: npm test -- path/to/test.test.js Expected: FAIL with "function not defined"

• Step 3: Write minimal implementation

// implementation code

• Step 4: Run test to verify it passes Run: npm test -- path/to/test.test.js Expected: PASS

• Step 5: Commit

git add path/to/file.jsx path/to/file.test.js
git commit -m "feat: add specific feature"

## No Placeholders
Every step must contain the actual content an engineer needs. These are **plan failures** — never write them:
- "TBD", "TODO", "implement later", "fill in details"
- "Add appropriate error handling" / "add validation" / "handle edge cases"
- "Write tests for the above" (without actual test code)
- "Similar to Task N" (repeat the code)
- Steps that describe what to do without showing how (code blocks required for code steps)
- References to types, functions, or methods not defined in any task

## Remember
- Exact file paths always
- Complete code in every step — if a step changes code, show the code
- Exact commands with expected output
- DRY, YAGNI, TDD, frequent commits

## Self-Review
After writing the complete plan, look at the spec with fresh eyes and check the plan against it.

**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.
**2. Placeholder scan:** Search your plan for red flags. Fix them.
**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? Fix any issues inline.

## Execution Handoff
After saving the plan, offer execution choice:

**"Plan complete and saved to `docs/superpowers/plans/[name].md`. Two execution options:**

**1. Subagent-Driven (recommended)**
- I dispatch a fresh subagent per task, review between tasks, fast iteration

**2. Inline Execution**
- Execute tasks in this session, batch execution with checkpoints

Which approach?"

**If Subagent-Driven chosen:**
- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development

**If Inline Execution chosen:**
- **REQUIRED SUB-SKILL:** Use superpowers:executing-plans