task-breakdown-phase

Breaking down features into test-driven tasks involves decomposing your implementation plan into 20-30 right-sized tasks (0.5–1 day each), defining measurable acceptance criteria for each, and sequencing them to prioritize writing tests before code. This ensures clarity on completion and enforces TDD discipline from the start.

Structure tasks following the RED → GREEN → REFACTOR cycle: write test cases first (RED phase), implement minimal code to pass tests (GREEN phase), then refactor for quality. This TDD-first sequencing prevents scope creep, ensures testability, and keeps tasks focused and manageable.

Acceptance criteria are measurable conditions that define when a task is complete. Extract them from your spec and plan by identifying testable behaviors, edge cases, and dependencies. Clear criteria prevent ambiguity, enable parallel work, and provide developers with explicit completion targets.

Yes. Task breakdown is applied after high-level planning and architecture are defined. It transforms detailed implementation plans into concrete, sequenced work items with explicit dependencies and acceptance criteria, making your workflow-state and task list ready for the implementation phase.

You need your specification document (spec.md), detailed implementation plan (plan.md), and architecture definitions. The task-breakdown phase consumes these to generate a comprehensive tasks.md file and updated workflow-state.yaml with dependencies, criteria, and documentation.

Dependency mapping sequences tasks along critical and parallel paths, reducing bottlenecks and enabling concurrent work. It prevents developers from starting tasks blocked by prerequisites, accelerates delivery, and provides visibility into project risk and timeline.