Run discovery once,
land it in slices.
Some features split into tasks that ship separately. Run each task as its own workflow and you pay for the same background work every time. An epic makes you pay once: intake, scout, research and spec run one time, and every slice inherits them.
Choose the epic track
Use an epic when one feature splits into tasks that can ship on their own, and when those tasks also share the same background work. The test is whether a second workflow would read the same code and reach the same answers; if it would, you are about to pay for that reading twice.
Start it like any other work: /triage classifies the request and offers you a track, and you pick epic when you see it.
> /triage "your multi-slice feature"
Triage writes .claude/state/epic/<slug>.json next to the usual workflow state. Later children read that file to learn which slice they own and which research they inherit, so it has to stay put once the epic is under way.
Run discovery once
The epic track carries ten nodes and stops at the commit: intake, scout, research, spec, spec-shippability-review, approve-direction, roadmap-sync, memory-sync, grant-commit, commit. Code comes later, in the children.
Your roadmap tracks a multi-slice feature on its own. The epic adds itself when its discovery commits, and each child turns its own row green as it lands, so nobody keeps the plan current by hand. Epics that predate this go on with node .claude/skills/roadmap-sync/cli.mjs backfill. Add --dry-run to read the report first.
What you get is a sliced spec at docs/specs/<epic>.md, in which each future child has its own ## Slice <id> section holding that child's acceptance criteria. You approve the whole document once, at gate A.
That single approval has two consequences worth planning around. Write each slice so that it can ship on its own, because you get one approval and no later chance to redraw the lines. Put each acceptance criterion in exactly one slice as well, since an AC appearing in two slices will simply be built twice.
The discovery bundle commits live, which means the spec, scout and research stay exactly where they are. If a child runs three weeks later it must still be able to find them, so archiving them now would break every child still waiting.
Land a slice
Open a session and describe the slice you want to build. If an approved epic is active, triage will match your request to an open slice and pick the epic-child track for you.
A child skips discovery entirely and pins whatever the epic already produced. Its declared graph is implementation, simplify, security, integrate, document, archive, roadmap-sync, memory-sync, grant-commit, commit. The first node is a selector: a slice with independent components fans out to swarm workers, and a single-component slice runs solo. Three of the later nodes only run when they are needed.
track_guard blocks every write on a child until two things are true: the epic's approval token must exist at .claude/state/spec_approvals/<epic>.approval, and its pinned scout, research and spec must all still be findable. Because the guard enforces both, a child cannot run on an epic whose discovery was skipped, nor on one whose files have since moved.
Each child ends at its own /grant-commit, so slices land one at a time. Should a slice turn out to be wrong, it costs you a single child workflow and the rest of the epic still stands.
Escalate a risky slice
Record the risk on the slice as you write the sliced spec. Triage reads those flags and adds simplify, security and document to that particular child, while a slice carrying no risk flags runs the short path and skips all three.
You do this per slice, which is the whole point of slicing risk: the one risky child gets a security review, and the other slices stay lean.
Read the epic state
Check .claude/state/epic/<slug>.json to see which slices are left and which children have landed.
{
"epic": "erp-portables",
"artifacts": { scout, research, spec — the pinned paths },
"slices": [ { "id": "A", "title": …, "acs": […], "risk": […] } ],
"approved": true,
"children": [ { "slice": "A", "slug": "…-slice-a", "status": "committed" } ]
}
The approved flag is guarded. epic_approval_guard will let it flip to true only when the matching .claude/state/spec_approvals/<slug>.approval token is on disk, that token being the lasting record of a real gate-A approval. Other writes pass through untouched: appends to children, status flips, and rewrites of an epic that is already approved.
The guard checks two things only: that the token exists, and that the slug matches. The token then stays valid indefinitely, so an approved spec remains approved and children can keep landing weeks afterwards.
When to use something else
Work that lands in one change has nothing to spread out. Use intake-full or something lighter.
Want separate tasks built at the same time, in one workflow? That is the swarm path at phase 6.
A batch of tickets that already have specs is the power track. It saves repeat work on the mechanical phases.
An epic pays off when discovery is the expensive part and the tasks land over time. If the build is the expensive part and all of it can land at once, one of the three options above will cost you less.