brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
epic-breakdownDecompose 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…
Independent GitHub snapshot · Automated classification · Original documentation governs
name: epic-breakdown description: | Decompose large epics into sprint-ready sub-epics using 9 splitting patterns. Use this skill when:
Take a spec's Functional Requirements and Differences sections, apply 9 decomposition patterns to produce sized sub-epics ready for sprint planning.
| # | 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.
| 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.
# 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 | Sub-Epics | Points | Theme |
|---|---|---|---|
| Sprint 1 | SE-001, SE-002 | {n} | Core happy path |
| Sprint 2 | SE-003, SE-004 | {n} | Edge cases + offline |
| 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