planning-and-task-breakdown

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

32stars3forks

How to install planning-and-task-breakdown?

jmxt3/gitscape.ai/planning-and-task-breakdown

$npx -y skills add jmxt3/gitscape.ai --skill planning-and-task-breakdown

Installs into the current project.

Summary

Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.

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, 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 export a skill (skill schema + API + UI for export)
69	```
70
71	Each vertical slice delivers working, testable functionality.
72
73	### Step 4: Write Tasks
74
75	Each task follows this structure:
76
77	```markdown
78	## Task [N]: [Short descriptive title]
79
80	Description: One paragraph explaining what this task accomplishes.
81
82	Acceptance criteria:
83	- [ ] [Specific, testable condition]
84	- [ ] [Specific, testable condition]
85
86	Verification:
87	- [ ] Tests pass: `pytest tests/ -k "test_name"`
88	- [ ] Build succeeds
89	- [ ] Manual check: [description of what to verify]
90
91	Dependencies: [Task numbers this depends on, or "None"]
92
93	Files likely touched:
94	- `api/app/path/to/file.py`
95	- `web/components/path/to/component.tsx`
96
97	Estimated scope: [Small: 1-2 files \| Medium: 3-5 files \| Large: 5+ files]
98	```
99
100	### Step 5: Order and Checkpoint
101
102	Arrange tasks so that:
103
104	1. Dependencies are satisfied (build foundation first)
105	2. Each task leaves the system in a working state
106	3. Verification checkpoints occur after every 2-3 tasks
107	4. High-risk tasks are early (fail fast)
108
109	Add explicit checkpoints:
110
111	```markdown
112	## Checkpoint: After Tasks 1-3
113	- [ ] All tests pass
114	- [ ] Application builds without errors
115	- [ ] Core user flow works end-to-end
116	- [ ] Review with human before proceeding
117	```
118
119	## Task Sizing Guidelines
120
121	\| Size \| Files \| Scope \| Example \|
122	\|------\|-------\|-------\|---------\|
123	\| XS \| 1 \| Single function or config change \| Add a validation rule \|
124	\| S \| 1-2 \| One component or endpoint \| Add a new API endpoint \|
125	\| M \| 3-5 \| One feature slice \| Skill export flow \|
126	\| L \| 5-8 \| Multi-component feature \| Search with filtering and pagination \|
127	\| XL \| 8+ \| Too large — break it down further \| — \|
128
129	If a task is L or larger, break it into smaller tasks. An agent performs best on S and M tasks.
130
131	When to break a task down further:
132	- It would take more than one focused session
133	- You cannot describe the acceptance criteria in 3 or fewer bullet points
134	- It touches two or more independent subsystems
135	- You find yourself writing "and" in the task title
136
137	## Common Rationalizations
138
139	\| Rationalization \| Reality \|
140	\|---\|---\|
141	\| "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. \|
142	\| "The tasks are obvious" \| Write them down anyway. Explicit tasks surface hidden dependencies and forgotten edge cases. \|
143	\| "Planning is overhead" \| Planning is the task. Implementation without a plan is just typing. \|
144	\| "I can hold it all in my head" \| Context windows are finite. Written plans survive session boundaries. \|
145
146	## Red Flags
147
148	- Starting implementation without a written task

People who liked this also viewed

6 picks

Type

planning-and-task-breakdown

32stars3forks

View on GitHub

How to install planning-and-task-breakdown?

jmxt3/gitscape.ai/planning-and-task-breakdown

$npx -y skills add jmxt3/gitscape.ai --skill planning-and-task-breakdown

Installs into the current project.

Summary

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, 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 export a skill (skill schema + API + UI for export)
69	```
70
71	Each vertical slice delivers working, testable functionality.
72
73	### Step 4: Write Tasks
74
75	Each task follows this structure:
76
77	```markdown
78	## Task [N]: [Short descriptive title]
79
80	Description: One paragraph explaining what this task accomplishes.
81
82	Acceptance criteria:
83	- [ ] [Specific, testable condition]
84	- [ ] [Specific, testable condition]
85
86	Verification:
87	- [ ] Tests pass: `pytest tests/ -k "test_name"`
88	- [ ] Build succeeds
89	- [ ] Manual check: [description of what to verify]
90
91	Dependencies: [Task numbers this depends on, or "None"]
92
93	Files likely touched:
94	- `api/app/path/to/file.py`
95	- `web/components/path/to/component.tsx`
96
97	Estimated scope: [Small: 1-2 files \| Medium: 3-5 files \| Large: 5+ files]
98	```
99
100	### Step 5: Order and Checkpoint
101
102	Arrange tasks so that:
103
104	1. Dependencies are satisfied (build foundation first)
105	2. Each task leaves the system in a working state
106	3. Verification checkpoints occur after every 2-3 tasks
107	4. High-risk tasks are early (fail fast)
108
109	Add explicit checkpoints:
110
111	```markdown
112	## Checkpoint: After Tasks 1-3
113	- [ ] All tests pass
114	- [ ] Application builds without errors
115	- [ ] Core user flow works end-to-end
116	- [ ] Review with human before proceeding
117	```
118
119	## Task Sizing Guidelines
120
121	\| Size \| Files \| Scope \| Example \|
122	\|------\|-------\|-------\|---------\|
123	\| XS \| 1 \| Single function or config change \| Add a validation rule \|
124	\| S \| 1-2 \| One component or endpoint \| Add a new API endpoint \|
125	\| M \| 3-5 \| One feature slice \| Skill export flow \|
126	\| L \| 5-8 \| Multi-component feature \| Search with filtering and pagination \|
127	\| XL \| 8+ \| Too large — break it down further \| — \|
128
129	If a task is L or larger, break it into smaller tasks. An agent performs best on S and M tasks.
130
131	When to break a task down further:
132	- It would take more than one focused session
133	- You cannot describe the acceptance criteria in 3 or fewer bullet points
134	- It touches two or more independent subsystems
135	- You find yourself writing "and" in the task title
136
137	## Common Rationalizations
138
139	\| Rationalization \| Reality \|
140	\|---\|---\|
141	\| "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. \|
142	\| "The tasks are obvious" \| Write them down anyway. Explicit tasks surface hidden dependencies and forgotten edge cases. \|
143	\| "Planning is overhead" \| Planning is the task. Implementation without a plan is just typing. \|
144	\| "I can hold it all in my head" \| Context windows are finite. Written plans survive session boundaries. \|
145
146	## Red Flags
147
148	- Starting implementation without a written task

People who liked this also viewed

6 picks

Type