# Create Stories > Divide un epic en historias implementables. Lee la epic, su GDD, las ADR que la rigen y el manifiesto de control; cada historia incluye el TR-ID, la guía de ADR y la ruta de evidencia. Ejecutar tras /create-epics. Fuente: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/create-stories Markdown: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/create-stories.md Repositorio: https://github.com/Donchitos/Claude-Code-Game-Studios Autor: Donchitos Licencia: MIT Actualizado: hace 3 meses Coste de contexto: 67 tok instalada, 3.6k tok al activarse, 3.6k tok con todos los archivos del bundle Bundle: 1 archivo, 14 KB Permisos que pide: read, glob, grep, write, task, askuserquestion ## Instalación Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina. ```bash # Claude Code npx -y skills add Donchitos/Claude-Code-Game-Studios --skill create-stories --agent claude-code # Cursor npx -y skills add Donchitos/Claude-Code-Game-Studios --skill create-stories --agent cursor # Codex npx -y skills add Donchitos/Claude-Code-Game-Studios --skill create-stories --agent codex # Gemini CLI npx -y skills add Donchitos/Claude-Code-Game-Studios --skill create-stories --agent gemini # Windsurf npx -y skills add Donchitos/Claude-Code-Game-Studios --skill create-stories --agent windsurf # Cline npx -y skills add Donchitos/Claude-Code-Game-Studios --skill create-stories --agent cline ``` ## Qué hace - Breaks one epic into implementable story files, each traceable to a GDD requirement and ADR decision - Classifies each story by type (Logic, Integration, Visual/Feel, UI, Config/Data) - Runs a QA lead story-readiness gate and generates concrete test case specs per acceptance criterion - Writes story-NNN files and updates the epic's EPIC.md and index.md with the new story table - Blocks if referenced ADR files are missing or flags stories against Proposed ADRs as Blocked ## Cuándo usarla - Después de ejecutar /create-epics para un epic dado, uno por uno - Antes de /story-readiness y /dev-story, para obtener historias implementables y trazables ## Qué la activa - "/create-stories combat" - "/create-stories production/epics/combat/EPIC.md" - "Divide el epic de combate en historias implementables" - "Genera las historias para el sistema de inventario tras crear el epic" ## Antes de instalar - Requiere un EPIC.md con ADRs referenciados, la GDD del epic, control-manifest.md y tr-registry.yaml. - writes to your files ## Archivos - SKILL.md — 14 KB ## SKILL.md Reproducido tal cual desde Donchitos/Claude-Code-Game-Studios bajo MIT. Esta sección es el documento original y está en inglés. # Create Stories A story is a single implementable behaviour — small enough to complete in one focused session, self-contained, and fully traceable to a GDD requirement and an ADR decision. Stories are what developers pick up. Epics are what architects define. **Run this skill per epic**, not per layer. Run it for Foundation epics first, then Core, and so on — matching the dependency order. **Output:** `production/epics/[epic-slug]/story-NNN-[slug].md` files **Previous step:** `/create-epics [system]` **Next step after stories exist:** `/story-readiness [story-path]` then `/dev-story [story-path]` --- ## 1. Parse Argument Extract `--review [full|lean|solo]` if present and store as the review mode override for this run. If not provided, read `production/review-mode.txt` (default `lean` if missing). This resolved mode applies to all gate spawns in this skill — apply the check pattern from `.claude/docs/director-gates.md` before every gate invocation. - `/create-stories [epic-slug]` — e.g. `/create-stories combat` - `/create-stories production/epics/combat/EPIC.md` — full path also accepted - No argument — ask: "Which epic would you like to break into stories?" Glob `production/epics/*/EPIC.md` and list available epics with their status. --- ## 2. Load Everything for This Epic Read in full: - `production/epics/[epic-slug]/EPIC.md` — epic overview, governing ADRs, GDD requirements table - The epic's GDD (`design/gdd/[filename].md`) — read all 8 sections, especially Acceptance Criteria, Formulas, and Edge Cases - All governing ADRs listed in the epic — read the Decision, Implementation Guidelines, Engine Compatibility, and Engine Notes sections - `docs/architecture/control-manifest.md` — extract rules for this epic's layer; note the Manifest Version date from the header - `docs/architecture/tr-registry.yaml` — load all TR-IDs for this system **ADR existence validation**: After reading the governing ADRs list from the epic, confirm each ADR file exists on disk. If any ADR file cannot be found, **stop immediately** before decomposing any story: > "Epic references [ADR-NNNN: title] but `docs/architecture/[adr-file].md` was not found. > Check the filename in the epic's Governing ADRs list, or run `/architecture-decision` > to create it. Cannot create stories until all referenced ADR files are present." Do not proceed to Step 3 until all referenced ADR files are confirmed present. Report: "Loaded epic [name], GDD [filename], [N] governing ADRs (all confirmed present), control manifest v[date]." --- ## 3. Classify Stories by Type **Story Type Classification** — assign each story a type based on its acceptance criteria: | Story Type | Assign when criteria reference... | |---|---| | **Logic** | Formulas, numerical thresholds, state transitions, AI decisions, calculations | | **Integration** | Two or more systems interacting, signals crossing boundaries, save/load round-trips | | **Visual/Feel** | Animation behaviour, VFX, "feels responsive", timing, screen shake, audio sync | | **UI** | Menus, HUD elements, buttons, screens, dialogue boxes, tooltips | | **Config/Data** | Balance tuning values, data file changes only — no new code logic | Mixed stories: assign the type that carries the highest implementation risk. The type determines what test evidence is required before `/story-done` can close the story. --- ## 4. Decompose the GDD into Stories For each GDD acceptance criterion: 1. Group related criteria that require the same core implementation 2. Each group = one story 3. Order stories: foundational behaviour first, edge cases last, UI last **Story sizing rule:** one story = one focused session (~2-4 hours). If a group of criteria would take longer, split into two stories. For each story, determine: - **GDD requirement**: which acceptance criterion(ia) does this satisfy? - **TR-ID**: look up in `tr-registry.yaml`. Use the stable ID. If no match, use `TR-[system]-???` and warn. - **Governing ADR**: which ADR governs how to implement this? - `Status: Accepted` → embed normally - `Status: Proposed` → set story `Status: Blocked` with note: "BLOCKED: ADR-NNNN is Proposed — run `/architecture-decision` to advance it" - **Multiple ADRs apply**: List all governing ADRs in the story's `Governing ADRs:` field. Designate the one most directly controlling the implementation pattern as primary (first in the list). Others are listed as secondary references. - **No ADR applies at all**: Write `ADR: N/A — [brief reason, e.g. "pure data configuration, no architectural pattern required"]` in the story's ADR field. Do NOT leave the field blank — a blank ADR field means "not checked", not "not applicable". - **Story Type**: from Step 3 classification - **Engine risk**: from the ADR's Knowledge Risk field --- ## 4b. QA Lead Story Readiness Gate **Review mode check** — apply before spawning QL-STORY-READY: - `solo` → skip. Note: "QL-STORY-READY skipped — Solo mode." Proceed to Step 5 (present stories for review). - `lean` → skip (not a PHASE-GATE). Note: "QL-STORY-READY skipped — Lean mode." Proceed to Step 5 (present stories for review). - `full` → spawn as normal. After decomposing all stories (Step 4 complete) but before presenting them for write approval, spawn `qa-lead` via Task using gate **QL-STORY-READY** (`.claude/docs/director-gates.md`). Pass: the full story list with acceptance criteria, story types, and TR-IDs; the epic's GDD acceptance criteria for reference. Present the QA lead's assessment. For each story flagged as GAPS or INADEQUATE, revise the acceptance criteria before proceeding — stories with untestable criteria cannot be implemented correctly. Once all stories reach ADEQUATE, proceed. **Before generating test specs**: Glob `production/qa/qa-plan-*.md` for the most recently modified file. If found, read it and check whether it contains test case specifications for the stories in this epic (look for story titles or slugs in the plan's Automated Tests Required section). If matching specs exist: - Use `AskUserQuestion`: - Prompt: "A QA plan exists at [path] with test specs for some of these stories. How do you want to proceed?" - Options: - `Use existing specs from the QA plan — embed them into the story files (Recommended)` - `Ask qa-lead to generate fresh specs — override the QA plan` - `Skip test spec generation — I'll fill in ## QA Test Cases manually` - If "Use existing specs": extract the test case specs from the qa-plan for each matching story and embed them directly into the `## QA Test Cases` section. No qa-lead spawn needed for those stories. Only spawn qa-lead for stories with no coverage in the qa-plan. - If "Generate fresh": proceed with the qa-lead spawn below as normal. - If "Skip": leave `## QA Test Cases` with a placeholder: `*Test cases not yet defined — run /qa-plan to generate them.*` **After ADEQUATE** (or after qa-plan import): for every Logic and Integration story, ask the qa-lead to produce concrete test case specifications — one per acceptance criterion — in this format: ``` Test: [criterion text] Given: [precondition] When: [action] Then: [expected result / assertion] Edge cases: [boundary values or failure states to test] ``` For Visual/Feel and UI stories, produce manual verification steps instead: ``` Manual check: [criterion text] Setup: [how to reach the state] Verify: [what to look for] Pass condition: [unambiguous pass description] ``` These test case specs are embedded directly into each story's `## QA Test Cases` section. The developer implements against these cases. The programmer does not write tests from scratch — QA has already defined what "done" looks like. --- ## 5. Present Stories for Review Before writing any files, present the full story list: ``` ## Stories for Epic: [name] Story 001: [title] — Logic — ADR-NNNN Covers: TR-[system]-001 ([1-line summary of requirement]) Test required: tests/unit/[system]/[slug]_test.[ext] Story 002: [title] — Integration — ADR-MMMM Covers: TR-[system]-002, TR-[system]-003 Test required: tests/integration/[system]/[slug]_test.[ext] Story 003: [title] — Visual/Feel — ADR-NNNN Covers: TR-[system]-004 Evidence required: production/qa/evidence/[slug]-evidence.md [N stories total: N Logic, N Integration, N Visual/Feel, N UI, N Config/Data] ``` Use `AskUserQuestion`: - Prompt: "May I write these [N] stories to `production/epics/[epic-slug]/`?" - Options: `[A] Yes — write all [N] stories` / `[B] Not yet — I want to review or adjust first` --- ## 6. Write Story Files For each story, write `production/epics/[epic-slug]/story-[NNN]-[slug].md`: ```markdown # Story [NNN]: [title] > **Epic**: [epic name] > **Status**: Ready > **Layer**: [Foundation / Core / Feature / Presentation] > **Type**: [Logic | Integration | Visual/Feel | UI | Config/Data] > **Estimate**: [hours or t-shirt size — fill before sprint planning] > **Manifest Version**: [date from control-manifest.md header] > **Last Updated**: [set by /dev-story when implementation begins] ## Context **GDD**: `design/gdd/[filename].md` **Requirement**: `TR-[system]-NNN` *(Requirement text lives in `docs/architecture/tr-registry.yaml` — read fresh at review time)* **ADR Governing Implementation**: [ADR-NNNN: title] **ADR Decision Summary**: [1-2 sentence summary of what the ADR decided] **Engine**: [name + version] | **Risk**: [LOW / MEDIUM / HIGH] **Engine Notes**: [from ADR Engine Compatibility section — post-cutoff APIs, verification required] **Control Manifest Rules (this layer)**: - Required: [relevant required pattern] - Forbidden: [relevant forbidden pattern] - Guardrail: [relevant performance guardrail] --- ## Acceptance Criteria *From GDD `design/gdd/[filename].md`, scoped to this story:* - [ ] [criterion 1 — directly from GDD] - [ ] [criterion 2] - [ ] [performance criterion if applicable] --- ## Implementation Notes *Derived from ADR-NNNN Implementation Guidelines:* [Specific, actionable guidance from the ADR. Do not paraphrase in ways that change meaning. This is what the programmer reads instead of the ADR.] --- ## Out of Scope *Handled by neighbouring stories — do not implement here:* - [Story NNN+1]: [what it handles] --- ## QA Test Cases *Written by qa-lead at story creation. The developer implements against these — do not invent new test cases during implementation.* **[For Logic / Integration stories — automated test specs]:** - **AC-1**: [criterion text] - Given: [precondition] - When: [action] - Then: [assertion] - Edge cases: [boundary values / failure states] **[For Visual/Feel / UI stories — manual verification steps]:** - **AC-1**: [criterion text] - Setup: [how to reach the state] - Verify: [what to look for] - Pass condition: [unambiguous pass description] --- ## Test Evidence **Story Type**: [type] **Required evidence**: - Logic: `tests/unit/[system]/[story-slug]_test.[ext]` — must exist and pass - Integration: `tests/integration/[system]/[story-slug]_test.[ext]` OR playtest doc - Visual/Feel: `production/qa/evidence/[story-slug]-evidence.md` + sign-off - UI: `production/qa/evidence/[story-slug]-evidence.md` or interaction test - Config/Data: smoke check pass (`production/qa/smoke-*.md`) **Status**: [ ] Not yet created --- ## Dependencies - Depends on: [Story NNN-1 must be DONE, or "None"] - Unlocks: [Story NNN+1, or "None"] ``` ### Also update `production/epics/[epic-slug]/EPIC.md` Replace the "Stories: Not yet created" line with a populated table: ```markdown ## Stories | # | Story | Type | Status | ADR | |---|-------|------|--------|-----| | 001 | [title] | Logic | Ready | ADR-NNNN | | 002 | [title] | Integration | Ready | ADR-MMMM | ``` ### Also update `production/epics/index.md` Find the row in the index table matching this epic (by epic name or slug). Update its `Stories` column from `Not yet created` to `[N] stories` (where N is the count just written). If the index file does not exist, skip silently. --- ## 7. After Writing Use `AskUserQuestion` to close with context-aware next steps: Check: - Are there other epics in `production/epics/` without stories yet? List them. - Is this the last epic? If so, include `/sprint-plan` as an option. Widget: - Prompt: "[N] stories written to `production/epics/[epic-slug]/`. What next?" - Options (include all that apply): - `[A] Start implementing — run /story-readiness [first-story-path]` (Recommended) - `[B] Create stories for [next-epic-slug] — run /create-stories [slug]` (only if other epics have no stories yet) - `[C] Plan the sprint — run /sprint-plan new` (only if all epics have stories) - `[D] Stop here for this session` Note in output: "Work through stories in order — each story's `Depends on:` field tells you what must be DONE before you can start it." --- ## Collaborative Protocol 1. **Read before presenting** — load all inputs silently before showing the story list 2. **Ask once** — present all stories for the epic in one summary, not one at a time 3. **Warn on blocked stories** — flag any story with a Proposed ADR before writing 4. **Ask before writing** — get approval for the full story set before writing files 5. **No invention** — acceptance criteria come from GDDs, implementation notes from ADRs, rules from the manifest 6. **Never start implementation** — this skill stops at the story file level After writing (or declining): - **Verdict: COMPLETE** — [N] stories written to `production/epics/[epic-slug]/`. Run `/story-readiness` → `/dev-story` to begin implementation. - **Verdict: BLOCKED** — user declined. No story files written. ## Dónde encaja - Categoría: [Productividad](https://skillsagentes.com/categorias/productividad.md) — Planificación, toma de notas y automatización de flujos personales. - Creador: [Donchitos](https://skillsagentes.com/creators/donchitos.md) — 73 skills en el directorio - [Todas las skills](https://skillsagentes.com/skills.md) - [Ranking de instalaciones](https://skillsagentes.com/ranking.md) ## Otras skills del mismo repositorio - [Team Qa](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/team-qa.md): Orquesta al equipo de QA (qa-lead y qa-tester) para producir un paquete completo de QA: plan de pruebas, smoke check, casos de prueba, ejecución manual y reporte de sign-off. - [Consistency Check](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/consistency-check.md): Compara todos los GDDs contra el registro de entidades para detectar inconsistencias entre documentos: mismo stat, ítem o fórmula con valores distintos, usando un enfoque grep-first. - [Create Architecture](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/create-architecture.md): Redacción guiada, sección por sección, del documento de arquitectura maestro del juego, consciente de la versión del motor y de sus posibles brechas de conocimiento. - [Day One Patch](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/day-one-patch.md): Prepara un patch day-one para el lanzamiento de un juego: define alcance, prioriza, implementa y valida con un QA gate ligero, como un mini-sprint con plan de rollback. - [Hotfix](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/hotfix.md): Flujo de arreglo urgente que se salta el proceso normal de sprint pero deja rastro de auditoría completo: crea rama hotfix, registra aprobaciones y asegura el backport correcto. --- Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)