Epic mode
Epic mode is how the current product turns an Architect plan into a coordinated coder run. It is designed for one parent conversation, multiple child implementation slices, one shared branch, and one resulting PR.
How it fits together
- Architect produces suggested tasks on a parent card.
- You review the list, dismiss anything that should not ship, and keep the rest pending.
- Implement all creates child coder cards and copies the relevant task specs.
- Child tasks execute in dependency order inside a shared sandbox / branch context.
- The epic produces a single PR tied back to the parent work.
Why use epics
- Keeps the Architect breakdown visible as child tasks.
- Avoids opening many unrelated PRs for one cohesive change.
- Preserves traceability from PRD and ADR to implementation order.
Parent and child responsibilities
- The parent card owns discussion and review.
- Child cards are internal execution units that show progress, queue state, or failures.
- User comments stay on the parent, not on the child tasks.
- Suggested task dependencies decide which child tasks stay queued until earlier work finishes.
When not to use epics
- Unrelated work that should ship independently.
- Hotfixes that need the smallest possible PR.