Create Epics

What Is This

The Create Epics skill (create-epics) is a technical director utility designed for the Happycapy Skills platform. Its primary function is to systematically translate approved Game Design Documents (GDDs) and architectural plans into high-level "epics." Each epic corresponds to a single architectural module, such as a subsystem or a layer (foundation, core, feature, presentation), and sets the boundaries and ownership for that body of work. The skill does not break down epics into implementation tasks or user stories; instead, it prepares the groundwork for subsequent story creation.

This skill enforces strict separation between defining the scope at the module level (epics) and breaking work further into actionable stories. By using well-defined architectural boundaries, it ensures clarity in responsibility, risk tracking, and traceability for the game development process. The output consists of structured documentation files placed within the project’s production/epics/ directory.

Why Use It

The process of building a robust game, especially with a modular architecture, requires clear definition of what each module is, why it exists, and who is responsible for it. The Create Epics skill offers several key benefits:

• Consistent Scope Definition: By mapping each epic to a single architectural module, teams avoid scope creep and maintain clear boundaries.
• Traceability: Epics reference governing Architectural Decision Records (ADRs), engine risks, and any requirements not covered elsewhere.
• Ownership Clarity: Each epic clarifies architectural responsibility, improving accountability.
• Preparedness for Implementation: Epics act as a bridge between high-level design and actionable development tasks, which are created later via stories.
• Layered Development: The skill enforces a disciplined approach, only allowing epics for feature layers once core layers are stable, thereby reducing rework caused by evolving designs.

How to Use It

Invocation Syntax

The skill is invoked using the following format:

/create-epics [system-name | layer: foundation|core|feature|presentation | all] [--review full|lean|solo]

• system-name: Name of the architectural module or system.
• layer: Specify the architecture layer (foundation, core, feature, presentation).
• all: Generate epics for all layers.
• --review: (Optional) Specify review mode (full, lean, or solo).

Argument Parsing and Review Mode The skill determines the review mode in this priority order:

1. If --review is explicitly provided, use that value.
2. If not, read from production/review-mode.txt.
3. If neither exists, default to lean.

Example Suppose you want to generate epics for the core layer with a full review:

/create-epics layer:core --review full

Skill Workflow

1. Preconditions: Ensure /create-control-manifest and /architecture-review have successfully passed.
2. Execution: For each architectural module within the specified layer, the skill will:
   • Create a directory: production/epics/[epic-slug]/
   • Generate an EPIC.md file with:
     • Epic name and description
     • Scope definition
     • Governing ADRs
     • Engine risk assessment
     • Untraced requirements
     • Module ownership
   • Update or create production/epics/index.md to provide an overview of all active epics.

Sample EPIC.md Structure

## [Epic Name]

## Description
Brief overview of the architectural module’s purpose and boundaries.

## Scope
- List of included responsibilities
- Explicit exclusions

## Governing ADRs
- ADR-001: Entity-Component System Design
- ADR-003: Serialization Strategy

## Engine Risk
- [Describe any engine-specific risks or uncertainties]

## Untraced Requirements
- [List requirements not covered in GDDs or architecture docs]

## Ownership
- [Team/individual responsible for this module]

Post-Epic Workflow After each epic is created, run:

/create-stories [epic-slug]

This breaks the epic into actionable development stories.

When to Use It

Use the Create Epics skill under these conditions:

• After the control manifest and architecture review have passed, confirming the design is ready for module breakdown.
• Once you are ready to define the scope and ownership for a specific architecture layer or system.
• When the foundation and core layers are stable, proceed to feature and presentation layers. Do not create epics for dependent layers prematurely, as upstream changes can invalidate designs.

Important Notes

• Strict Layer Order: Only create epics for higher layers (feature, presentation) after lower layers (foundation, core) are nearly complete.
• No Story Breakdown: This skill does not create implementation stories-run /create-stories after each epic is defined.
• Review Modes: Choose the review mode appropriate for your workflow. Use full for comprehensive review, lean for quicker iteration, or solo for individual use.
• Traceability: Ensure that each epic captures all untraced requirements and references relevant ADRs for architectural decisions.
• Documentation Output: All output files are written to production/epics/, maintaining project documentation hygiene.

By using the Create Epics skill as described, teams ensure a disciplined, traceable, and modular approach to game architecture, setting the stage for efficient and accountable development.