task-breakdown

name	task-breakdown
description	Break requirements or design ideas into implementable work items. Use it when you need execution order, prerequisites, parallelism, and completion criteria.

Task Breakdown

Purpose

Break a large or ambiguous task into executable units and define the recommended order.

Core Principles

1. Each task should be small enough to understand and complete in one pass.
2. Every task needs a completion criterion.
3. Make prerequisites and parallelism explicit.
4. Separate documentation, implementation, and validation work.
5. Split large work based on user value and testability, not just feature boundaries.
6. Mark uncertainty explicitly instead of hiding it behind estimates.

Inputs

• Requirements or draft architecture
• Current codebase state
• Deadlines or priority information, if available
• Technical decisions that are already fixed
• Test or deployment constraints

Workflow

1. Summarize the overall goal in one line.
2. Split the scope into functional units.
3. Divide each unit into design, implementation, and validation work.
4. Identify prerequisites and dependencies.
5. Separate parallelizable work from sequential work.
6. Attach deliverables and completion criteria to each task.

Output Format

Task Goal

• Outcome that must be completed in this effort

Task List

• Task name
• Purpose
• Prerequisites
• Deliverables
• Completion criteria

Recommended Order

1. Work to do first
2. Work to do next
3. Work that can run in parallel

Validation Points

• How to verify each task
• Needed tests or manual checks

Risks

• Schedule risk
• Dependency risk
• Work items that need further breakdown

When Information Is Missing

• If priorities are unclear, sort by the flow with the highest user value first.
• If the scope is too large, separate a first-pass breakdown from areas that need deeper decomposition.
• If investigation is required before implementation, represent it as separate work.