To Epic
Invoking this skill is the owner's standing approval for the full planning transaction set of one Epic — Epic intake, child work-item intake, refinement, rank placement, every proposed -> ready transition — superseding $backlog's per-transaction pauses for exactly these transactions; follow $backlog for everything else. It additionally authorizes $guidance publication for the subjects the owner names at step 2, and nothing else in docs/wiki. It never authorizes cancellation, other wiki mutation, execution claims, or records outside this Epic and its children.
Pause only at the evidence decision (step 2), a $guidance rule-replacement pause, and hard blockers; otherwise run to completion and report. Only $to-product's contract covers the rule-replacement pause — never otherwise suppress it. User-invoked only — or by $to-product, whose autonomous contract auto-answers every pause.
When at least two planning concerns are independent, invoke $parallel-execution for read-only analysis of slicing, dependencies, shared contracts, risks, acceptance, and verification. This context synthesizes the Epic and serializes every evidence decision and $backlog mutation.
Workflow
- Epic intake — Establish the coordinated outcome from the conversation or named sources, then create the
proposed Epic via $backlog intake with provenance. Add its active-index entry as - [EPIC-NNN: <title>](EPIC-NNN-short-title/) - <outcome>.; link the Epic directory with the trailing /, never its EPIC-NNN.md record. If the outcome doesn't need multiple work items, stop and recommend $to-backlog instead. If the user names an existing proposed Epic, resume at its first incomplete step; reject ready, in-progress, or terminal Epics.
- Evidence decision — Before proposing any child, inventory the technologies and standards the Epic's outcome implicates, using
$research's delta-scoped subject rule — never a whole-stack survey. Apply $research step 2's concept triggers; name each implicated standard subject or record why none applies — an empty standards half without a recorded reason is invalid. Report each subject's page state under docs/wiki/engineering/: missing, draft, version-mismatched against the manifest, stale per $research's thresholds, or current. Then ask the owner one question covering both: run $guidance for which of those subjects, and run $research on the Epic? Never skip or answer either half yourself, unless $to-product's autonomous contract answers it.
$guidance → naming a subject is the decision to run $guidance for it now, before child intake — deferring it to implementation or acceptance is not an outcome. Run it for the named subjects only, under this invocation's approval; $research's no-wiki-during-planning rule does not apply to $guidance pages. Its fresh pages then answer those subjects for research and for child refinement.$research yes → run it after guidance; use the findings to inform child slicing.$research no → record the decision on the Epic. Children still need individually justified research states; if a version-specific or security-sensitive question surfaces later, ask again for that record — never relabel uncertainty.
- Child intake — Slice the outcome into the smallest coherent, independently valuable Stories/Tasks/Bugs with
parent: EPIC-NNN, relationships, blockers, and provenance via $backlog. Rank placement: the user's stated position, else append in dependency order at the end of the global rank.
- Refine to ready — For each child in rank order: refine against its template and accepted wiki state; resolve research (
complete from Epic findings or a child-level $research run, not-needed only with inspecting evidence); resolve decisions per $backlog's Definition of Ready, reading existing ADRs first and naming any one a draft would supersede — decisions: none only when the significance test records no qualifying decision; every decision confirmed in discussion or named in the record body becomes decisions: draft with an ADR-shaped draft under ## Decisions, never deferred in prose; fill ## Execution with approach, verification commands, and its conflict domain or fixed interface, citing this invocation as the recorded approval; verify the full Definition of Ready; transition to ready. Then refine the Epic — outcome, objective criteria, exclusions, coordination approach, its own Epic-level decisions, and the template's complete provisional execution graph — and set it ready. If any graph row is unresolved, keep the Epic proposed; implementation revalidates every row against live code. Never allocate or publish an ADR here — publication happens at acceptance.
- Report — Epic and child IDs with type, status, rank position, research state, and decisions state with each drafted decision named; the evidence decision, every guidance page created or refreshed, and every rule-replacement pause with its outcome; commit hashes; final
node scripts/validate-project.mjs result. Any record left proposed gets its named blocker and resumption point.
A failed validator, unresolved research the owner declined, or a missing readiness requirement is a blocker: leave the record proposed, keep committed transactions intact, and report — never force ready.
End the report with Next step: — one copy-pasteable command from the outcome: everything ready → $implement EPIC-NNN (local serial execution) or $implement-with-subagents EPIC-NNN (fresh subagents, serial on one branch); a record left proposed → the exact resume command after its named blocker.
1---2name: to-epic3description: Plan one coordinated outcome end-to-end into a ready Epic under one standing approval. Use when asked to plan an Epic; not for standalone items — use to-backlog.4---56# To Epic78Invoking this skill is the owner's standing approval for the full planning transaction set of one Epic — Epic intake, child work-item intake, refinement, rank placement, every `proposed -> ready` transition — superseding `$backlog`'s per-transaction pauses for exactly these transactions; follow `$backlog` for everything else. It additionally authorizes `$guidance` publication for the subjects the owner names at step 2, and nothing else in `docs/wiki`. It never authorizes cancellation, other wiki mutation, execution claims, or records outside this Epic and its children.910Pause only at the evidence decision (step 2), a `$guidance` rule-replacement pause, and hard blockers; otherwise run to completion and report. Only `$to-product`'s contract covers the rule-replacement pause — never otherwise suppress it. User-invoked only — or by `$to-product`, whose autonomous contract auto-answers every pause.1112When at least two planning concerns are independent, invoke `$parallel-execution` for read-only analysis of slicing, dependencies, shared contracts, risks, acceptance, and verification. This context synthesizes the Epic and serializes every evidence decision and `$backlog` mutation.1314## Workflow15161. **Epic intake** — Establish the coordinated outcome from the conversation or named sources, then create the `proposed` Epic via `$backlog` intake with provenance. Add its active-index entry as `- [EPIC-NNN: <title>](EPIC-NNN-short-title/) - <outcome>.`; link the Epic directory with the trailing `/`, never its `EPIC-NNN.md` record. If the outcome doesn't need multiple work items, stop and recommend `$to-backlog` instead. If the user names an existing `proposed` Epic, resume at its first incomplete step; reject `ready`, `in-progress`, or terminal Epics.172. **Evidence decision** — Before proposing any child, inventory the technologies and standards the Epic's outcome implicates, using `$research`'s delta-scoped subject rule — never a whole-stack survey. Apply `$research` step 2's concept triggers; name each implicated standard subject or record why none applies — an empty standards half without a recorded reason is invalid. Report each subject's page state under `docs/wiki/engineering/`: missing, `draft`, version-mismatched against the manifest, stale per `$research`'s thresholds, or current. Then ask the owner one question covering both: run `$guidance` for which of those subjects, and run `$research` on the Epic? Never skip or answer either half yourself, unless `$to-product`'s autonomous contract answers it.18 - `$guidance` → naming a subject is the decision to run `$guidance` for it now, before child intake — deferring it to implementation or acceptance is not an outcome. Run it for the named subjects only, under this invocation's approval; `$research`'s no-wiki-during-planning rule does not apply to `$guidance` pages. Its fresh pages then answer those subjects for research and for child refinement.19 - `$research` yes → run it after guidance; use the findings to inform child slicing.20 - `$research` no → record the decision on the Epic. Children still need individually justified research states; if a version-specific or security-sensitive question surfaces later, ask again for that record — never relabel uncertainty.213. **Child intake** — Slice the outcome into the smallest coherent, independently valuable Stories/Tasks/Bugs with `parent: EPIC-NNN`, relationships, blockers, and provenance via `$backlog`. Rank placement: the user's stated position, else append in dependency order at the end of the global rank.224. **Refine to ready** — For each child in rank order: refine against its template and accepted wiki state; resolve research (`complete` from Epic findings or a child-level `$research` run, `not-needed` only with inspecting evidence); resolve `decisions` per `$backlog`'s Definition of Ready, reading existing ADRs first and naming any one a draft would supersede — `decisions: none` only when the significance test records no qualifying decision; every decision confirmed in discussion or named in the record body becomes `decisions: draft` with an ADR-shaped draft under `## Decisions`, never deferred in prose; fill `## Execution` with approach, verification commands, and its conflict domain or fixed interface, citing this invocation as the recorded approval; verify the full Definition of Ready; transition to `ready`. Then refine the Epic — outcome, objective criteria, exclusions, coordination approach, its own Epic-level decisions, and the template's complete provisional execution graph — and set it `ready`. If any graph row is unresolved, keep the Epic `proposed`; implementation revalidates every row against live code. Never allocate or publish an ADR here — publication happens at acceptance.235. **Report** — Epic and child IDs with type, status, rank position, research state, and decisions state with each drafted decision named; the evidence decision, every guidance page created or refreshed, and every rule-replacement pause with its outcome; commit hashes; final `node scripts/validate-project.mjs` result. Any record left `proposed` gets its named blocker and resumption point.2425A failed validator, unresolved research the owner declined, or a missing readiness requirement is a blocker: leave the record `proposed`, keep committed transactions intact, and report — never force `ready`.2627End the report with `Next step:` — one copy-pasteable command from the outcome: everything ready → `$implement EPIC-NNN` (local serial execution) or `$implement-with-subagents EPIC-NNN` (fresh subagents, serial on one branch); a record left `proposed` → the exact resume command after its named blocker.
beeltec