mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 04:51:46 +00:00
Release v1.0.0 — concept-prototype/vertical-slice split, workflow restructure, polish (#50)
* Add /vertical-slice skill, prototype overhaul, and workflow integration - Add /vertical-slice skill for pre-production validation (Phase 4 gate) - Overhaul /prototype skill with two-mode design: concept prototype (Phase 1) vs vertical slice (Phase 4), with clearer differentiation and higher standards for VS - Update prototyper agent to own both prototype and vertical-slice workflows - Add prototype-report.md and vertical-slice-report.md output templates - Update WORKFLOW-GUIDE, quick-start, skills-reference, agent-coordination-map, and skill-flow-diagrams to fully integrate both skills into the 7-phase pipeline - Remove orphaned empty quick-prototype/ directory Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * sync v1 counts + polish Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add entity inventory flow, relax vertical-slice gate, improve UX authoring prompts - /asset-spec: new Phase 0b entity & screen inventory when no argument and no existing inventory — reads GDDs/art-bible, proposes categorized list, writes design/assets/entity-inventory.md collaboratively - /asset-spec: entity/character target falls back to inline user description when no source doc exists, rather than failing - /gate-check: vertical slice changed from blocking to CONCERNS-only when absent; built-but-broken slice still fails; adds entity inventory as gate artifact - /ux-design: convert inline approval prompts to AskUserQuestion for structured option capture at key authoring decision points - workflow-catalog.yaml: entity-inventory step added to pre-production; UX spec min_count raised to 3; vertical-slice and prototype marked required: false with updated descriptions - .gitignore: exclude marrow/ eval tooling directory Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Add missing AskUserQuestion widgets to 7 skills Audit found 11 decision points across 7 skills where structured option prompts were missing — using plain text, auto-selection, or no gate at all. Skills patched: - create-epics: per-epic approval + producer CONCERNS verdict - sprint-plan: producer CONCERNS verdict with scope/timeline options - milestone-review: AT RISK / OFF TRACK producer verdicts require acknowledgement - retrospective: existing-retro handling converted from plain text [A]/[B] - quick-design: classification confirmation + draft approve/revise/redirect - tech-debt add mode: category (6 options) + effort (S/M/L/XL) structured capture - regression-suite: no-arg mode selection instead of silent auto-detect - hotfix: severity confirmation gate before workflow begins Also added AskUserQuestion to allowed-tools headers for retrospective, quick-design, tech-debt, regression-suite, and hotfix. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Prep v1 stable: fix WORKFLOW-GUIDE counts, stale agent names, and skill model fields - WORKFLOW-GUIDE.md: correct agent count (48→49), skill count (66/68→73), add 6 missing skills to Appendix B, fix Creative category count (2→4), replace 3 non-existent agent names with correct ue-*/unity-* specialists, add missing godot-csharp/gdextension specialists to hierarchy, fix production/stories/ paths → production/epics/ - coordination-rules.md: replace "not yet used" with opt-in env var note - quick-start.md: rename duplicate "Validate the concept" label → "Prototype the mechanic" - skill-flow-diagrams.md: remove duplicate legacy UX pipeline section - All 62 skills missing model: field now have explicit model: sonnet Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: comprehensive skill audit — consistency, UX, and flow gaps Two-pass audit fixing ~35 bugs across 41 files. Pre-production flow: - Brainstorm next-steps split into Path A (design-first) and Path B (prototype-first) — eliminates "prototype after architecture" confusion - /architecture-review added to pre-production flow in brainstorm and create-architecture handoffs - gate-check traceability check corrected to requirements-traceability.md - dev-story TR registry error now points to /architecture-review (not /create-epics) - start now writes production/stage.txt on first onboarding AskUserQuestion gaps filled: - balance-check, code-review, hotfix, day-one-patch, consistency-check all gain closing widgets and/or missing allowed-tools declarations - hotfix git branch creation now requires user confirmation - sprint-plan review-mode setup moved to Phase 0 (before gates run) - team-combat gains architecture→implementation approval gate - design-review APPROVED path consolidated from 3 widgets to 1 multiSelect All 9 team-* skills: - Phase 0 review-mode resolution added (solo/lean/full now respected) - team-audio output path fixed (design/gdd/ → design/audio/) - team-level final doc compilation delegated to level-designer subagent - team-narrative localization-lead added to composition list - team-qa sprint path fixed (flat files, not directories) - team-release NO-GO override captures written justification - team-live-ops Cancel verdict now explicitly BLOCKED Other fixes: - Art bible path standardized to design/art/art-bible.md (3 wrong refs) - AD-PHASE-GATE added to lean-mode skip list in director-gates.md - design-system duplicate 5d heading fixed; skeleton decline path added; mandatory agent spawns now respect review mode - story-readiness acceptance criteria thresholds now type-aware - create-stories gains multi-ADR and no-ADR handling guidance - consistency-check creates docs/consistency-failures.md on first run - retrospective frontmatter bash injection replaced with explicit Bash call - smoke-check ls -t gains PowerShell fallback - Conventional Commits format documented in coding-standards.md - gate-check: ADR acceptance gate, QA plan check, chain-of-verification tool-action requirement all added Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: expose --review flag in argument-hints for all team-* skills All 9 team-* skills already implement Phase 0 review-mode resolution internally (full/lean/solo), but none advertised [--review full|lean|solo] in their argument-hint. Users had no way to discover the per-run override. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add SECURITY.md with coordinated disclosure policy Defines scope, reporting process (GitHub private vulnerability reporting), contributor security guidelines for hooks/skills/agents, and 90-day coordinated disclosure timeline. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add CONTRIBUTING.md with framework contribution guidelines Covers what PRs are welcome, skill/hook/agent technical requirements, the collaborative principle, testing expectations, commit format, and platform compatibility requirements. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add v1.0.0-beta → v1.0 upgrade section to UPGRADING.md Documents the 17 commits since the beta tag: new /vertical-slice gate, entity inventory flow in /map-systems, AskUserQuestion widgets across 7 skills, --review flag exposure on team-* skills, bug fixes (#21, #36, #42, #43, #45), and the new CONTRIBUTING.md and SECURITY.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Donchitos
@@ -45,6 +45,7 @@
|
||||
|
||||
godot-specialist -- Godot 4 lead: GDScript, node/scene, signals, resources
|
||||
godot-gdscript-specialist -- GDScript: static typing, patterns, signals, performance
|
||||
godot-csharp-specialist -- C#: .NET patterns, [Signal] delegates, async, type-safe node access
|
||||
godot-shader-specialist -- Shaders: Godot shading language, visual shaders, VFX
|
||||
godot-gdextension-specialist -- Native: C++/Rust bindings, GDExtension, build systems
|
||||
```
|
||||
@@ -200,16 +201,27 @@ art-dir = art-director
|
||||
10. producer -- Marks release complete
|
||||
```
|
||||
|
||||
### Pattern 8: Rapid Prototype
|
||||
### Pattern 8: Concept Prototype (early — before GDDs)
|
||||
|
||||
```text
|
||||
1. game-designer -- Defines the hypothesis and success criteria
|
||||
2. prototyper -- Scaffolds prototype with /prototype
|
||||
3. prototyper -- Builds minimal implementation (hours, not days)
|
||||
2. prototyper -- Scaffolds concept prototype with /prototype
|
||||
3. prototyper -- Builds minimal implementation (1-3 days)
|
||||
4. game-designer -- Evaluates prototype against criteria
|
||||
5. prototyper -- Documents findings report
|
||||
6. creative-director -- Go/no-go decision on proceeding to production
|
||||
7. producer -- Schedules production work if approved
|
||||
5. prototyper -- Documents findings in REPORT.md
|
||||
6. creative-director -- PROCEED / PIVOT / KILL decision (full mode only)
|
||||
7. game-designer -- Informs GDD writing with prototype learnings if PROCEED
|
||||
```
|
||||
|
||||
### Pattern 8b: Vertical Slice (pre-production — after GDDs and architecture)
|
||||
|
||||
```text
|
||||
1. game-designer -- Confirms slice scope against GDDs
|
||||
2. prototyper -- Builds production-quality end-to-end build with /vertical-slice
|
||||
3. prototyper -- Conducts internal playtest sessions (minimum 1)
|
||||
4. prototyper -- Documents findings in REPORT.md
|
||||
5. creative-director -- Go/no-go decision on proceeding to Production (full mode)
|
||||
6. producer -- Schedules Production epics/sprints if PROCEED
|
||||
```
|
||||
|
||||
### Pattern 9: Live Event / Season Launch
|
||||
|
||||
@@ -37,7 +37,7 @@ domain lead) should delegate to specialists.
|
||||
| `tools-programmer` | Dev tools | Sonnet | Editor extensions, pipeline tools, debug utilities |
|
||||
| `ui-programmer` | UI implementation | Sonnet | UI framework, screens, widgets, data binding |
|
||||
| `technical-artist` | Tech art | Sonnet | Shaders, VFX, optimization, art pipeline tools |
|
||||
| `sound-designer` | Sound design | Haiku | SFX design docs, audio event lists, mixing notes |
|
||||
| `sound-designer` | Sound design | Sonnet | SFX design docs, audio event lists, mixing notes |
|
||||
| `writer` | Dialogue/lore | Sonnet | Dialogue writing, lore entries, item descriptions |
|
||||
| `world-builder` | World/lore design | Sonnet | World rules, faction design, history, geography |
|
||||
| `qa-tester` | Test execution | Haiku | Writing test cases, bug reports, test checklists |
|
||||
@@ -84,5 +84,6 @@ domain lead) should delegate to specialists.
|
||||
| Agent | Subsystem | Model | When to Use |
|
||||
| ---- | ---- | ---- | ---- |
|
||||
| `godot-gdscript-specialist` | GDScript | Sonnet | Static typing, design patterns, signals, coroutines, GDScript performance |
|
||||
| `godot-csharp-specialist` | C# / .NET | Sonnet | .NET patterns, [Signal] delegates, async, nullable types, type-safe node access |
|
||||
| `godot-shader-specialist` | Shaders/Rendering | Sonnet | Godot shading language, visual shaders, particles, post-processing |
|
||||
| `godot-gdextension-specialist` | GDExtension | Sonnet | C++/Rust bindings, native performance, custom nodes, build systems |
|
||||
|
||||
@@ -5,6 +5,7 @@
|
||||
- Gameplay values must be data-driven (external config), never hardcoded
|
||||
- All public methods must be unit-testable (dependency injection over singletons)
|
||||
- Commits must reference the relevant design document or task ID
|
||||
- **Commit messages**: Use Conventional Commits format — `feat:`, `fix:`, `chore:`, `docs:`, `test:`, `refactor:`. Reference the story or task ID in the body (e.g., `Story: EPIC-001-S02`).
|
||||
- **Verification-driven development**: Write tests first when adding gameplay systems.
|
||||
For UI changes, verify with screenshots. Compare expected output to actual output
|
||||
before marking work complete. Every implementation should have a way to prove it works.
|
||||
|
||||
@@ -61,7 +61,7 @@ Requires `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` environment variable.
|
||||
- The task fits in a single session's context (use subagents instead)
|
||||
- Cost is a concern — each team member burns tokens independently
|
||||
|
||||
**Current status**: Not yet used in this project. Document usage here when first adopted.
|
||||
**Current status**: Opt-in via `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`. Document first usage here when adopted.
|
||||
|
||||
## Parallel Task Protocol
|
||||
|
||||
|
||||
@@ -53,11 +53,11 @@ Examples:
|
||||
Before spawning gate [GATE-ID]:
|
||||
1. If skill was called with --review [mode], use that
|
||||
2. Else read production/review-mode.txt
|
||||
3. Else default to full
|
||||
3. Else default to lean
|
||||
|
||||
Apply the resolved mode:
|
||||
- solo → skip all gates. Note: "[GATE-ID] skipped — Solo mode"
|
||||
- lean → skip unless this is a PHASE-GATE (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE)
|
||||
- lean → skip unless this is a PHASE-GATE (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
|
||||
Note: "[GATE-ID] skipped — Lean mode"
|
||||
- full → spawn as normal
|
||||
```
|
||||
@@ -744,7 +744,7 @@ authored, or when a design decision has narrative implications
|
||||
introduced, or when a tech art decision affects visual style
|
||||
|
||||
**Context to pass**:
|
||||
- Art bible path (if exists at `design/art-bible.md`)
|
||||
- Art bible path (if exists at `design/art/art-bible.md`)
|
||||
- The specific asset type, style decision, or visual direction being reviewed
|
||||
- Reference images or style descriptions
|
||||
- Platform and performance constraints
|
||||
@@ -786,7 +786,7 @@ When a new gate is needed for a new skill or workflow:
|
||||
|
||||
1. Assign a gate ID: `[DIRECTOR-PREFIX]-[DESCRIPTIVE-SLUG]`
|
||||
- Prefixes: `CD-` `TD-` `PR-` `LP-` `QL-` `ND-` `AD-`
|
||||
- Add new prefixes for new agents: `AudioDirector` → `AU-`, `UX` → `UX-`
|
||||
- Add new prefixes for new agents: `audio-director` → `AU-`, `ux-designer` → `UX-`
|
||||
2. Add the gate under the appropriate director section with all five fields:
|
||||
Trigger, Context to pass, Prompt, Verdicts, and any special handling notes
|
||||
3. Reference it in skills by ID only — never copy the prompt text into the skill
|
||||
@@ -801,6 +801,6 @@ When a new gate is needed for a new skill or workflow:
|
||||
| **Systems Design** | TD-SYSTEM-BOUNDARY, CD-SYSTEMS, PR-SCOPE, CD-GDD-ALIGN (per GDD) | ND-CONSISTENCY, AD-VISUAL |
|
||||
| **Technical Setup** | TD-ARCHITECTURE, TD-ADR (per ADR), LP-FEASIBILITY, AD-ART-BIBLE | TD-ENGINE-RISK |
|
||||
| **Pre-Production** | PR-EPIC, QL-STORY-READY (per story), PR-SPRINT, all four PHASE-GATEs (via gate-check) | CD-PLAYTEST |
|
||||
| **Production** | LP-CODE-REVIEW (per story), QL-STORY-READY, PR-SPRINT (per sprint) | PR-MILESTONE, QL-TEST-COVERAGE, AD-VISUAL |
|
||||
| **Production** | LP-CODE-REVIEW (per story), QL-STORY-READY, PR-SPRINT (per sprint), QL-TEST-COVERAGE (per sprint close-out) | PR-MILESTONE, AD-VISUAL |
|
||||
| **Polish** | QL-TEST-COVERAGE, CD-PLAYTEST, PR-MILESTONE | AD-VISUAL |
|
||||
| **Release** | All four PHASE-GATEs (via gate-check) | QL-TEST-COVERAGE |
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
## What Is This?
|
||||
|
||||
This is a complete Claude Code agent architecture for game development. It
|
||||
organizes 48 specialized AI agents into a studio hierarchy that mirrors
|
||||
organizes 49 specialized AI agents into a studio hierarchy that mirrors
|
||||
real game development teams, with defined responsibilities, delegation
|
||||
rules, and coordination protocols. It includes engine-specialist agents
|
||||
for Godot, Unity, and Unreal — each with dedicated sub-specialists for
|
||||
@@ -65,6 +65,7 @@ Ask yourself: "What department would handle this in a real studio?"
|
||||
| Manage Addressable assets | `unity-addressables-specialist` |
|
||||
| Build UI Toolkit/UGUI screens | `unity-ui-specialist` |
|
||||
| Write idiomatic GDScript | `godot-gdscript-specialist` |
|
||||
| Write Godot C# code | `godot-csharp-specialist` |
|
||||
| Create Godot shaders | `godot-shader-specialist` |
|
||||
| Build GDExtension modules | `godot-gdextension-specialist` |
|
||||
| Plan live events and seasons | `live-ops-designer` |
|
||||
@@ -86,6 +87,8 @@ Ask yourself: "What department would handle this in a real studio?"
|
||||
| `/quick-design` | Lightweight spec for small changes — tuning, tweaks, minor additions |
|
||||
| `/review-all-gdds` | Cross-GDD consistency and game design theory review |
|
||||
| `/propagate-design-change` | Find ADRs and stories affected by a GDD change |
|
||||
| `/art-bible` | Guided, section-by-section Art Bible authoring — creates visual identity spec before asset production |
|
||||
| `/asset-spec` | Generate per-asset visual specifications and AI generation prompts from GDDs or character profiles |
|
||||
| `/ux-design` | Author UX specs (screen/flow, HUD, interaction patterns) |
|
||||
| `/ux-review` | Validate UX specs for accessibility and GDD alignment |
|
||||
| `/create-architecture` | Master architecture document for the game |
|
||||
@@ -110,6 +113,7 @@ Ask yourself: "What department would handle this in a real studio?"
|
||||
| `/tech-debt` | Scan, track, and prioritize tech debt |
|
||||
| `/gate-check` | Validate phase readiness (PASS/CONCERNS/FAIL) |
|
||||
| `/consistency-check` | Scan all GDDs for cross-document inconsistencies (conflicting stats, names, rules) |
|
||||
| `/security-audit` | Audit for security vulnerabilities: save tampering, cheat vectors, network exploits, data exposure |
|
||||
| `/reverse-document` | Generate design/architecture docs from existing code |
|
||||
| `/milestone-review` | Reviews milestone progress |
|
||||
| `/retrospective` | Runs sprint/milestone retrospective |
|
||||
@@ -121,7 +125,9 @@ Ask yourself: "What department would handle this in a real studio?"
|
||||
| `/changelog` | Generates changelog from git history |
|
||||
| `/patch-notes` | Generate player-facing patch notes |
|
||||
| `/hotfix` | Emergency fix with audit trail |
|
||||
| `/prototype` | Scaffolds a throwaway prototype |
|
||||
| `/day-one-patch` | Prepare a focused day-one patch for known issues discovered after gold master |
|
||||
| `/prototype` | Concept prototype — validate core idea before writing GDDs (Phase 1) |
|
||||
| `/vertical-slice` | Production-quality end-to-end build — validate full game loop (Phase 4) |
|
||||
| `/localize` | Localization scan, extract, validate |
|
||||
| `/team-combat` | Orchestrate full combat team pipeline |
|
||||
| `/team-narrative` | Orchestrate full narrative team pipeline |
|
||||
@@ -142,6 +148,7 @@ Ask yourself: "What department would handle this in a real studio?"
|
||||
| `/test-flakiness` | Detect flaky tests from CI history, flag for quarantine or fix |
|
||||
| `/test-evidence-review` | Quality review of test files and manual evidence — ADEQUATE/INCOMPLETE/MISSING |
|
||||
| `/skill-test` | Validate skill files for compliance and correctness (static / spec / audit) |
|
||||
| `/skill-improve` | Improve a skill using a test-fix-retest loop — diagnose, propose fix, rewrite, verify |
|
||||
|
||||
### 4. Use Templates for New Documents
|
||||
|
||||
@@ -219,9 +226,9 @@ If you already know what you need, jump directly to the relevant path:
|
||||
4. **Decompose into systems** — Run `/map-systems` to map all systems and dependencies
|
||||
5. **Design each system** — Run `/design-system [system-name]` (or `/map-systems next`)
|
||||
to write GDDs in dependency order
|
||||
6. **Test the core loop** — Run `/prototype [core-mechanic]`
|
||||
7. **Playtest it** — Run `/playtest-report` to validate the hypothesis
|
||||
8. **Plan the first sprint** — Run `/sprint-plan new`
|
||||
6. **Prototype the mechanic** — Run `/prototype [core-mechanic]` (1–3 days — before writing GDDs)
|
||||
7. **Design each system** — Run `/design-system [system-name]` to write GDDs, informed by prototype findings
|
||||
8. **Plan the first sprint** — After architecture and `/vertical-slice`, run `/sprint-plan new`
|
||||
9. Start building
|
||||
|
||||
### Path B: "I know what I want to build"
|
||||
@@ -266,8 +273,8 @@ If you have design docs, prototypes, or code already:
|
||||
CLAUDE.md -- Master config (read this first, ~60 lines)
|
||||
.claude/
|
||||
settings.json -- Claude Code hooks and project settings
|
||||
agents/ -- 48 agent definitions (YAML frontmatter)
|
||||
skills/ -- 68 slash command definitions (YAML frontmatter)
|
||||
agents/ -- 49 agent definitions (YAML frontmatter)
|
||||
skills/ -- 73 slash command definitions (YAML frontmatter)
|
||||
hooks/ -- 12 hook scripts (.sh) wired by settings.json
|
||||
rules/ -- 11 path-specific rule files
|
||||
docs/
|
||||
@@ -280,5 +287,5 @@ CLAUDE.md -- Master config (read this first, ~60 lines)
|
||||
workflow-catalog.yaml -- 7-phase pipeline definition (read by /help)
|
||||
setup-requirements.md -- System prerequisites (Git Bash, jq, Python)
|
||||
settings-local-template.md -- Personal settings.local.json guide
|
||||
templates/ -- 37 document templates
|
||||
templates/ -- 41 document templates
|
||||
```
|
||||
|
||||
@@ -15,8 +15,8 @@ you'll lose validation features.
|
||||
|
||||
| Tool | Used By | Purpose | Install |
|
||||
| ---- | ---- | ---- | ---- |
|
||||
| **jq** | Hooks (4 of 8) | JSON parsing in commit/push/asset/agent hooks | See below |
|
||||
| **Python 3** | Hooks (2 of 8) | JSON validation for data files | [python.org](https://www.python.org/) |
|
||||
| **jq** | Hooks (7 of 12) | JSON parsing in commit/push/asset/agent hooks | See below |
|
||||
| **Python 3** | Hooks (2 of 12) | JSON validation for data files | [python.org](https://www.python.org/) |
|
||||
| **Bash** | All hooks | Shell script execution | Included with Git for Windows |
|
||||
|
||||
### Installing jq
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Available Skills (Slash Commands)
|
||||
|
||||
68 slash commands organized by phase. Type `/` in Claude Code to access any of them.
|
||||
73 slash commands organized by phase. Type `/` in Claude Code to access any of them.
|
||||
|
||||
## Onboarding & Navigation
|
||||
|
||||
@@ -23,6 +23,14 @@
|
||||
| `/review-all-gdds` | Cross-GDD consistency and game design holism review across all design docs |
|
||||
| `/propagate-design-change` | When a GDD is revised, find affected ADRs and produce an impact report |
|
||||
|
||||
## Art & Assets
|
||||
|
||||
| Command | Purpose |
|
||||
|---------|---------|
|
||||
| `/art-bible` | Guided, section-by-section Art Bible authoring — creates visual identity spec before asset production begins |
|
||||
| `/asset-spec` | Generate per-asset visual specifications and AI generation prompts from GDDs, level docs, or character profiles |
|
||||
| `/asset-audit` | Audit assets for naming conventions, file size budgets, and pipeline compliance |
|
||||
|
||||
## UX & Interface Design
|
||||
|
||||
| Command | Purpose |
|
||||
@@ -59,13 +67,13 @@
|
||||
| `/design-review` | Review a game design document for completeness and consistency |
|
||||
| `/code-review` | Architectural code review for a file or changeset |
|
||||
| `/balance-check` | Analyze game balance data, formulas, and config — flag outliers |
|
||||
| `/asset-audit` | Audit assets for naming conventions, file size budgets, and pipeline compliance |
|
||||
| `/content-audit` | Audit GDD-specified content counts against implemented content |
|
||||
| `/scope-check` | Analyze feature or sprint scope against original plan, flag scope creep |
|
||||
| `/perf-profile` | Structured performance profiling with bottleneck identification |
|
||||
| `/tech-debt` | Scan, track, prioritize, and report on technical debt |
|
||||
| `/gate-check` | Validate readiness to advance between development phases (PASS/CONCERNS/FAIL) |
|
||||
| `/consistency-check` | Scan all GDDs against the entity registry to detect cross-document inconsistencies (stats, names, rules that contradict each other) |
|
||||
| `/security-audit` | Audit the game for security vulnerabilities: save tampering, cheat vectors, network exploits, data exposure, and input validation gaps |
|
||||
|
||||
## QA & Testing
|
||||
|
||||
@@ -80,6 +88,7 @@
|
||||
| `/test-evidence-review` | Quality review of test files and manual evidence documents |
|
||||
| `/test-flakiness` | Detect non-deterministic (flaky) tests from CI run logs |
|
||||
| `/skill-test` | Validate skill files for structural compliance and behavioral correctness |
|
||||
| `/skill-improve` | Improve a skill using a test-fix-retest loop — diagnose, propose fix, rewrite, verify |
|
||||
|
||||
## Production
|
||||
|
||||
@@ -101,12 +110,14 @@
|
||||
| `/changelog` | Auto-generate changelog from git commits and sprint data |
|
||||
| `/patch-notes` | Generate player-facing patch notes from git history and internal data |
|
||||
| `/hotfix` | Emergency fix workflow with audit trail, bypassing normal sprint process |
|
||||
| `/day-one-patch` | Prepare a focused day-one patch for known issues discovered after gold master but before or at public launch |
|
||||
|
||||
## Creative & Content
|
||||
|
||||
| Command | Purpose |
|
||||
|---------|---------|
|
||||
| `/prototype` | Rapid throwaway prototype to validate a mechanic (relaxed standards, isolated worktree) |
|
||||
| `/prototype` | Concept prototype — throwaway build right after brainstorm to validate core idea (Phase 1) |
|
||||
| `/vertical-slice` | Pre-Production validation — production-quality end-to-end build before committing to Production (Phase 4) |
|
||||
| `/onboard` | Generate contextual onboarding document for a new contributor or agent |
|
||||
| `/localize` | Localization workflow: string extraction, validation, translation readiness |
|
||||
|
||||
|
||||
7
.claude/docs/templates/game-concept.md
vendored
7
.claude/docs/templates/game-concept.md
vendored
@@ -309,8 +309,9 @@ the combat-crafting loop engaging for 30+ minute sessions"]
|
||||
- [ ] Get concept approval from creative-director
|
||||
- [ ] Fill in CLAUDE.md technology stack based on engine choice (`/setup-engine`)
|
||||
- [ ] Create game pillars document (`/design-review` to validate)
|
||||
- [ ] Decompose concept into systems (`/map-systems` — maps dependencies, assigns priorities, guides per-system GDD writing)
|
||||
- [ ] Create first architecture decision record (`/architecture-decision`)
|
||||
- [ ] Prototype core loop (`/prototype [core-mechanic]`)
|
||||
- [ ] **Prototype core idea** (`/prototype [core-mechanic]`) — before writing GDDs, validate the concept is worth designing
|
||||
- [ ] If prototype PROCEEDS: Decompose concept into systems (`/map-systems`)
|
||||
- [ ] Design each system (`/design-system [system-name]`) — use prototype learnings in Tuning Knobs and Formulas sections
|
||||
- [ ] Build vertical slice in Pre-Production (`/vertical-slice`) — validate full game loop before committing to Production
|
||||
- [ ] Validate core loop with playtest (`/playtest-report`)
|
||||
- [ ] Plan first milestone (`/sprint-plan new`)
|
||||
|
||||
2
.claude/docs/templates/hud-design.md
vendored
2
.claude/docs/templates/hud-design.md
vendored
@@ -7,7 +7,7 @@
|
||||
> **Platform Targets**: [All platforms this HUD must work on — e.g., PC, PS5, Xbox Series X, Steam Deck]
|
||||
> **Related GDDs**: [Every system that exposes information through the HUD — e.g., `design/gdd/combat.md`, `design/gdd/progression.md`, `design/gdd/quests.md`]
|
||||
> **Accessibility Tier**: Basic | Standard | Comprehensive | Exemplary
|
||||
> **Style Reference**: [Link to art bible HUD section if it exists — e.g., `design/gdd/art-bible.md § HUD Visual Language`]
|
||||
> **Style Reference**: [Link to art bible HUD section if it exists — e.g., `design/art/art-bible.md § HUD Visual Language`]
|
||||
|
||||
> **Note — Scope boundary**: This document specifies all elements that overlay the
|
||||
> game world during active gameplay — health bars, ammo counters, minimaps, quest
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
> **Engine**: [Godot 4.6 / Unity 6 / Unreal Engine 5]
|
||||
> **UI Framework**: [Godot Control nodes / Unity UI Toolkit / Unreal UMG]
|
||||
> **Related Documents**:
|
||||
> - `docs/art-bible.md` — visual standards (colors, typography, iconography)
|
||||
> - `design/art/art-bible.md` — visual standards (colors, typography, iconography)
|
||||
> - `docs/accessibility-requirements.md` — accessibility commitments per feature
|
||||
> - `docs/ux/ux-spec-[screen].md` — individual screen specs that reference patterns
|
||||
|
||||
|
||||
114
.claude/docs/templates/prototype-report.md
vendored
Normal file
114
.claude/docs/templates/prototype-report.md
vendored
Normal file
@@ -0,0 +1,114 @@
|
||||
# Concept Prototype Report: [Concept Name]
|
||||
|
||||
> **Date**: [YYYY-MM-DD]
|
||||
> **Prototype Path**: [HTML / Engine / Paper]
|
||||
> **Concept File**: design/gdd/game-concept.md (if exists)
|
||||
|
||||
---
|
||||
|
||||
## Hypothesis
|
||||
|
||||
[The falsifiable hypothesis this prototype set out to test:
|
||||
"If the player [does X], they will feel [Y] — evidenced by [measurable signal Z]."]
|
||||
|
||||
---
|
||||
|
||||
## Riskiest Assumption Tested
|
||||
|
||||
[What was identified as the biggest risk in the concept, and whether it proved out.]
|
||||
|
||||
---
|
||||
|
||||
## Approach
|
||||
|
||||
[What was built, how long it took, what shortcuts were taken deliberately.]
|
||||
|
||||
**Path chosen:** [HTML / Engine / Paper]
|
||||
**Reason for path:** [Why this path was appropriate for this hypothesis]
|
||||
|
||||
**Shortcuts taken (intentional):**
|
||||
- [e.g., hardcoded values, placeholder art, no menus, etc.]
|
||||
|
||||
---
|
||||
|
||||
## Result
|
||||
|
||||
[What actually happened — specific observations, not opinions. Quote playtesters
|
||||
directly where possible.]
|
||||
|
||||
---
|
||||
|
||||
## Metrics
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Path used | [HTML / Engine / Paper] |
|
||||
| Iterations to playable | [N — Engine path only; N/A otherwise] |
|
||||
| Prototype duration | [e.g., 4 hours] |
|
||||
| Playtesters | [N internal / N external] |
|
||||
| Feel assessment | [Specific — "response felt sluggish at 200ms" not "felt bad"] |
|
||||
| Hypothesis verdict | [CONFIRMED / PARTIALLY CONFIRMED / REFUTED] |
|
||||
|
||||
---
|
||||
|
||||
## Recommendation: [PROCEED / PIVOT / KILL]
|
||||
|
||||
[One paragraph explaining the recommendation with evidence from the result above.]
|
||||
|
||||
---
|
||||
|
||||
## If Proceeding
|
||||
|
||||
[What the prototype revealed that should directly inform GDD writing:]
|
||||
|
||||
- **Core tuning values discovered:** [e.g., "jump height of 3.5 units felt best"]
|
||||
- **Assumptions confirmed:** [What the concept doc assumed that proved true]
|
||||
- **Assumptions disproved:** [What the concept doc assumed that proved wrong]
|
||||
- **Emergent mechanics:** [Behaviors that appeared during testing worth formalizing]
|
||||
|
||||
> Note: If HTML path was used and feel is uncertain, consider an engine prototype
|
||||
> targeting feel specifically before committing to GDDs.
|
||||
|
||||
**Next steps:**
|
||||
1. `/design-review design/gdd/game-concept.md`
|
||||
2. `/gate-check`
|
||||
3. `/map-systems`
|
||||
4. `/design-system [mechanic]` (use learnings in Tuning Knobs and Formulas sections)
|
||||
|
||||
---
|
||||
|
||||
## If Pivoting
|
||||
|
||||
[What alternative direction the results suggest — what felt almost right and what
|
||||
to adjust. Be specific about what to change, not just that something needs changing.]
|
||||
|
||||
**Pivot direction:** [What to try differently]
|
||||
**What to keep:** [What worked and should be preserved]
|
||||
**Next step:** `/prototype [revised-concept]`
|
||||
|
||||
---
|
||||
|
||||
## If Killing
|
||||
|
||||
[Why this concept does not work — what specific signal led to this verdict.
|
||||
This report is the deliverable; no further action needed on this concept.]
|
||||
|
||||
**Next step:** `/brainstorm [new-direction]`
|
||||
|
||||
---
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
- **What assumptions were broken by actually building this?**
|
||||
[...]
|
||||
|
||||
- **What surprised us that didn't show up in the brainstorm?**
|
||||
[...]
|
||||
|
||||
- **What would we test differently next time?**
|
||||
[...]
|
||||
|
||||
---
|
||||
|
||||
> *Prototype code location: `prototypes/[concept-name]-concept/`*
|
||||
> *This code is throwaway. Never refactor into production.*
|
||||
33
.claude/docs/templates/sprint-plan.md
vendored
33
.claude/docs/templates/sprint-plan.md
vendored
@@ -1,4 +1,4 @@
|
||||
# Sprint [N] -- [Start Date] to [End Date]
|
||||
# Sprint [N] — [Start Date] to [End Date]
|
||||
|
||||
## Sprint Goal
|
||||
|
||||
@@ -12,14 +12,9 @@
|
||||
|
||||
## Capacity
|
||||
|
||||
| Resource | Available Days | Allocated | Buffer (20%) | Remaining |
|
||||
|----------|---------------|-----------|-------------|-----------|
|
||||
| Programming | | | | |
|
||||
| Design | | | | |
|
||||
| Art | | | | |
|
||||
| Audio | | | | |
|
||||
| QA | | | | |
|
||||
| **Total** | | | | |
|
||||
- **Total days**: [X]
|
||||
- **Buffer (20%)**: [Y days reserved for unplanned work]
|
||||
- **Available**: [Z days]
|
||||
|
||||
## Tasks
|
||||
|
||||
@@ -59,17 +54,13 @@
|
||||
|
||||
## Definition of Done
|
||||
|
||||
- [ ] All Must Have tasks completed and passing acceptance criteria
|
||||
- [ ] All Must Have tasks completed
|
||||
- [ ] All tasks pass acceptance criteria
|
||||
- [ ] QA plan exists (`production/qa/qa-plan-sprint-[N].md`)
|
||||
- [ ] All Logic/Integration stories have passing unit/integration tests
|
||||
- [ ] Smoke check passed (`/smoke-check sprint`)
|
||||
- [ ] QA sign-off report: APPROVED or APPROVED WITH CONDITIONS (`/team-qa sprint`)
|
||||
- [ ] No S1 or S2 bugs in delivered features
|
||||
- [ ] Code reviewed and merged to develop
|
||||
- [ ] Design documents updated for any deviations from spec
|
||||
- [ ] Test cases written and executed for all new features
|
||||
- [ ] Asset naming and format standards met
|
||||
- [ ] Design documents updated for any deviations
|
||||
- [ ] Code reviewed and merged
|
||||
|
||||
## Daily Status Tracking
|
||||
|
||||
| Day | Tasks Completed | Tasks In Progress | Blockers | Notes |
|
||||
|-----|----------------|------------------|----------|-------|
|
||||
| Day 1 | | | | |
|
||||
| Day 2 | | | | |
|
||||
| Day 3 | | | | |
|
||||
|
||||
2
.claude/docs/templates/systems-index.md
vendored
2
.claude/docs/templates/systems-index.md
vendored
@@ -143,4 +143,4 @@ These should be prototyped early regardless of priority tier.]
|
||||
- [ ] Design MVP-tier systems first (use `/design-system [system-name]`)
|
||||
- [ ] Run `/design-review` on each completed GDD
|
||||
- [ ] Run `/gate-check pre-production` when MVP systems are designed
|
||||
- [ ] Prototype the highest-risk system early (`/prototype [system]`)
|
||||
- [ ] Validate the highest-risk systems with `/vertical-slice` before committing to Production
|
||||
|
||||
10
.claude/docs/templates/test-evidence.md
vendored
10
.claude/docs/templates/test-evidence.md
vendored
@@ -65,9 +65,13 @@ If nothing notable: *No significant observations.*
|
||||
|
||||
## Sign-Off
|
||||
|
||||
All three sign-offs are required before the story can be marked COMPLETE via
|
||||
`/story-done`. Visual/Feel stories require the designer or art-lead sign-off.
|
||||
UI stories require the UX lead or designer sign-off.
|
||||
All roles must sign off before the story can be marked COMPLETE via `/story-done`.
|
||||
Visual/Feel stories require the designer or art-lead sign-off. UI stories require
|
||||
the UX lead or designer sign-off.
|
||||
|
||||
**Solo developers**: all sign-offs may be by the same person in each role. The
|
||||
intent is that someone deliberately reviews the evidence before marking complete —
|
||||
not that three separate people must participate.
|
||||
|
||||
| Role | Name | Date | Signature |
|
||||
|------|------|------|-----------|
|
||||
|
||||
24
.claude/docs/templates/test-plan.md
vendored
24
.claude/docs/templates/test-plan.md
vendored
@@ -114,31 +114,9 @@ A story is DONE when ALL of the following are true:
|
||||
|
||||
---
|
||||
|
||||
## Test Results
|
||||
|
||||
*Fill in after testing is complete.*
|
||||
|
||||
| Story | Automated | Manual | Result | Notes |
|
||||
|-------|-----------|--------|--------|-------|
|
||||
| [title] | PASS | — | PASS | |
|
||||
| [title] | — | PASS | PASS | |
|
||||
| [title] | FAIL | — | BLOCKED | [describe failure] |
|
||||
|
||||
---
|
||||
|
||||
## Bugs Found
|
||||
|
||||
| ID | Story | Severity | Description | Status |
|
||||
|----|-------|----------|-------------|--------|
|
||||
| BUG-001 | | S[1-4] | | Open |
|
||||
|
||||
---
|
||||
|
||||
## Sign-Off
|
||||
|
||||
- **QA Tester**: [name] — [date]
|
||||
- **QA Lead**: [name] — [date]
|
||||
- **Sprint Owner**: [name] — [date]
|
||||
*Results and sign-off are tracked in the QA sign-off report generated by `/team-qa` — not in this plan file.*
|
||||
|
||||
*Template: `.claude/docs/templates/test-plan.md`*
|
||||
*Generated by: `/qa-plan` — do not edit this line*
|
||||
|
||||
169
.claude/docs/templates/vertical-slice-report.md
vendored
Normal file
169
.claude/docs/templates/vertical-slice-report.md
vendored
Normal file
@@ -0,0 +1,169 @@
|
||||
# Vertical Slice Report: [Concept Name]
|
||||
|
||||
> **Date**: [YYYY-MM-DD]
|
||||
> **Slice Duration**: [N days]
|
||||
> **Target Scope**: 3–5 minutes of polished, continuous gameplay
|
||||
> **Source GDD**: design/gdd/game-concept.md
|
||||
|
||||
---
|
||||
|
||||
## Validation Question
|
||||
|
||||
[The full game loop question this build was proving — both experience AND feasibility:
|
||||
"Does a player, starting from nothing, experience [core fantasy] within [N] minutes,
|
||||
without developer guidance — and can we build one such loop in [X] days at
|
||||
representative quality?"]
|
||||
|
||||
---
|
||||
|
||||
## Scope Built
|
||||
|
||||
[Systems implemented, art quality level, what was intentionally omitted.]
|
||||
|
||||
**Systems included:**
|
||||
- [System 1]
|
||||
- [System 2]
|
||||
- [...]
|
||||
|
||||
**Art/audio quality level:** [Placeholder / Representative / Near-shipping]
|
||||
**Shortcuts taken deliberately:** [List]
|
||||
**What was cut from original scope:** [List]
|
||||
|
||||
---
|
||||
|
||||
## Build Velocity Log
|
||||
|
||||
[Day-by-day record of what was completed. This is your real production rate data —
|
||||
use it in sprint planning.]
|
||||
|
||||
| Day | Completed |
|
||||
|-----|-----------|
|
||||
| Day 1 | [What was built] |
|
||||
| Day 2 | [What was built] |
|
||||
| Day 3 | [What was built] |
|
||||
| ... | ... |
|
||||
|
||||
**Total elapsed:** [N days] for [scope summary]
|
||||
**Velocity estimate:** [N hours per equivalent scope unit — e.g., "1 day per combat
|
||||
encounter, 0.5 days per UI screen"]
|
||||
|
||||
---
|
||||
|
||||
## Playtest Results
|
||||
|
||||
| Attribute | Value |
|
||||
|-----------|-------|
|
||||
| Total sessions | [N] |
|
||||
| Internal testers | [N] |
|
||||
| External testers | [N — people who had not seen the game, if available] |
|
||||
| Avg session length | [N minutes (target: [N] minutes)] |
|
||||
| Time to first meaningful action | [N seconds (target: [N] seconds)] |
|
||||
|
||||
---
|
||||
|
||||
## Observations
|
||||
|
||||
[Specific, non-opinion observations from playtest sessions. Quote testers where useful.]
|
||||
|
||||
**Where testers succeeded without guidance:**
|
||||
- [...]
|
||||
|
||||
**Where testers were confused or stuck:**
|
||||
- [...]
|
||||
|
||||
**Emotional reactions observed:**
|
||||
- [...]
|
||||
|
||||
---
|
||||
|
||||
## Metrics
|
||||
|
||||
| Metric | Target | Actual |
|
||||
|--------|--------|--------|
|
||||
| Time to first meaningful action | [N sec] | [N sec] |
|
||||
| Session length | [N min] | [N min] |
|
||||
| Critical fun blockers found | 0 | [N] |
|
||||
| Pipeline blockers found | 0 | [N] |
|
||||
| Architecture surprises | 0 | [N] |
|
||||
|
||||
**Feel assessment:** [Specific — "combat feedback weak; no impact sound on hit" not "felt rough"]
|
||||
|
||||
---
|
||||
|
||||
## Recommendation: [PROCEED / PIVOT / KILL]
|
||||
|
||||
[One paragraph with evidence — reference the validation question directly. Did a
|
||||
player experience the core fantasy within the target time, without developer guidance?
|
||||
Can the team build at this quality on the projected schedule?]
|
||||
|
||||
---
|
||||
|
||||
## If Proceeding
|
||||
|
||||
**Production requirements** (what must change from slice to production):
|
||||
- [e.g., "Replace placeholder art with shipped assets"]
|
||||
- [e.g., "Combat system needs 2 more weapon types"]
|
||||
|
||||
**Architecture adjustments needed:**
|
||||
- [ADR to update or create]
|
||||
|
||||
**Sprint velocity estimate based on slice data:**
|
||||
- [e.g., "1 day per enemy type, 2 days per level section, 0.5 days per UI screen"]
|
||||
|
||||
**Scope adjustments from original design:**
|
||||
- [What the slice revealed about the true production scope]
|
||||
|
||||
**Performance targets:** [Confirmed / Revised — list changes if revised]
|
||||
|
||||
**Playtest note:** Run `/playtest-report` to structure additional session data
|
||||
before running `/gate-check pre-production`.
|
||||
|
||||
**Next steps:**
|
||||
1. `/gate-check pre-production` — formally advance to Production
|
||||
2. `/create-epics layer:foundation` — plan Foundation layer epics
|
||||
3. `/create-epics layer:core` — plan Core layer epics
|
||||
4. `/sprint-plan` — use velocity data from this report in the estimate
|
||||
|
||||
---
|
||||
|
||||
## If Pivoting
|
||||
|
||||
[Which GDDs need revision and why — be specific about the failure mode observed.]
|
||||
|
||||
**Systems requiring GDD revision:** [List]
|
||||
**Architecture decisions to revisit:** [List — use `/architecture-decision` to update]
|
||||
**Core loop change needed:** [What specifically to change]
|
||||
|
||||
**Next steps:**
|
||||
1. `/design-system [mechanic]` — revise affected GDDs
|
||||
2. `/architecture-decision [decision]` — address architecture issues
|
||||
3. `/vertical-slice` — re-validate after revisions
|
||||
|
||||
---
|
||||
|
||||
## If Killing
|
||||
|
||||
[Why the full game loop does not work at this quality level. What specifically
|
||||
prevented the player from experiencing the core fantasy. What to do instead.]
|
||||
|
||||
**Next step:** `/brainstorm` to explore a new direction, or `/prototype [new-concept]`
|
||||
to test a different concept cheaply before investing in another vertical slice.
|
||||
|
||||
---
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
- **What assumptions were broken by building to near-production quality?**
|
||||
[...]
|
||||
|
||||
- **What surprised us about the pipeline or architecture?**
|
||||
[...]
|
||||
|
||||
- **What would we change about the slice scope if we ran this again?**
|
||||
[...]
|
||||
|
||||
---
|
||||
|
||||
> *Vertical slice code location: `prototypes/[concept-name]-vertical-slice/`*
|
||||
> *This code is reference material only. Production implementation is written from scratch.*
|
||||
> *Never import or refactor this code into production.*
|
||||
@@ -150,9 +150,17 @@ phases:
|
||||
|
||||
pre-production:
|
||||
label: "Pre-Production"
|
||||
description: "UX specs, asset specs, prototype the core mechanic, define stories, validate fun"
|
||||
description: "Visual entity inventory, UX specs, asset specs, prototype the core mechanic, define stories, validate fun"
|
||||
next_phase: production
|
||||
steps:
|
||||
- id: entity-inventory
|
||||
name: "Visual Entity & Screen Inventory"
|
||||
command: /asset-spec
|
||||
required: false
|
||||
artifact:
|
||||
glob: "design/assets/entity-inventory.md"
|
||||
description: "Enumerate everything the game needs visually: entities (characters, enemies, buildings, environment pieces), UI screens, HUD elements, panels. Run /asset-spec with no arguments to start a collaborative inventory session — brief or detailed based on your responses. Reads GDDs and art bible to propose a starting list; you add, remove, and adjust. Becomes the source of truth for all art and UX work. Not required if the game has very few distinct visual elements."
|
||||
|
||||
- id: asset-spec
|
||||
name: "Asset Specs"
|
||||
command: /asset-spec
|
||||
@@ -160,7 +168,7 @@ phases:
|
||||
repeatable: true
|
||||
artifact:
|
||||
glob: "design/assets/asset-manifest.md"
|
||||
description: "Generate per-asset visual specifications and AI generation prompts from approved GDDs and level docs. Run once per system/level/character."
|
||||
description: "Generate per-asset visual specifications and AI generation prompts. Run once per entity, system, level, or character. If no source doc exists, /asset-spec interviews you inline — no narrative document required."
|
||||
|
||||
- id: ux-design
|
||||
name: "UX Specs (key screens)"
|
||||
@@ -169,8 +177,8 @@ phases:
|
||||
repeatable: true
|
||||
artifact:
|
||||
glob: "design/ux/*.md"
|
||||
min_count: 1
|
||||
description: "Author UX specs for main menu, core gameplay HUD, and interaction patterns. Reads input method and platform from technical-preferences.md."
|
||||
min_count: 3
|
||||
description: "Author UX specs for the screens identified in the entity inventory (or GDDs if no inventory). Minimum required: main menu, core gameplay HUD, pause menu. Add more screens as the inventory identifies them. Reads input method and platform from technical-preferences.md."
|
||||
|
||||
- id: ux-review
|
||||
name: "UX Review"
|
||||
@@ -181,11 +189,11 @@ phases:
|
||||
- id: prototype
|
||||
name: "Prototype"
|
||||
command: /prototype
|
||||
required: true
|
||||
required: false
|
||||
artifact:
|
||||
glob: "prototypes/*/README.md"
|
||||
min_count: 1
|
||||
description: "Build throwaway prototypes in isolated worktree to validate core mechanic"
|
||||
description: "Build a throwaway prototype to validate the core mechanic is fun before committing to full production. Recommended for first-time mechanics or high-risk design decisions. Solo devs with proven concepts may skip."
|
||||
|
||||
- id: create-epics
|
||||
name: "Create Epics"
|
||||
@@ -225,13 +233,13 @@ phases:
|
||||
description: "Plan the first sprint with prioritized stories from epics"
|
||||
|
||||
- id: vertical-slice
|
||||
name: "Vertical Slice (playtested)"
|
||||
command: /playtest-report
|
||||
required: true
|
||||
name: "Vertical Slice"
|
||||
command: /vertical-slice
|
||||
required: false
|
||||
artifact:
|
||||
glob: "production/playtests/*.md"
|
||||
glob: "prototypes/*/REPORT.md"
|
||||
min_count: 1
|
||||
description: "Document vertical slice playtest sessions using /playtest-report. Run at least once here (≥1 session required before Production; ≥3 required before Polish). Each session should cover one complete run-through of the core loop."
|
||||
description: "Build and playtest a vertical slice — a complete end-to-end pass through the core loop. Recommended before committing epics and stories to production. Skipping is a valid solo dev call but increases risk of late-stage design pivots. If built, must be played and documented before advancing."
|
||||
|
||||
production:
|
||||
label: "Production"
|
||||
|
||||
Reference in New Issue
Block a user