### Create Stories
Works with
description: "Break a single epic into implementable story files. Reads the epic, its GDD, governing ADRs, and control manifest. Each story embeds its GDD requirement TR-ID, ADR guidance, acceptance c
argument-hint: "[epic-slug | epic-path] [--review full|lean|solo]"
allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versioncreate-storiesExecute the skills CLI command in your project's root directory to begin installation:
Fetches create-stories from Donchitos/Claude-Code-Game-Studios and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate create-stories. Access via /create-stories in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
0
total installs
0
this week
10.7K
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
10.7K
stars
| name | create-stories |
| description | "Break a single epic into implementable story files. Reads the epic, its GDD, governing ADRs, and control manifest. Each story embeds its GDD requirement TR-ID, ADR guidance, acceptance criteria, story type, and test evidence path. Run after /create-epics for each epic." |
| argument-hint | "[epic-slug | epic-path] [--review full|lean|solo]" |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Write, Task, AskUserQuestion |
| agent | lead-programmer |
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]
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 full 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 acceptedproduction/epics/*/EPIC.md and list available epics with their status.Read in full:
production/epics/[epic-slug]/EPIC.md — epic overview, governing ADRs, GDD requirements tabledesign/gdd/[filename].md) — read all 8 sections, especially Acceptance Criteria, Formulas, and Edge Casesdocs/architecture/control-manifest.md — extract rules for this epic's layer; note the Manifest Version date from the headerdocs/architecture/tr-registry.yaml — load all TR-IDs for this systemADR 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].mdwas not found. Check the filename in the epic's Governing ADRs list, or run/architecture-decisionto 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]."
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.
For each GDD acceptance criterion:
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:
tr-registry.yaml. Use the stable ID. If no match, use TR-[system]-??? and warn.Status: Accepted → embed normallyStatus: Proposed → set story Status: Blocked with note: "BLOCKED: ADR-NNNN is Proposed — run /architecture-decision to advance it"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.
After ADEQUATE: 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.
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:
production/epics/[epic-slug]/?"[A] Yes — write all [N] stories / [B] Not yet — I want to review or adjust firstFor each story, write production/epics/[epic-slug]/story-[NNN]-[slug].md:
# Story [NNN]: [title]
> **Epic**: [epic name]
> **Status**: Ready
> **Layer**: [Foundation / Core / Feature / Presentation]
> **Type**: [Logic | Integration | Visual/Feel | UI | Config/Data]
> **Manifest Version**: [date from control-manifest.md header]
## 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"]
production/epics/[epic-slug]/EPIC.mdReplace the "Stories: Not yet created" line with a populated table:
## Stories
| # | Story | Type | Status | ADR |
|---|-------|------|--------|-----|
| 001 | [title] | Logic | Ready | ADR-NNNN |
| 002 | [title] | Integration | Ready | ADR-MMMM |
Use AskUserQuestion to close with context-aware next steps:
Check:
production/epics/ without stories yet? List them./sprint-plan as an option.Widget:
production/epics/[epic-slug]/. What next?"[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 (only if all epics have stories)[D] Stop here for this sessionNote in output: "Work through stories in order — each story's Depends on: field tells you what must be DONE before you can start it."
After writing (or declining):
production/epics/[epic-slug]/. Run /story-readiness → /dev-story to begin implementation.Prerequisites
Time Estimate
15-45 minutes depending on use case complexity
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
JuliusBrussee/caveman
JuliusBrussee/caveman
whyashthakker/agent-skills-marketing
JuliusBrussee/caveman
whyashthakker/agent-skills-marketing
vercel-labs/skills
create-stories reduced setup friction for our internal harness; good balance of opinion and flexibility.
Useful defaults in create-stories — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
We added create-stories from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
create-stories has been reliable in day-to-day use. Documentation quality is above average for community skills.
Useful defaults in create-stories — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
create-stories fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
create-stories is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
create-stories is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
Solid pick for teams standardizing on skills: create-stories is focused, and the summary matches what you get after install.
Registry listing for create-stories matched our evaluation — installs cleanly and behaves as described in the markdown.
showing 1-10 of 56