epic-workflowlisted

# epic-workflow The layer above `task-workflow`. `task-workflow` takes one task to shipped code; this decides what the tasks *are* and in what order, then feeds them in one at a time. It adds no gate of its own. Every unit still goes through `task-workflow`'s spec gate — approving an epic approves the *decomposition*, never a unit's spec, and `.claude/memory/EPIC.md` deliberately does not satisfy `spec-gate-guard.mjs`. Don't try to make it: the guard reads `PLAN.md` at the repo root, and an epic-level approval standing in for five unwritten specs is exactly the drift the gate exists to stop. ## When not to use - **The request fits one `PLAN.md`** — one spec, one implement/verify loop, one mergeable diff. That's `task-workflow`. Decomposing it costs a session and buys nothing. - **A bug, however tangled.** `debug-workflow` triages it; the fix is one task. - **A roadmap.** More than ~8 units isn't an epic — see the ceiling in step 3. ## Steps 1. **Triage.** An epic must clear this bar: **3+ units**, *or* it spans more than one mergeable PR, *or* it touches two-plus distinct surfaces (a contract *and* its consumers, a migration *and* the code reading it). If it fails the bar, say so in one sentence and hand straight to `task-workflow` — don't decompose to justify the invocation. 2. **Clarify.** Up to 3 questions, and only about what changes the *decomposition*: sequencing, what's explicitly out, which surface is authoritative when two disagree. Not implementation detail —