/create-epics

name: create-epics
description: "Turns the GDDs and architecture into epics, one per architectural module. Use when the user wants to break the game into epics or plan the work before writing stories. Not for splitting one epic into stories."
argument-hint: "[system-name | layer: foundation|core|feature|presentation | all] [--review full|lean|solo]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash "*/.claude/skills/create-epics/../../hooks/yaml-helper.sh" resolve_config *), Bash(bash .claude/scripts/gdd-structure-check.sh*), Bash(bash .claude/scripts/adr-status.sh*), Bash(bash .claude/scripts/md-section.sh *), Bash(bash .claude/scripts/write-guard.sh overwrite *)
model: sonnet

!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,review_gate,automation,workflow,docs.density,engine_values,system_overrides`

Resolved above — use as-is; `--review` overrides `review_mode`. No block → defaults in `.claude/docs/config-resolution.md`.

Ask with the question tool. Without one, list the options numbered and end your turn to wait. A skipped or dismissed question is not an answer: ask again in plain text.

Create Epics

An epic is a bounded body of work for one architectural module: **what** gets built and which decisions govern it. How to build it is for the stories. Run it once per layer as development reaches that layer: Feature epics written before Core is nearly done describe a design that will have changed.

**Writes:** `production/epics/[epic-slug]/EPIC.md` per epic and its row in `production/epics/index.md`, each after its own yes. **Next:** `/create-stories [epic-slug]` per epic. This skill never writes a story.

Asks follow `.claude/docs/automation-modes.md` (collaborative always asks, guided asks on major choices, autonomous logs and goes on; `automation_always_ask` categories always ask).

Checklist (copy it and tick as you go):

- [ ] Phase 1: scope and tier
- [ ] Phase 2: inputs loaded and reported
- [ ] Phase 3: each epic shown, "Shall I create Epic: …?" asked one at a time
- [ ] Phase 4: producer review run, or its skip noted
- [ ] Phase 5: each EPIC.md and index row written after its own yes
- [ ] Phase 6: closing block printed

Phase 1: Scope and tier

The text typed after the skill name, with any `--review <mode>` pair removed:

• `all`: every system, in layer order.
• `layer: foundation` (or `core`, `feature`, `presentation`): that layer only.
• a system name: that system only.
• nothing: the request's own words when they name a layer or system ("foundation

and core"); else ask "Which layer or system would you like epics for?"

**Tier.** The project's `workflow` value sets what is required (Phase 2). Each in-scope system's own GDD bar comes from its `system_overrides` row, when it has one.

**At `minimal`, tell the user first:** this step is optional at this tier, because `/create-stories` builds the epic from `design/game-brief.md` by itself. Then go on when they asked for epics.

Phase 2: Load the inputs

`minimal`: the brief

Read `design/game-brief.md`. None: stop, "No `design/game-brief.md` — run `/start` or `/brainstorm` first." Never ask for GDDs, a systems index, an architecture document, ADRs, a TR registry or a control manifest, and never send the user to `/design-system`, `/map-systems` or `/create-architecture` first: this tier has none by design.

Report first, word for word:

Loaded: design/game-brief.md · engine [name version from the engine_values line]
At minimal this step is optional: /create-stories builds the epic from the brief by itself.

The epics come from the brief's Features list (MVP in older briefs), in its **Build order**. A short brief is one epic, slugged from the brief's working title (the slug `/create-stories` uses when nothing is typed). When the user asks for the work grouped, make one epic per group of features that ship together. Every epic names its slug, since `/create-stories` needs it typed.

`standard` and `full`: the design and the architecture

1. **The system GDDs.** `bash .claude/scripts/gdd-structure-check.sh` lists every system GDD; the game concept, systems index, pillars, cross-reviews and the other non-system documents are left out for you. Their count is **N**. N is 0: stop, "No system GDDs found in `design/gdd/` — run `/design-system` first." 2. **What is in scope.** Each GDD's `## Summary` quick reference gives its layer and priority. A GDD with no Summary (older GDDs predate it) takes its layer from `design/gdd/systems-index.md`. Never treat an absent `## Summary` as an absent system: it never drops one from scope. 3. **The architecture.** `docs/architecture/architecture.md` is required at both tiers: missing, stop with "No `docs/architecture/architecture.md` — run `/create-architecture` first." Never invent module boundaries. 4. **For in-scope systems only**, by section, never whole:

• each GDD's Overview and Acceptance Criteria

(`bash .claude/scripts/md-section.sh extract design/gdd/<file>.md "Overview"`);

• `bash .claude/scripts/adr-status.sh` for every ADR's status, layer and missing

sections; then the GDD Requirements Addressed, Decision and Engine Compatibility sections of the ADRs that cover in-scope systems;

• `docs/architecture/tr-registry.yaml`: the entries whose `system:` is an

in-scope system;

• the control manifest's `Manifest Version` line (read if present at `standard`,

required at `full`);

• `docs/engine-reference/<engine>/VERSION.md` for the engine's risk levels.

Report before defining anything, with the real state:

Loaded: [N] system GDDs, [n] in scope ([names]) · [M] ADRs ([A] Accepted, [P] Proposed) · manifest v[date | absent] · engine [name version from the engine_values line]

At `full`, every in-scope GDD needs all 8 sections and Approved status, and the TR registry and control manifest are required.