Task Breakdown
Purpose
Decompose a project, feature, or initiative into actionable, well-defined tasks. Produce a structured checklist that a team can immediately pick up and work from, with clear priorities, effort estimates, and dependencies.
When to Use
- Breaking down a feature or project into sprint-ready work items
- Creating a personal task list from a broad goal
- Estimating effort and identifying the critical path for a body of work
Inputs
- Work description: The feature, project, or goal to decompose
- Scope constraints: Any boundaries on what to include or exclude (optional)
- Team context: Team size, roles, skill sets (optional)
- Timeline: Target completion date or sprint length (optional)
Output Format
Produce a markdown document with the following structure:
1. Objective
One sentence stating what "done" looks like for this body of work.
2. Task List
For each task, use this checklist format:
- [ ] **Task title**
- Description: What needs to be done (1-2 sentences)
- Priority: P0 / P1 / P2
- Effort: S (< 2h) / M (2-8h) / L (1-3d) / XL (3-5d)
- Dependencies: List any tasks that must complete first
- Acceptance criteria: How to verify this task is done
Group tasks into logical phases or categories using H3 headers.
3. Dependency Graph
A text summary of the critical path: which tasks block others and what can be parallelized.
4. Effort Summary
A quick table:
| Priority |
Count |
Total Effort |
| P0 |
|
|
| P1 |
|
|
| P2 |
|
|
5. Risks and Blockers
List anything that could delay or prevent completion.
Example
Input: "Break down the work to add dark mode to our web app."
Output:
- Objective: Users can toggle between light and dark themes across all pages.
- Tasks grouped into phases:
- Design: Audit existing color tokens, define dark palette, update design system
- Infrastructure: Implement theme provider, add user preference storage, set up CSS variable system
- Implementation: Update core components, update page layouts, handle third-party widget theming
- Testing: Visual regression tests, accessibility contrast checks, cross-browser testing
- Rollout: Feature flag setup, beta rollout, documentation update
- Dependency graph showing design must precede implementation, infrastructure can parallel with design
- Effort summary showing total estimated work
Guidelines
- Make each task small enough to complete in one sitting (aim for S or M when possible)
- Every task should have a clear "done" state -- no vague tasks like "work on styling"
- Order tasks within each phase by dependency, then priority
- Flag tasks that require specific expertise or access
- Include testing and documentation tasks -- they are real work
- If a task is XL, consider whether it should be broken down further
1---2name: todo3description: Break down a project into actionable tasks. Use when the user says /todo, asks to create a task breakdown, decompose a feature into tasks, or plan work items. Triggers: todo, task breakdown, break down, decompose, work items, sprint planning, task list.4---56# Task Breakdown78## Purpose910Decompose a project, feature, or initiative into actionable, well-defined tasks. Produce a structured checklist that a team can immediately pick up and work from, with clear priorities, effort estimates, and dependencies.1112## When to Use1314- Breaking down a feature or project into sprint-ready work items15- Creating a personal task list from a broad goal16- Estimating effort and identifying the critical path for a body of work1718## Inputs1920- **Work description**: The feature, project, or goal to decompose21- **Scope constraints**: Any boundaries on what to include or exclude (optional)22- **Team context**: Team size, roles, skill sets (optional)23- **Timeline**: Target completion date or sprint length (optional)2425## Output Format2627Produce a markdown document with the following structure:2829### 1. Objective30One sentence stating what "done" looks like for this body of work.3132### 2. Task List3334For each task, use this checklist format:3536```37- [ ] **Task title**38 - Description: What needs to be done (1-2 sentences)39 - Priority: P0 / P1 / P240 - Effort: S (< 2h) / M (2-8h) / L (1-3d) / XL (3-5d)41 - Dependencies: List any tasks that must complete first42 - Acceptance criteria: How to verify this task is done43```4445Group tasks into logical phases or categories using H3 headers.4647### 3. Dependency Graph48A text summary of the critical path: which tasks block others and what can be parallelized.4950### 4. Effort Summary51A quick table:5253| Priority | Count | Total Effort |54|----------|-------|--------------|55| P0 | | |56| P1 | | |57| P2 | | |5859### 5. Risks and Blockers60List anything that could delay or prevent completion.6162## Example6364**Input**: "Break down the work to add dark mode to our web app."6566**Output**:67- Objective: Users can toggle between light and dark themes across all pages.68- Tasks grouped into phases:69 - **Design**: Audit existing color tokens, define dark palette, update design system70 - **Infrastructure**: Implement theme provider, add user preference storage, set up CSS variable system71 - **Implementation**: Update core components, update page layouts, handle third-party widget theming72 - **Testing**: Visual regression tests, accessibility contrast checks, cross-browser testing73 - **Rollout**: Feature flag setup, beta rollout, documentation update74- Dependency graph showing design must precede implementation, infrastructure can parallel with design75- Effort summary showing total estimated work7677## Guidelines7879- Make each task small enough to complete in one sitting (aim for S or M when possible)80- Every task should have a clear "done" state -- no vague tasks like "work on styling"81- Order tasks within each phase by dependency, then priority82- Flag tasks that require specific expertise or access83- Include testing and documentation tasks -- they are real work84- If a task is XL, consider whether it should be broken down further
maggit