plan-writing

Name: plan-writing
Author: One-Man-Company

77stars16forks

How to install plan-writing?

one-man-company/skills-contextmanager/plan-writing

$npx -y skills add One-Man-Company/Skills-ContextManager --skill plan-writing

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type

plan-writing

77stars16forks

View on GitHub

How to install plan-writing?

one-man-company/skills-contextmanager/plan-writing

$npx -y skills add One-Man-Company/Skills-ContextManager --skill plan-writing

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type