Files
Claude-Code-Game-Studios/.claude/skills/start/SKILL.md
Donchitos 984023ddac 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>
2026-05-13 20:15:08 +10:00

246 lines
13 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
name: start
description: "First-time onboarding — asks where you are, then guides you to the right workflow. No assumptions."
argument-hint: "[no arguments]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
model: sonnet
---
# Guided Onboarding
This skill writes one file: `production/review-mode.txt` (review mode config set in Phase 3b).
This skill is the entry point for new users. It does NOT assume you have a game idea, an engine preference, or any prior experience. It asks first, then routes you to the right workflow.
---
## Phase 1: Detect Project State
Before asking anything, silently gather context so you can tailor your guidance. Do NOT show these results unprompted — they inform your recommendations, not the conversation opener.
Check:
- **Engine configured?** Read `.claude/docs/technical-preferences.md`. If the Engine field contains `[TO BE CONFIGURED]`, the engine is not set.
- **Game concept exists?** Check for `design/gdd/game-concept.md`.
- **Source code exists?** Glob for source files in `src/` (`*.gd`, `*.cs`, `*.cpp`, `*.h`, `*.rs`, `*.py`, `*.js`, `*.ts`).
- **Prototypes exist?** Check for subdirectories in `prototypes/`.
- **Design docs exist?** Count markdown files in `design/gdd/`.
- **Production artifacts?** Check for files in `production/sprints/` or `production/milestones/`.
Store these findings internally to validate the user's self-assessment and tailor recommendations.
---
## Phase 2: Ask Where the User Is
This is the first thing the user sees. Use `AskUserQuestion` with these exact options so the user can click rather than type:
- **Prompt**: "Welcome to Claude Code Game Studios! Before I suggest anything, I'd like to understand where you're starting from. Where are you at with your game idea right now?"
- **Options**:
- `A) No idea yet` — I don't have a game concept at all. I want to explore and figure out what to make.
- `B) Vague idea` — I have a rough theme, feeling, or genre in mind (e.g., "something with space" or "a cozy farming game") but nothing concrete.
- `C) Clear concept` — I know the core idea — genre, basic mechanics, maybe a pitch sentence — but haven't formalized it into documents yet.
- `D) Existing work` — I already have design docs, prototypes, code, or significant planning done. I want to organize or continue the work.
Wait for the user's selection. Do not proceed until they respond.
---
## Phase 3: Route Based on Answer
#### If A: No idea yet
The user needs creative exploration before anything else.
1. Acknowledge that starting from zero is completely fine
2. Briefly explain what `/brainstorm` does (guided ideation using professional frameworks — MDA, player psychology, verb-first design). Mention that it has two modes: `/brainstorm open` for fully open exploration, or `/brainstorm [hint]` if they have even a vague theme (e.g., "space", "cozy", "horror").
3. Recommend running `/brainstorm open` as the next step, but invite them to use a hint if something comes to mind
4. Show the recommended path:
**Concept phase:**
- `/brainstorm open` — discover your game concept
- `/setup-engine` — configure the engine (brainstorm will recommend one)
- `/prototype` — throwaway concept build: validate the core idea is fun before designing (13 days)
- `/art-bible` — define visual identity (uses the Visual Identity Anchor brainstorm produces)
- `/map-systems` — decompose the concept into systems
- `/design-system` — author a GDD for each MVP system
- `/review-all-gdds` — cross-system consistency check
- `/gate-check` — validate readiness before architecture work
**Architecture phase:**
- `/create-architecture` — produce the master architecture blueprint and Required ADR list
- `/architecture-decision (×N)` — record key technical decisions, following the Required ADR list
- `/create-control-manifest` — compile decisions into an actionable rules sheet
- `/architecture-review` — validate architecture coverage
**Pre-Production phase:**
- `/ux-design` — author UX specs for key screens (main menu, HUD, core interactions)
- `/vertical-slice` — production-quality end-to-end build to validate the full game loop
- `/playtest-report (×1+)` — document each vertical slice playtest session
- `/create-epics` — map systems to epics
- `/create-stories` — break epics into implementable stories
- `/sprint-plan` — plan the first sprint
**Production phase:** → pick up stories with `/dev-story`
#### If B: Vague idea
1. Ask them to share their vague idea — even a few words is enough
2. Validate the idea as a starting point (don't judge or redirect)
3. Recommend running `/brainstorm [their hint]` to develop it
4. Show the recommended path:
**Concept phase:**
- `/brainstorm [hint]` — develop the idea into a full concept
- `/setup-engine` — configure the engine
- `/prototype` — throwaway concept build: validate the core idea is fun before designing (13 days)
- `/art-bible` — define visual identity (uses the Visual Identity Anchor brainstorm produces)
- `/map-systems` — decompose the concept into systems
- `/design-system` — author a GDD for each MVP system
- `/review-all-gdds` — cross-system consistency check
- `/gate-check` — validate readiness before architecture work
**Architecture phase:**
- `/create-architecture` — produce the master architecture blueprint and Required ADR list
- `/architecture-decision (×N)` — record key technical decisions, following the Required ADR list
- `/create-control-manifest` — compile decisions into an actionable rules sheet
- `/architecture-review` — validate architecture coverage
**Pre-Production phase:**
- `/ux-design` — author UX specs for key screens (main menu, HUD, core interactions)
- `/vertical-slice` — production-quality end-to-end build to validate the full game loop
- `/playtest-report (×1+)` — document each vertical slice playtest session
- `/create-epics` — map systems to epics
- `/create-stories` — break epics into implementable stories
- `/sprint-plan` — plan the first sprint
**Production phase:** → pick up stories with `/dev-story`
#### If C: Clear concept
1. Ask them to describe their concept in one sentence — genre and core mechanic. Use plain text, not AskUserQuestion (it's an open response).
2. Acknowledge the concept, then use `AskUserQuestion` to offer two paths:
- **Prompt**: "How would you like to proceed?"
- **Options**:
- `Formalize it first` — Run `/brainstorm [concept]` to structure it into a proper game concept document
- `Jump straight in` — Go to `/setup-engine` now and write the GDD manually afterward
3. Show the recommended path:
**Concept phase:**
- `/brainstorm` or `/setup-engine` — (their pick from step 2)
- `/prototype` — throwaway concept build: validate the core idea is fun before designing (13 days)
- `/art-bible` — define visual identity (after brainstorm if run, or after concept doc exists)
- `/design-review` — validate the concept doc
- `/map-systems` — decompose the concept into individual systems
- `/design-system` — author a GDD for each MVP system
- `/review-all-gdds` — cross-system consistency check
- `/gate-check` — validate readiness before architecture work
**Architecture phase:**
- `/create-architecture` — produce the master architecture blueprint and Required ADR list
- `/architecture-decision (×N)` — record key technical decisions, following the Required ADR list
- `/create-control-manifest` — compile decisions into an actionable rules sheet
- `/architecture-review` — validate architecture coverage
**Pre-Production phase:**
- `/ux-design` — author UX specs for key screens (main menu, HUD, core interactions)
- `/vertical-slice` — production-quality end-to-end build to validate the full game loop
- `/playtest-report (×1+)` — document each vertical slice playtest session
- `/create-epics` — map systems to epics
- `/create-stories` — break epics into implementable stories
- `/sprint-plan` — plan the first sprint
**Production phase:** → pick up stories with `/dev-story`
#### If D: Existing work
1. Share what you found in Phase 1:
- "I can see you have [X source files / Y design docs / Z prototypes]..."
- "Your engine is [configured as X / not yet configured]..."
2. **Sub-case D1 — Early stage** (engine not configured or only a game concept exists):
- Recommend `/setup-engine` first if engine not configured
- Then `/project-stage-detect` for a gap inventory
**Sub-case D2 — GDDs, ADRs, or stories already exist:**
- Explain: "Having files isn't the same as the template's skills being able to use them. GDDs might be missing required sections. `/adopt` checks this specifically."
- Recommend:
1. `/project-stage-detect` — understand what phase and what's missing entirely
2. `/adopt` — audit whether existing artifacts are in the right internal format
3. Show the recommended path for D2:
- `/project-stage-detect` — phase detection + existence gaps
- `/adopt` — format compliance audit + migration plan
- `/setup-engine` — if engine not configured
- `/design-system retrofit [path]` — fill missing GDD sections
- `/architecture-decision retrofit [path]` — add missing ADR sections
- `/architecture-review` — bootstrap the TR requirement registry
- `/gate-check` — validate readiness for next phase
---
## Phase 3c: Write Initial Stage File
After confirming the starting path (and before asking about review mode), write the initial stage to `production/stage.txt`. Create the `production/` directory if it does not exist.
Stage mapping:
- **Path A, B, or C (starting from scratch)**: write `Concept`
- **Path D, existing project, engine not configured or only a game concept exists**: write `Concept`
- **Path D, existing project with GDDs but no architecture documents**: write `Systems Design`
- **Path D, existing project with full architecture (ADRs, architecture doc)**: write `Technical Setup`
Do this silently — no "May I write?" needed for this single-line file.
Say: "I've set `production/stage.txt` to `[stage]` — this anchors your status line and stage detection."
---
## Phase 3b: Set Review Mode
Check if `production/review-mode.txt` already exists.
**If it exists**: Read it and show the current mode — "Review mode is set to `[current]`." — then proceed to Phase 4. Do not ask again.
**If it does not exist**: Use `AskUserQuestion`:
- **Prompt**: "One setup choice: how much design review would you want as you work through the workflow?"
- **Options**:
- `Full` — Director specialists review at each key workflow step. Best for teams, learning the workflow, or when you want thorough feedback on every decision.
- `Lean (recommended)` — Directors only at phase gate transitions (/gate-check). Skips per-skill reviews. Balanced approach for solo devs and small teams.
- `Solo` — No director reviews at all. Maximum speed. Best for game jams, prototypes, or if the reviews feel like overhead.
Write the choice to `production/review-mode.txt` immediately after the user
selects — no separate "May I write?" needed, as the write is a direct
consequence of the selection:
- `Full` → write `full`
- `Lean (recommended)` → write `lean`
- `Solo` → write `solo`
Create the `production/` directory if it does not exist.
---
## Phase 4: Confirm Before Proceeding
After presenting the recommended path, use `AskUserQuestion` to ask the user which step they'd like to take first. Never auto-run the next skill.
- **Prompt**: "Would you like to start with [recommended first step]?"
- **Options**:
- `Yes, let's start with [recommended first step]`
- `I'd like to do something else first`
---
## Phase 5: Hand Off
When the user confirms their next step, respond with a single short line: "Type `[skill command]` to begin." Nothing else. Do not re-explain the skill or add encouragement. The `/start` skill's job is done.
Verdict: **COMPLETE** — user oriented and handed off to next step.
---
## Edge Cases
- **User picks D but project is empty**: Gently redirect — "It looks like the project is a fresh template with no artifacts yet. Would Path A or B be a better fit?"
- **User picks A but project has code**: Mention what you found — "I noticed there's already code in `src/`. Did you mean to pick D (existing work)?"
- **User is returning (engine configured, concept exists)**: Skip onboarding entirely — "It looks like you're already set up! Your engine is [X] and you have a game concept at `design/gdd/game-concept.md`. Review mode: `[read from production/review-mode.txt, or 'lean (default)' if missing]`. Want to pick up where you left off? Try `/sprint-plan` or just tell me what you'd like to work on."
- **User doesn't fit any option**: Let them describe their situation in their own words and adapt.
---
## Collaborative Protocol
1. **Ask first** — never assume the user's state or intent
2. **Present options** — give clear paths, not mandates
3. **User decides** — they pick the direction
4. **No auto-execution** — recommend the next skill, don't run it without asking
5. **Adapt** — if the user's situation doesn't fit a template, listen and adjust