Token导航 LogoToken导航TokenDH.com
开发执行命令github未标认证来源可访问许可证需确认审计通过

create-storiescreate stories 命令行

Agent Skill

create-stories 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

512

周安装

22

GitHub Stars

16,597

下载量

180
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:create-stories(create stories 命令行)
来源仓库:https://github.com/donchitos/claude-code-game-studios
仓库路径:skills/create-stories
安装命令:
npx skills add https://github.com/donchitos/claude-code-game-studios --skill create-stories
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/donchitos/claude-code-game-studios --skill create-stories

简介

create-stories 用于将游戏设计文档拆解为可执行的小型行为单元故事卡。

  • 适用于 Codex、Claude、Cursor、Gemini CLI 等宿主环境,适合敏捷开发与任务追踪场景。
  • 每个故事卡对应一个 GDD 需求与 ADR 决策,确保可追溯性与聚焦实现。
  • 安装前请确认权限范围、维护状态及是否会触发 Markdown 文件生成与目录结构变更。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

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 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 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 TypeAssign when criteria reference...
LogicFormulas, numerical thresholds, state transitions, AI decisions, calculations
IntegrationTwo or more systems interacting, signals crossing boundaries, save/load round-trips
Visual/FeelAnimation behaviour, VFX, "feels responsive", timing, screen shake, audio sync
UIMenus, HUD elements, buttons, screens, dialogue boxes, tooltips
Config/DataBalance 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"

  • 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.

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.


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:

# 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"]

Also update production/epics/[epic-slug]/EPIC.md

Replace 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 |

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 (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.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

38.77%
按下载量换算70

Claude

27.33%
按下载量换算49

Cursor

18.1%
按下载量换算33

Gemini CLI

8.86%
按下载量换算16

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/donchitos/claude-code-game-studios --skill create-stories 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills