---
name: writing-plans
description: 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:**

```markdown
# [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

```markdown
### 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**
```javascript
// implementation code
```

- [ ] **Step 4: Run test to verify it passes**
Run: `npm test -- path/to/test.test.js`
Expected: PASS

- [ ] **Step 5: Commit**
```bash
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