Task Decomposition
You are breaking down a complex task into smaller, atomic units. Each unit should be independently completable and verifiable.
Core Principle
If a task feels too big, it is too big. Break it down until each piece is obvious.
A well-decomposed task should take no more than a few hours to complete and have a clear definition of done. Aim for tasks that are small, independent, testable, and clearly scoped.
Decomposition Techniques
1. Vertical Slicing
Break by user-visible functionality (each slice is deployable and testable independently):
Feature: User Registration
Slice 1: Email/password signup β form, validation, account creation
Slice 2: Email verification β send email, verify link, UI state
Slice 3: Social login (OAuth) β Google button, OAuth flow, account link2. Horizontal Layering
Break by system layer:
Feature: Order Processing
Layer 1: Data Model β entities, migrations
Layer 2: Data Access β repository, CRUD, queries
Layer 3: Business Logic β service, validation rules
Layer 4: API Endpoints β routes, error handling
Layer 5: Frontend β form, API client, loading/error states3. Workflow Decomposition
Break by process steps:
Task: Checkout flow
Step 1: Cart validation β stock check, quantities, totals
Step 2: Payment β collect details, validate, process
Step 3: Order creation β record, payment link, inventory update
Step 4: Confirmation β email, success page, invoice4. Component Decomposition
Break by UI or system component:
Task: Dashboard page
Component 1: Header β logo, nav, user menu
Component 2: Stats cards β revenue, orders, customers
Component 3: Chart β sales trend, data fetch/transform
Component 4: Orders table β sort, pagination, row actionsFor more detailed worked examples of each technique, see
EXAMPLES.md.
Task Template
For each decomposed task, define:
## Task: [Brief Title]
**Description:**
[What needs to be done in 1-2 sentences]
**Files to Create/Modify:**
- [ ] path/to/file1.ts
- [ ] path/to/file2.ts
**Steps:**
1. [First specific step]
2. [Second specific step]
3. [Third specific step]
**Done When:**
- [ ] [Success criterion 1]
- [ ] [Success criterion 2]
- [ ] Tests pass
**Dependencies:**
- Requires: [Other task if any]
- Blocks: [What this enables]Dependency Management
Identify Dependencies
Task Graph:
[Data Model] βββ¬βββΆ [Repository]
β
ββββΆ [API Types]
β
[Repository] βββββββββββΆ [Service]
β
[API Types] βββββββββββββββββββ€
βΌ
[API Endpoints]Minimize Dependencies
- Prefer tasks that can run in parallel
- Use interfaces to decouple dependencies
- Start with foundational tasks first
Order by Dependencies
Phase 1 (No dependencies):
- Task A: Data model
- Task B: API type definitions
- Task C: UI component skeletons
Phase 2 (Depends on Phase 1):
- Task D: Repository (needs A)
- Task E: API client (needs B)
- Task F: UI logic (needs C)
Phase 3 (Depends on Phase 2):
- Task G: Service (needs D)
- Task H: Connected UI (needs E, F)Decomposition Checklist
For each task, verify:
- Atomic? β Can be done without interruption
- Clear? β Scope is unambiguous
- Testable? β Know when it's done
- Independent? β Minimal dependencies
- Small? β Less than half a day
Integration with Other Skills
- Use design-first to understand the full scope before decomposing
- Use verification-gates to define checkpoints between phases
- Use testing/red-green-refactor to implement each task