writing-plans
starsforks
How to install writing-plans?
heymegabyte/claude-skills/writing-plans
$npx -y skills add heymegabyte/claude-skills --skill writing-plansUse when you have a spec or requirements for a multi-step task, before touching code
SKILL.md
| 1 | # Writing Plans |
| 2 | |
| 3 | Write an implementation plan for an engineer with zero context for this codebase and questionable test taste. Decompose into bite-sized, independently verifiable tasks. DRY, YAGNI, TDD, frequent commits. |
| 4 | |
| 5 | Pairs with `/generate-prp` (research-driven blueprint) and `/writing-plans`. Save to `docs/superpowers/plans/YYYY-MM-DD-<feature>.md` (user preference overrides). Worktree, if isolated, comes from `using-git-worktrees` at execution time. |
| 6 | |
| 7 | Announce: "Using the writing-plans skill to create the implementation plan." |
| 8 | |
| 9 | ## Scope |
| 10 | |
| 11 | - One plan per independent subsystem — each must produce working, testable software alone. If the spec spans several, suggest splitting into separate plans. |
| 12 | |
| 13 | ## File structure (decide before tasks) |
| 14 | |
| 15 | - Map every file to create/modify and its single responsibility — this locks in decomposition. |
| 16 | - One responsibility per file; prefer small focused files; files that change together live together (split by responsibility, not layer). |
| 17 | - Follow established codebase patterns. Restructure a file only when it's grown unwieldy AND you're already modifying it. |
| 18 | |
| 19 | ## Task right-sizing |
| 20 | |
| 21 | - A task = the smallest unit that carries its own test cycle and is worth a fresh reviewer's gate. |
| 22 | - Fold setup/config/scaffolding/docs into the task whose deliverable needs them. Split only where a reviewer could reject one task while approving its neighbor. |
| 23 | - Each task ends with an independently testable deliverable. |
| 24 | |
| 25 | ## Step granularity |
| 26 | |
| 27 | Each step is one 2-5 min action: write failing test → run it (confirm RED) → minimal implementation → run (confirm GREEN) → commit. |
| 28 | |
| 29 | ## Plan document shape |
| 30 | |
| 31 | Header (required): |
| 32 | |
| 33 | ```markdown |
| 34 | # [Feature] Implementation Plan |
| 35 | |
| 36 | > **For agentic workers:** REQUIRED SUB-SKILL: superpowers:subagent-driven-development (recommended) or superpowers:executing-plans. Steps use `- [ ]` checkboxes. |
| 37 | |
| 38 | **Goal:** [one sentence] **Architecture:** [2-3 sentences] **Tech Stack:** [key libs] |
| 39 | |
| 40 | ## Global Constraints |
| 41 | [Project-wide spec requirements — version floors, dep limits, naming/copy rules, |
| 42 | platform — one line each, exact values verbatim. Every task implicitly includes this.] |
| 43 | ``` |
| 44 | |
| 45 | Per task: |
| 46 | |
| 47 | - **Files** — exact `Create:` / `Modify:path:lines` / `Test:` paths. |
| 48 | - **Interfaces** — `Consumes:` exact signatures from earlier tasks; `Produces:` exact names + param/return types later tasks rely on (implementers see only their own task). |
| 49 | - **Steps** — checkbox per step, with the ACTUAL test code, exact run command + expected output, the ACTUAL implementation code, and the commit. |
| 50 | |
| 51 | ## No placeholders (these are plan failures) |
| 52 | |
| 53 | - "TBD"/"TODO"/"implement later"/"fill in details". |
| 54 | - "Add appropriate error handling / validation / edge cases". |
| 55 | - "Write tests for the above" without the test code; "similar to Task N" without repeating the code (tasks may be read out of order). |
| 56 | - Steps describing what without showing how (code steps need code blocks). |
| 57 | - References to types/functions/methods not defined in any task. |
| 58 | |
| 59 | ## Self-review (yourself, not a subagent) |
| 60 | |
| 61 | 1. **Spec coverage** — every spec requirement maps to a task; list + fill gaps. |
| 62 | 2. **Placeholder scan** — hunt the patterns above; fix inline. |
| 63 | 3. **Type consistency** — names/signatures in later tasks match earlier definitions (`clearLayers()` in T3 vs `clearFullLayers()` in T7 is a bug). |
| 64 | |
| 65 | For a fresh-eyes pass, dispatch `plan-document-reviewer-prompt.md`. |
| 66 | |
| 67 | ## Execution handoff |
| 68 | |
| 69 | Offer: **(1) Subagent-driven** (recommended) — `superpowers:subagent-driven-development`, fresh subagent per task + two-stage review; **(2) Inline** — `superpowers:executing-plans`, batch execution with checkpoints. |
| 70 | |
| 71 | <!-- budget: ~74 --> |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
