| name | epic-breakdown |
| description | Decompose large epics into sprint-ready sub-epics using 9 splitting patterns. Use this skill when:
- A spec is approved and you need to break a large feature into estimable work items for engineering
- You want to split an epic that is too large for a single sprint
- You need sized sub-epics with story point estimates for sprint planning
- You are preparing for engineering handoff and need to identify work packages
|
Epic Breakdown
Take a spec's Functional Requirements and Differences sections, apply 9 decomposition patterns to produce sized sub-epics ready for sprint planning.
Workflow
- Read spec from your spec directory
- List all functionality blocks and platform/user differences
- Evaluate which splitting patterns apply to each block
- Generate sub-epics with estimates
- Map dependencies between sub-epics
- Suggest sprint allocation
- Output to file or print
The 9 Splitting Patterns
| # | Pattern | When to Use |
|---|
| 1 | Workflow Steps | Multi-step flow (create -> configure -> publish) |
| 2 | Business Rules | Complex validation logic |
| 3 | Data Variations | Multiple content types or input formats |
| 4 | Platform Differences | Different behavior across web/mobile/tablet/offline |
| 5 | Operations (CRUD) | Standard data management flow |
| 6 | Spike/Research | Technical unknowns or third-party integrations |
| 7 | Performance | Specific NFR targets |
| 8 | Persona Variations | Different behavior per user role |
| 9 | Happy Path vs Edge Cases | Feature can deliver value with just happy path |
See references/splitting-patterns.md for detailed examples of each pattern.
Story Point Guide
| Points | Complexity | Example |
|---|
| 1 | Simple, no unknowns | Config change, copy update |
| 2 | Small, minor complexity | Add a field, simple UI change |
| 3 | Medium, some complexity | New API endpoint, form with validation |
| 5 | Significant, multiple components | New screen with backend integration |
| 8 | Large, cross-cutting | Offline sync, real-time updates |
| 13 | Very large — SPLIT FURTHER | Use the 9 patterns to decompose |
If estimate > 8 points, attempt to split further using the patterns.
Output Format
# Epic Breakdown — {Feature Name}
**Source Spec:** {path}
**Date:** {DD-MM-YYYY}
**Total Sub-Epics:** {count}
**Total Estimated Points:** {sum}
---
## Sub-Epics
### SE-001: {Title}
**Pattern:** {which of the 9}
**Estimate:** {points} points
**Spec Section:** {reference}
**Description:** {what this delivers}
**Dependencies:** {SE-NNN or "None"}
**Acceptance Summary:** {key outcomes}
---
## Dependency Map
```mermaid
graph TD
SE-001 --> SE-003
SE-002 --> SE-003
Sprint Allocation
| Sprint | Sub-Epics | Points | Theme |
|---|
| Sprint 1 | SE-001, SE-002 | {n} | Core happy path |
| Sprint 2 | SE-003, SE-004 | {n} | Edge cases + offline |
Summary
| Pattern Used | Count | Total Points |
|---|
| Workflow Steps | {n} | {n} |
| Happy Path vs Edge | {n} | {n} |
## Anti-Patterns
- Don't create sub-epics smaller than 1 point — group them
- Don't ignore dependencies — they determine sprint order
- Don't estimate > 13 points — split further instead
- Don't skip the dependency map — it prevents sprint planning surprises
## Quality Checklist
- [ ] Every sub-epic has a clear pattern attribution
- [ ] All estimates are Fibonacci (1, 2, 3, 5, 8, 13)
- [ ] Dependencies are mapped
- [ ] Sprint allocation respects dependencies
- [ ] No sub-epic exceeds 8 points without a split rationale
