Menu
Decompose work into atomic, independently verifiable tasks
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | planning-and-task-breakdown |
| description | Decompose work into atomic, independently verifiable tasks |
| difficulty | senior |
| domains | ["general"] |
Good task breakdown is the difference between a project that ships incrementally and one that delivers a big-bang surprise at the deadline. Tasks must be atomic (one logical unit), verifiable (you can prove it's done), and independent (completable without blocking on other tasks).
A vertical slice delivers end-to-end value: from input to storage to output. Prefer slices over horizontal layers (don't plan "do all the models, then all the controllers, then all the views").
Good: "Add rate limiting to the /api/search endpoint (max 100 req/min per user)" Bad: "Rate limiting"
No task should take more than 2 days. If it does, break it down further. If it genuinely can't be broken down, flag it as a risk.
Each task must have a clear, observable "done" state: test passes, endpoint returns 200, UI renders without error, migration runs cleanly.
Draw or list which tasks must complete before others can start. Minimize dependencies — they are schedule risk.
The longest chain of dependent tasks sets the minimum delivery time. Optimize this chain first.
Add 20% time to estimates for unknowns. If you've never done something before, add 50%.
Put the riskiest tasks first. You want to discover impossible requirements on day 2, not day 20.
"These tasks are too small to track" If it's too small to track, it's too small to lose track of — which means it will be forgotten. Track it.
"I'll figure out the subtasks as I go" Figuring out subtasks during execution means context-switching between planning mode and execution mode. Do the planning upfront.
"The spec is clear enough — I don't need to break it down" A spec describes the destination. A task breakdown is the map. You need both.
