task-decomposition

Task Decomposition

Break work into ordered, well-scoped tasks that can be independently implemented and verified.

Decomposition Process

1. Identify Units of Work

• Break the work into the smallest units that are independently valuable
• Each unit should produce a verifiable outcome (a passing test, a working endpoint, observable behavior)
• Avoid tasks that are too large to complete in a single session
• Avoid tasks that are too small to be meaningful (e.g., "add an import statement")

2. Define Acceptance Criteria

For each task, define what "done" looks like:

• Be specific and measurable -- avoid vague criteria like "works correctly"
• Include both positive cases (what should work) and negative cases (what should be rejected)
• Reference exact behavior: error messages, status codes, output format, performance thresholds
• If a task modifies existing behavior, state both the before and after

3. Assign Verification Type

Each task must have a verification method. Choose the most appropriate:

Verification Type	When to Use
Unit test	Pure logic, data transformations, utility functions
Integration test	Cross-module interactions, database operations, API contracts
E2E test	User-facing workflows, multi-service interactions
Manual verification	UI/UX behavior, visual correctness, one-time infrastructure changes
Build verification	Compilation, type checking, linting, bundle size
Deploy verification	Service health checks, smoke tests, monitoring dashboards

4. Map Dependencies

• Identify which tasks must complete before others can start
• Order tasks so that each builds on a stable foundation
• Prefer independent tasks that can run in parallel where possible
• Flag external dependencies (other teams, services, permissions, data) that may block progress

5. Determine Execution Order

• Place foundational tasks first (types, schemas, interfaces, shared utilities)
• Follow with implementation tasks (business logic, handlers, services)
• Then integration tasks (wiring, configuration, API routes)
• Finish with verification tasks (test suites, documentation, cleanup)

6. Assign Required Skills

Map each task to the skills needed to complete it. This enables delegation to specialized agents or helps identify what expertise is required.

Output Format

## Task Breakdown

### Task 1: [imperative description]
- **Acceptance criteria:**
  - [specific, measurable criterion]
  - [specific, measurable criterion]
- **Verification:** [type] -- [how to verify]
- **Dependencies:** [none | task IDs that must complete first]
- **Skills:** [list of skills needed]

### Task 2: [imperative description]
- **Acceptance criteria:**
  - [specific, measurable criterion]
- **Verification:** [type] -- [how to verify]
- **Dependencies:** [Task 1]
- **Skills:** [list of skills needed]

### Execution Order
1. [Task 1, Task 3] (parallel -- no dependencies)
2. [Task 2] (depends on Task 1)
3. [Task 4] (depends on Task 2, Task 3)

### External Dependencies
- [dependency] -- [who owns it] -- [current status]

Rules

• Every task must have at least one acceptance criterion that can be empirically verified
• Do not create tasks that cannot be verified -- if you cannot define how to prove it is done, the task is not well-scoped
• Keep tasks ordered so that no task references work that has not been completed by a prior task
• Flag any task that requires access, permissions, or external input not yet available
• Prefer more small tasks over fewer large tasks -- smaller tasks are easier to verify and less risky to fail
• Do not create placeholder or "TODO" tasks -- every task should describe concrete work