planning-and-task-breakdown

Name: planning-and-task-breakdown
Author: addyosmani

byaddyosmani· 31 skills

Installs

17k

Stars

80k

Forks

8.7k

How to install planning-and-task-breakdown?

addyosmani/agent-skills/planning-and-task-breakdown

$npx -y skills add addyosmani/agent-skills --skill planning-and-task-breakdown

Installs into the current project.

›Prefer a prompt? Paste this to your agent

Use this skill

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/planning-and-task-breakdown"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the whole pack

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

Files · 1

View on GitHub

SKILL.md

1	# Planning and Task Breakdown
2
3	## Overview
4
5	Decompose work into small, verifiable tasks with explicit acceptance criteria. Good task breakdown is the difference between an agent that completes work reliably and one that produces a tangled mess. Every task should be small enough to implement, test, and verify in a single focused session.
6
7	## When to Use
8
9	- You have a spec and need to break it into implementable units
10	- A task feels too large or vague to start
11	- Work needs to be parallelized across multiple agents or sessions
12	- You need to communicate scope to a human
13	- The implementation order isn't obvious
14
15	When NOT to use: Single-file changes with obvious scope, or when the spec already contains well-defined tasks.
16
17	## The Planning Process
18
19	### Step 1: Enter Plan Mode
20
21	Before writing any code, operate in read-only mode:
22
23	- Read the spec and relevant codebase sections
24	- Identify existing patterns and conventions
25	- Map dependencies between components
26	- Note risks and unknowns
27
28	Do NOT write code during planning. The output is a plan document saved to `tasks/plan.md` and a task list saved to `tasks/todo.md`, not implementation.
29
30	### Step 2: Identify the Dependency Graph
31
32	Map what depends on what:
33
34	```
35	Database schema
36	│
37	├── API models/types
38	│ │
39	│ ├── API endpoints
40	│ │ │
41	│ │ └── Frontend API client
42	│ │ │
43	│ │ └── UI components
44	│ │
45	│ └── Validation logic
46	│
47	└── Seed data / migrations
48	```
49
50	Implementation order follows the dependency graph bottom-up: build foundations first.
51
52	### Step 3: Slice Vertically
53
54	Instead of building all the database, then all the API, then all the UI — build one complete feature path at a time:
55
56	Bad (horizontal slicing):
57	```
58	Task 1: Build entire database schema
59	Task 2: Build all API endpoints
60	Task 3: Build all UI components
61	Task 4: Connect everything
62	```
63
64	Good (vertical slicing):
65	```
66	Task 1: User can create an account (schema + API + UI for registration)
67	Task 2: User can log in (auth schema + API + UI for login)
68	Task 3: User can create a task (task schema + API + UI for creation)
69	Task 4: User can view task list (query + API + UI for list view)
70	```
71
72	Each vertical slice delivers working, testable functionality.
73
74	### Step 4: Write Tasks
75
76	Each task follows this structure:
77
78	```markdown
79	## Task [N]: [Short descriptive title]
80
81	Description: One paragraph explaining what this task accomplishes.
82
83	Acceptance criteria:
84	- [ ] [Specific, testable condition]
85	- [ ] [Specific, testable condition]
86
87	Verification:
88	- [ ] Tests pass: [the repository's focused-test command]
89	- [ ] Build succeeds: [the repository's build command]
90	- [ ] Manual check: [description of what to verify]
91
92	Dependencies: [Task numbers this depends on, or "None"]
93
94	Files likely touched:
95	- `src/path/to/file.ts`
96	- `tests/path/to/test.ts`
97
98	Estimated scope: [Small: 1-2 files \| Medium: 3-5 files \| Large: 5+ files]
99	```
100
101	### Step 5: Order and Checkpoint
102
103	Arrange tasks so that:
104
105	1. Dependencies are satisfied (build foundation first)
106	2. Each task leaves the system in a working state
107	3. Verification checkpoints occur after every 2-3 tasks
108	4. High-risk tasks are early (fail fast)
109
110	Add explicit checkpoints:
111
112	```markdown
113	## Checkpoint: After Tasks 1-3
114	- [ ] All tests pass
115	- [ ] Application builds without errors
116	- [ ] Core user flow works end-to-end
117	- [ ] Review with human before proceeding
118	```
119
120	## Task Sizing Guidelines
121
122	\| Size \| Files \| Scope \| Example \|
123	\|------\|-------\|-------\|---------\|
124	\| XS \| 1 \| Single function or config change \| Add a validation rule \|
125	\| S \| 1-2 \| One component or endpoint \| Add a new API endpoint \|
126	\| M \| 3-5 \| One feature slice \| User registration flow \|
127	\| L \| 5-8 \| Multi-component feature \| Search with filtering and pagination \|
128	\| XL \| 8+ \| Too large — break it down further \| — \|
129
130	If a task is L or larger, it should be broken into smaller tasks. An agent performs best on S and M tasks.
131
132	When to break a task down further:
133	- It would take more than one focused session (roughly 2+ hours of agent work)
134	- You cannot describe the acceptance criteria in 3 or fewer bullet points
135	- It touches two or more independent subsystems (e.g., auth and billing)
136	- You find yourself writing "and" in the task title (a sign it is two tasks)
137
138	## Output Files
139
140	- Plan document: Save the implementation plan to `tasks/plan.md`.
141	- Task list: Save the checklist-style task list to `tasks/todo.md`.
142
143	Create the `tasks/` directory if it does not exist. These paths are the convention expected by the `/build` command and other downstream tooling.
144
145	## Plan Document Template
146
147	```markdown
148	# Implementation Plan: [Feature/Project Name]
149
150	## Overview
151	[One paragraph summary of what we're building]
152
153	## Architecture Decisions
154	- [Key decision 1 and rationale]
155	- [Key decision 2 and rationale]
156
157	## Task List
158
159	### Phase 1: Foundation
160	- [ ] Task 1: ...
161	- [ ] Task 2: ...
162
163	### Checkpoint: Foundation
164	- [ ] Tests pass, builds clean
165
166	### Phase 2: Core Features
167	- [ ] Task 3: ...
168	- [ ] Task 4: ...
169
170	### Checkpoint: Core Features
171	- [ ] End-to-end flow works
172
173	### Phase 3: Polish
174	- [ ] Task 5: ...
175	- [ ] Task 6: ...
176
177	### Checkpoint: Complete
178	- [ ] All acceptance criteria met
179	- [ ] Ready for review
180
181	## Risks and Mitigations
182	\| Risk \| Impact \| Mitigation \|
183	\|------\|--------\|------------\|
184	\| [Risk] \| [High/Med/Low] \| [Strategy] \|
185
186	## Open Questions
187	- [Question needing human input]
188	```
189
190	## Parallelization Opportunities
191
192	When multiple agents or sessions are available:
193
194	- Safe to parallelize: Independent feature slices, tests for already-implemented features, documentation
195	- Must be sequential: Database migrations, shared state changes, dependency chains
196	- Needs coordination: Features that share an API contract (define the contract first, then parallelize)
197
198	## Common Rationalizations
199
200	\| Rationalization \| Reality \|
201	\|---\|---\|
202	\| "I'll figure it out as I go" \| That's how you end up with a tangled mess and rework. 10 minutes of planning saves hours. \|
203	\| "The tasks are obvious" \| Write them down anyway. Explicit tasks surface hidden dependencies and forgotten edge cases. \|
204	\| "Planning is overhead" \| Planning is the task. Implementation without a plan is just typing. \|
205	\| "I can hold it all in my head" \| Context windows are finite. Written plans survive session boundaries and compaction. \|
206
207	## Red Flags
208
209	- Starting implementation without a written task list
210	- Tasks that say "implement the feature" without acceptance criteria
211	- No verification steps in the plan
212	- All tasks are XL-sized
213	- No checkpoints between tasks
214	- Dependency order isn't considered
215
216	## Verification
217
218	Before starting implementation, confirm:
219
220	- [ ] Every task has acceptance criteria
221	- [ ] Every task has a verification step
222	- [ ] Task dependencies are identified and ordered correctly
223	- [ ] No task touches more than ~5 files
224	- [ ] Checkpoints exist between major phases
225	- [ ] The human has reviewed and approved the plan
226
227	## See Also
228
229	Acceptance criteria are per-task and answer "did we build the right thing?". They sit on top of the project-wide Definition of Done, the standing bar every task clears before it counts as done. See `references/definition-of-done.md`.

6 picks

Type

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/planning-and-task-breakdown"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

planning-and-task-breakdown

How to install planning-and-task-breakdown?

Related

planning-and-task-breakdown

How to install planning-and-task-breakdown?

Related