135 lines
5.0 KiB
Markdown
135 lines
5.0 KiB
Markdown
---
|
|
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
|