task-breakdown-phase

This skill orchestrates the /tasks phase, producing tasks.md with:

• Right-sized tasks (0.5-1 day each, 4-8 hours)
• TDD workflow (test → implement → refactor triplet for all components)
• Clear acceptance criteria (2-4 testable checkboxes per task)
• Explicit dependencies (task numbers, critical path, parallel opportunities)
• Implementation hints (reuse patterns, file paths, references to plan.md)

Inputs: plan.md (architecture, components, reuse strategy) Outputs: tasks.md (20-30 tasks sequenced by dependencies) Expected duration: 30-60 minutes

<quick_start> Execute /tasks workflow in 12 steps:

1. Parse plan.md - Extract architecture components, reuse patterns, data models, API endpoints, UI components
2. Generate foundation tasks - Database migrations, model definitions, configuration setup (3-5 tasks)
3. Generate business logic tasks - TDD triplet (test → implement → refactor) for each service/utility (2-4 tasks per component)
4. Generate API tasks - TDD for controllers/routes (test → implement per endpoint)
5. Generate UI tasks - TDD for components (test → implement per screen/component) if HAS_UI
6. Generate integration tasks - E2E tests, smoke tests, integration validation (2-3 tasks)
7. Map dependencies - Build dependency graph, identify critical path, mark parallel opportunities
8. Size tasks - Validate 0.5-1 day per task (split if >1.5 days, combine if <0.5 day)
9. Write acceptance criteria - 2-4 testable checkboxes per task using AC templates
10. Add implementation notes - Reuse hints, file paths, plan.md references for complex tasks
11. Generate tasks.md - Render with task summary (total, duration, critical path, distribution)
12. Validate and commit - Check 20-30 tasks total, all AC clear, TDD followed, dependencies explicit

Key principle: Every task is test-driven with measurable acceptance criteria. </quick_start>

If prerequisites not met, return to /plan phase.

Extract all implementation components from plan.md:

Architecture components to extract:

• Data layer: models, schemas, migrations
• Business logic: services, utilities, helpers
• API layer: controllers, routes, middleware
• UI layer: components, screens, forms (if HAS_UI)
• Testing: integration points, E2E scenarios

Reuse patterns to identify:

• Existing services/utilities referenced in plan.md
• Shared components/libraries to leverage
• Established patterns to follow (e.g., BaseService, repository pattern)

Quality check: All components from plan.md extracted, reuse opportunities documented.

See reference.md for component extraction examples.

Create infrastructure setup tasks (first to execute, all others depend on these).

Foundation task categories:

1. Database migration task (create tables, indexes, constraints)
2. Model definition tasks (data models, schemas, validation)
3. Configuration tasks (environment setup, dependency installation)

Example foundation task:

Task 1: Create database migration for student progress tables

Complexity: Small (2-4 hours)

Steps:
1. Create migration file (alembic revision --autogenerate)
2. Define students table (id, name, grade_level, created_at)
3. Define lessons table (id, student_id, subject, duration_mins)
4. Add indexes (student_id, created_at)
5. Add foreign key constraints

Acceptance criteria:
- [ ] Migration runs successfully on clean database
- [ ] Rollback works without errors
- [ ] Indexes improve query performance (measured)
- [ ] Foreign keys enforce referential integrity

Dependencies: None (foundation task)
Blocks: Task 4 (model definitions)