| name | decomposition |
| description | Break software milestones, features, epics, requirements, and architecture plans into executable stories, tasks, and subtasks with clear boundaries and acceptance criteria. |
Purpose
This skill helps convert large product or technical plans into work that can be
owned, estimated, scheduled, implemented, and reviewed.
Use this skill when:
- Breaking milestones into epics
- Turning requirements into stories
- Splitting technical designs into tasks
- Preparing work for estimation
- Identifying missing deliverables
- Creating executable implementation plans
Inputs
Expected inputs:
- Roadmap milestone
- Scope statement
- Requirements
- Architecture direction
- Acceptance criteria
- Constraints
- Known risks
Inputs usually come from roadmapping, scoping, and architecture. If the
work is not bounded, use scoping before decomposing it.
Decomposition Principles
Always optimize for:
- Independently executable work
- Clear ownership
- Testable acceptance criteria
- Visible dependencies
- Small enough tasks to estimate
Avoid optimizing solely for:
- Artificial task count
- Team structure over product value
- Implementation detail without acceptance criteria
- Splitting work so small it loses meaning
- Hiding integration work
Process
Step 1: Identify Deliverables
Determine:
- User-facing deliverables
- Backend or data deliverables
- Integration deliverables
- Operational deliverables
- Test and verification deliverables
Flag work that lacks a clear output.
Step 2: Break into Work Items
Convert deliverables into:
- Epics
- Stories
- Tasks
- Subtasks
- Spikes
Each item should have a clear purpose and completion condition.
Step 3: Add Acceptance Criteria
For each item, define:
- Expected behavior
- Verification method
- Dependencies
- Owner or owning area
- Done condition
Prefer acceptance criteria that can be tested or reviewed.
Step 4: Identify Missing Work
Check for:
- Data migrations
- Feature flags
- Observability
- Error handling
- Documentation
- Rollout and rollback
- Security review
Step 5: Produce Executable Work Breakdown
Generate:
- Grouped work items
- Acceptance criteria
- Dependencies
- Open questions
- Recommended next actions
Anti-Patterns
Avoid:
- Decomposing unscoped ideas
- Creating tasks without acceptance criteria
- Ignoring testing and rollout work
- Hiding dependency work inside broad tasks
- Creating tasks that cannot be owned
- Mixing roadmap phases with sprint tasks
Reviewer Checklist
Before finalizing decomposition:
- Is every work item executable?
- Are acceptance criteria clear?
- Are dependencies visible?
- Are verification tasks included?
- Can
dependency-analysis and estimation use the breakdown?
Escalation Guidance
Escalate when:
- Requirements are too vague to split
- Architecture decisions are missing
- Work crosses unclear ownership boundaries
- Dependencies block task definition
- Acceptance criteria cannot be verified
Example
Input:
- Architecture: Persist checklist progress and expose checklist APIs
Expected work items:
- Add workspace setup state fields
- Create checklist read endpoint
- Create checklist update endpoint
- Add frontend checklist state handling
- Add analytics event on completion
Recommended next skill:
- Use
dependency-analysis to identify blockers and sequencing constraints.