Project Plan Writer

Plan writing

by davila7 · MIT license · ★ 32,299 on GitHub

Plan writing cover

Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.

---
name: plan-writing
description: Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
allowed-tools: Read, Glob, Grep
---

# Plan Writing

> Source: obra/superpowers

## Overview
This skill provides a framework for breaking down work into clear, actionable tasks with verification criteria.

## Task Breakdown Principles

### 1. Small, Focused Tasks
- Each task should take 2-5 minutes
- One clear outcome per task

Overview

For NEW PROJECT: - What tech stack? (decide first) - What's the MVP? (minimal features) - What's the file structure?

Manual install (npx, ZIP)
Claude Codenpx skills add davila7/claude-code-templates --skill plan-writing -g -a claude-code
Claude Code (degit)npx degit davila7/claude-code-templates/cli-tool/components/skills/productivity/plan-writing#main ~/.claude/skills/plan-writing
Claude.ai / desktopZip the folder and upload it under Settings → Capabilities → Skills.
Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

  • SKILL.md3.9 KB
Read SKILL.md here
davila7/main1 file shown
SKILL.md
Show the full text153 lines

Plan Writing

Source: obra/superpowers

Overview

This skill provides a framework for breaking down work into clear, actionable tasks with verification criteria.

Task Breakdown Principles

1. Small, Focused Tasks
  • Each task should take 2-5 minutes
  • One clear outcome per task
  • Independently verifiable
2. Clear Verification
  • How do you know it's done?
  • What can you check/test?
  • What's the expected output?
3. Logical Ordering
  • Dependencies identified
  • Parallel work where possible
  • Critical path highlighted
  • Phase X: Verification is always LAST
4. Dynamic Naming in Project Root
  • Plan files are saved as {task-slug}.md in the PROJECT ROOT
  • Name derived from task (e.g., "add auth" → auth-feature.md)
  • NEVER inside .claude/, docs/, or temp folders

Planning Principles (NOT Templates!)

🔴 NO fixed templates. Each plan is UNIQUE to the task.

Principle 1: Keep It SHORT
❌ Wrong ✅ Right
50 tasks with sub-sub-tasks 5-10 clear tasks max
Every micro-step listed Only actionable items
Verbose descriptions One-line per task

Rule: If plan is longer than 1 page, it's too long. Simplify.


Principle 2: Be SPECIFIC, Not Generic
❌ Wrong ✅ Right
"Set up project" "Run npx create-next-app"
"Add authentication" "Install next-auth, create /api/auth/[...nextauth].ts"
"Style the UI" "Add Tailwind classes to Header.tsx"

Rule: Each task should have a clear, verifiable outcome.


Principle 3: Dynamic Content Based on Project Type

For NEW PROJECT:

  • What tech stack? (decide first)
  • What's the MVP? (minimal features)
  • What's the file structure?

For FEATURE ADDITION:

  • Which files are affected?
  • What dependencies needed?
  • How to verify it works?

For BUG FIX:

  • What's the root cause?
  • What file/line to change?
  • How to test the fix?

Principle 4: Scripts Are Project-Specific

🔴 DO NOT copy-paste script commands. Choose based on project type.

Project Type Relevant Scripts
Frontend/React ux_audit.py, accessibility_checker.py
Backend/API api_validator.py, security_scan.py
Mobile mobile_audit.py
Database schema_validator.py
Full-stack Mix of above based on what you touched

Wrong: Adding all scripts to every plan Right: Only scripts relevant to THIS task


Principle 5: Verification is Simple
❌ Wrong ✅ Right
"Verify the component works correctly" "Run npm run dev, click button, see toast"
"Test the API" "curl localhost:3000/api/users returns 200"
"Check styles" "Open browser, verify dark mode toggle works"

Plan Structure (Flexible, Not Fixed!)

# [Task Name]

## Goal
One sentence: What are we building/fixing?

## Tasks
- [ ] Task 1: [Specific action] → Verify: [How to check]
- [ ] Task 2: [Specific action] → Verify: [How to check]
- [ ] Task 3: [Specific action] → Verify: [How to check]

## Done When
- [ ] [Main success criteria]

That's it. No phases, no sub-sections unless truly needed. Keep it minimal. Add complexity only when required.

Notes

[Any important considerations]


---

## Best Practices (Quick Reference)

1. **Start with goal** - What are we building/fixing?
2. **Max 10 tasks** - If more, break into multiple plans
3. **Each task verifiable** - Clear "done" criteria
4. **Project-specific** - No copy-paste templates
5. **Update as you go** - Mark `[x]` when complete

---

## When to Use

- New project from scratch
- Adding a feature
- Fixing a bug (if complex)
- Refactoring multiple files
1---
2name: plan-writing
3description: Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
4allowed-tools: Read, Glob, Grep
5---
6 
7# Plan Writing
8 
9> Source: obra/superpowers
10 
11## Overview
12This skill provides a framework for breaking down work into clear, actionable tasks with verification criteria.
13 
14## Task Breakdown Principles
15 
16### 1. Small, Focused Tasks
17- Each task should take 2-5 minutes
18- One clear outcome per task
19- Independently verifiable
20 
21### 2. Clear Verification
22- How do you know it's done?
23- What can you check/test?
24- What's the expected output?
25 
26### 3. Logical Ordering
27- Dependencies identified
28- Parallel work where possible
29- Critical path highlighted
30- **Phase X: Verification is always LAST**
31 
32### 4. Dynamic Naming in Project Root
33- Plan files are saved as `{task-slug}.md` in the PROJECT ROOT
34- Name derived from task (e.g., "add auth" → `auth-feature.md`)
35- **NEVER** inside `.claude/`, `docs/`, or temp folders
36 
37## Planning Principles (NOT Templates!)
38 
39> 🔴 **NO fixed templates. Each plan is UNIQUE to the task.**
40 
41### Principle 1: Keep It SHORT
42 
43| ❌ Wrong | ✅ Right |
44|----------|----------|
45| 50 tasks with sub-sub-tasks | 5-10 clear tasks max |
46| Every micro-step listed | Only actionable items |
47| Verbose descriptions | One-line per task |
48 
49> **Rule:** If plan is longer than 1 page, it's too long. Simplify.
50 
51---
52 
53### Principle 2: Be SPECIFIC, Not Generic
54 
55| ❌ Wrong | ✅ Right |
56|----------|----------|
57| "Set up project" | "Run `npx create-next-app`" |
58| "Add authentication" | "Install next-auth, create `/api/auth/[...nextauth].ts`" |
59| "Style the UI" | "Add Tailwind classes to `Header.tsx`" |
60 
61> **Rule:** Each task should have a clear, verifiable outcome.
62 
63---
64 
65### Principle 3: Dynamic Content Based on Project Type
66 
67**For NEW PROJECT:**
68- What tech stack? (decide first)
69- What's the MVP? (minimal features)
70- What's the file structure?
71 
72**For FEATURE ADDITION:**
73- Which files are affected?
74- What dependencies needed?
75- How to verify it works?
76 
77**For BUG FIX:**
78- What's the root cause?
79- What file/line to change?
80- How to test the fix?
81 
82---
83 
84### Principle 4: Scripts Are Project-Specific
85 
86> 🔴 **DO NOT copy-paste script commands. Choose based on project type.**
87 
88| Project Type | Relevant Scripts |
89|--------------|------------------|
90| Frontend/React | `ux_audit.py`, `accessibility_checker.py` |
91| Backend/API | `api_validator.py`, `security_scan.py` |
92| Mobile | `mobile_audit.py` |
93| Database | `schema_validator.py` |
94| Full-stack | Mix of above based on what you touched |
95 
96**Wrong:** Adding all scripts to every plan
97**Right:** Only scripts relevant to THIS task
98 
99---
100 
101### Principle 5: Verification is Simple
102 
103| ❌ Wrong | ✅ Right |
104|----------|----------|
105| "Verify the component works correctly" | "Run `npm run dev`, click button, see toast" |
106| "Test the API" | "curl localhost:3000/api/users returns 200" |
107| "Check styles" | "Open browser, verify dark mode toggle works" |
108 
109---
110 
111## Plan Structure (Flexible, Not Fixed!)
112 
113```
114# [Task Name]
115 
116## Goal
117One sentence: What are we building/fixing?
118 
119## Tasks
120- [ ] Task 1: [Specific action] → Verify: [How to check]
121- [ ] Task 2: [Specific action] → Verify: [How to check]
122- [ ] Task 3: [Specific action] → Verify: [How to check]
123 
124## Done When
125- [ ] [Main success criteria]
126```
127 
128> **That's it.** No phases, no sub-sections unless truly needed.
129> Keep it minimal. Add complexity only when required.
130 
131## Notes
132[Any important considerations]
133```
134 
135---
136 
137## Best Practices (Quick Reference)
138 
1391. **Start with goal** - What are we building/fixing?
1402. **Max 10 tasks** - If more, break into multiple plans
1413. **Each task verifiable** - Clear "done" criteria
1424. **Project-specific** - No copy-paste templates
1435. **Update as you go** - Mark `[x]` when complete
144 
145---
146 
147## When to Use
148 
149- New project from scratch
150- Adding a feature
151- Fixing a bug (if complex)
152- Refactoring multiple files
153 
View all files on GitHub →

Details

License
MIT
Stars on the repo
★ 32,299
Checked
Source
davila7/claude-code-templates ↗
Creator
davila7 · 212 listings
View creator

Similar skills

See all →

More from davila7

Skill2D Game Developmentdavila7/claude-code-templates · by davila72D game development principles. Sprites, tilemaps, physics, camera.★ 32.3k GitHub starsSkill3D Game Development Principlesdavila7/claude-code-templates · by davila73D game development principles. Rendering, shaders, physics, cameras.★ 32.3k GitHub starsSkill3D Web Experience Builderdavila7/claude-code-templates · by davila7Expert in building 3D experiences for the web - Three.js, React Three Fiber, Spline, WebGL, and interactive 3D scenes. Covers product configurators, 3D portfolios, immersive websites, and bringing depth to web experiences. Use when: 3D website, three.js, WebGL, react three fiber, 3D experience.★ 32.3k GitHub starsSkillSplit Test Setupdavila7/claude-code-templates · by davila7When the user wants to plan, design, or implement an A/B test or experiment. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," or "hypothesis." For tracking implementation, see analytics-tracking.★ 32.3k GitHub starsAgentResearch Literature Synthesizerdavila7/claude-code-templates · by davila7Academic research synthesis specialist. Use PROACTIVELY for comprehensive research on academic topics, literature reviews, technical investigations, and well-cited analysis combining multiple sources. <example>Context: A podcast episode needs a segment grounded in peer-reviewed evidence with formal citations. user: "Research the current state of transformer efficiency techniques for the episode, with proper academic citations." assistant: "I'll use the academic-research-synthesizer agent to search arXiv and Semantic Scholar, extract full-text findings via WebFetch, and produce a cited literature synthesis with confidence levels." <commentary>Use academic-research-synthesizer (not comprehensive-researcher) when the episode segment needs peer-reviewed sourcing, formal citation format, and explicit confidence tagging rather than general-purpose multi-source coverage.</commentary></example> <example>Context: The episode-orchestrator has routed a "literature review" request for a technical deep-dive segment. user: "Summarize the research landscape on federated learning privacy guarantees." assistant: "I'll invoke academic-research-synthesizer to systematically search academic sources, note peer-review status per source, and synthesize consensus vs. open debates."</example>★ 32.3k GitHub starsAgentAcademic Research Specialistdavila7/claude-code-templates · by davila7Academic research specialist for scholarly sources, peer-reviewed papers, and academic literature. Use PROACTIVELY for research paper analysis, literature reviews, citation tracking, and academic methodology evaluation. <example>Context: The research-orchestrator has kicked off Phase 4 parallel research on 'efficacy of intermittent fasting' and needs peer-reviewed evidence. user: "Find the academic evidence on intermittent fasting outcomes." assistant: "I'll use the academic-researcher agent to search Semantic Scholar, PubMed, and OpenAlex for peer-reviewed studies and write structured findings to academic-research.md." <commentary>The request is specifically for scholarly/peer-reviewed evidence rather than general web coverage or code, so academic-researcher (not web-researcher or technical-researcher) is the right specialist.</commentary></example> <example>Context: The user wants a literature review comparing methodologies across studies on a topic. user: "Can you review the literature on transformer model interpretability and identify research gaps?" assistant: "Let me invoke the academic-researcher agent to pull foundational and recent papers, extract methodologies, and surface open research gaps." <commentary>Literature review, methodology extraction, and research-gap identification are core academic-researcher capabilities, distinct from technical-researcher's focus on code repositories and implementations.</commentary></example>★ 32.3k GitHub stars