Docs · Work types
Epics
An epic is a Work item that contains other Work items. Sessions can run on child Work items or the epic directly. An epic resolves when all child Work items have verified proof.
Structure
An epic contains:
- Title — the name of the larger feature or initiative.
- Description — context and background.
- Definition of done — the acceptance criteria for the epic as a whole.
- Child Work items — bugs, features, investigations, or other epics nested inside.
Child Work items are independent Work items linked to the parent epic. Each child has its own state, sessions, and proof.
Sessions on epics
Sessions can run on:
- A child Work item — most common. Agent works on a specific bug or feature within the epic.
- The epic directly — for coordination, planning, or cross-cutting changes that span multiple child items.
A session on the epic does not automatically advance child item states. Each child item must be resolved independently.
Proof rollup
An epic resolves through two layers of proof:
- Child proof — each child Work item must be in RESOLVED state with verified proof attached.
- Epic-level proof — acceptance evidence for the epic as a whole: integration test output, a recorded demo, or operator sign-off confirming the full feature is complete.
If any child item is unresolved, the epic’s RESOLVED button is blocked.
Epic state machine
Epics follow the same state machine as all Work items:
OPEN— created, no sessions started on any child.IMPLEMENTING— at least one child Work item has an active session.VERIFYING— all child Work items are resolved; epic-level proof not yet attached.RESOLVED— all children resolved and epic-level proof is verified.
The epic state advances automatically as child items move through their states.
GitHub integration
GitHub milestone import is planned. When available:
- A GitHub milestone imports as an epic in Zero.
- Issues within the milestone import as child Work items.
- Milestone close date maps to epic definition of done.