# Todo

> 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.

- Skill: `maggit/todo` (Agent Skill)
- Install (CLI): `npx skillmds@latest add maggit/todo`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maggit/todo/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: maggit (https://skillmd.com/u/maggit)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/maggit/todo

---


# 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