Break down an epic
Splits an epic into small, ordered vertical slices that each deliver testable value, with acceptance checks, dependencies and spikes. Use when an epic or large feature is too big to start.
Large epics stall because they are split by technical layer ("build the database", "build the UI"), so nothing works end to end until the very last ticket. Vertical slices cut through every layer and deliver something a user or tester can see, so the team learns early, can ship partway, and can stop when enough value is delivered.
Break down this epic: Only if [TEAM_CONTEXT] is given: Team context: Largest acceptable item: .
- State the goal in one sentence and the scope: what is in, and what is explicitly out.
- Find the walking skeleton: the thinnest end-to-end path that proves the main flow works. Make it slice 1.
- Add slices that each grow the working system, splitting by workflow step, business rule, data variation, happy path then error paths, or user type. Each slice must be independently testable and, where possible, shippable behind a flag.
- Give every slice a one-line acceptance check that a tester could verify, its dependencies on other slices, and a relative size (S, M or L, where L is at most ). Split anything bigger.
- Where an unknown blocks sizing or ordering, add a time-boxed spike with the question it must answer.
- Order the slices so that risk and learning come first and the most valuable behaviour arrives early.
- No layer-only items ("set up the database", "build the API") unless something truly cannot be sliced; then say why.
- At most 15 slices. If the epic needs more, propose how to split the epic itself and break down only the first part.
- Do not invent requirements. Anything you had to assume goes under Risks and open questions.
- Each slice title starts with a verb and names user-visible behaviour.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Goal and scope
One goal sentence, then "In:" and "Out:" bullets.
Slices
Table in delivery order: #, slice, acceptance check, depends on, size.
Spikes
Bullets: question, time box, which slices it unblocks. Or "None".
Risks and open questions
Numbered.
1 required value still a placeholder; the assistant will ask for it.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Software engineering
- category
- Planning
- level
- Intermediate
- made for
- Tech lead / staff engineer, Product manager, Engineering manager, Software engineer
- risk
- read-only
- version
- v1.0.0 · experimental
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install break-down-epic --target claude-codenpx skills add hermes-hq/hodios-dist --skill break-down-epic -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-software-engineering@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of PlanningWrite user stories
Turns a feature description into small, independent user stories for specific users, each with acceptance criteria, and splits stories that are too big. Use when preparing a backlog.
write-user-storiesEstimate work as a range
Breaks engineering work into tasks and produces a range estimate with a confidence level, stated assumptions and the unknowns that need a spike. Use when asked "how long will this take?".
estimate-with-rangesWrite an implementation plan
Reads the codebase and writes an ordered implementation plan in small verifiable steps, with files to touch, tests, rollout and risks. Use before coding any change that spans several files.
write-implementation-planPlan a spike
Turns a technical unknown into a time-boxed spike with a sharp question, exit criteria, cheapest-first experiments and a clear deliverable. Use when an unknown blocks a decision or an estimate.
plan-spikeFeature track
Takes a feature from open questions to a reviewed implementation in six gated steps, saving each step's artifact to the repo. Use for any change bigger than a quick fix.
feature-trackPlan a sprint
Builds a sprint plan from a backlog and real capacity, with a sprint goal, committed and stretch items, dependencies, risks and what it deliberately leaves out. Use before sprint planning.
plan-sprint