mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 04:51:46 +00:00
Release v0.2.0: Context Resilience, AskUserQuestion, /design-systems
* Add context resilience: file-backed state, incremental writing, auto-recovery Prevents "prompt too long" crashes from killing sessions by persisting work to disk incrementally instead of relying on conversation memory. Changes: - pre-compact.sh: dumps session state before context compression - session-start.sh: detects active.md for crash recovery - session-stop.sh: archives and clears active.md on clean shutdown - context-management.md: file-backed state as primary strategy - 9 agents updated with incremental section writing protocol (game-designer, systems-designer, economy-designer, narrative-director, level-designer, world-builder, writer, art-director, audio-director) - CLAUDE.md: trimmed redundant imports (10 → 5) to reduce token overhead - design-docs.md rule: enforces incremental writing pattern - .gitignore: excludes ephemeral session state files - directory-structure.md: documents session-state/ and session-logs/ - COLLABORATIVE-DESIGN-PRINCIPLE.md: documents incremental writing pattern Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add AskUserQuestion integration across collaborative protocols Explicitly reference the AskUserQuestion tool in all collaborative agent definitions, protocol templates, team orchestrator skills, and the master principle doc. Introduces the Explain-then-Capture pattern: agents write full expert analysis in conversation, then call AskUserQuestion with concise labels to capture decisions via structured UI. 26 files updated: - 3 protocol templates (design, leadership, implementation) - 14 agent definitions (10 design + 3 leadership + writer) - 8 orchestrator skills (brainstorm + 7 team-*) - 1 master principle doc (COLLABORATIVE-DESIGN-PRINCIPLE.md) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add /design-systems skill: concept-to-GDD decomposition workflow Bridges the gap between game concept and per-system design documents. Professional studios use systems enumeration + dependency sorting between concept and feature docs — skipping this step is one of the most expensive mistakes (systems discovered during production cost 5-10x more to add). New files: - .claude/skills/design-systems/SKILL.md — 7-phase orchestration skill (enumerate systems, map dependencies, assign priorities, write GDDs) - .claude/docs/templates/systems-index.md — master tracking template Flow integration (7 existing skills updated): - brainstorm, start, setup-engine, design-review, gate-check, project-stage-detect, game-concept template all reference /design-systems at the appropriate workflow touchpoints Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Fix cross-platform bugs, add missing tool permissions, and update docs for v0.2.0 Hooks: fix \s → [[:space:]] in grep -E fallbacks (3 files), fix detect-gaps.sh empty-variable bug, fix log-agent.sh field name (agent_name → agent_type), harden validate-push.sh with explicit $MATCHED_BRANCH, convert for-in loops to while-read for space-safe iteration, add POSIX head -n syntax, increase PreCompact timeout, widen session-stop log window. Skills: add AskUserQuestion to 10 skills and TodoWrite to 8 multi-phase skills. Fix project-stage-detect template/output paths, tech-artist → technical-artist. Docs: add /design-systems to all references (README, quick-start, workflow guide, skills-reference), update skill count 35 → 36, remove stale AI artifacts from COLLABORATIVE-DESIGN-PRINCIPLE.md, add AskUserQuestion note to examples README. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Donchitos
@@ -3,7 +3,7 @@ name: brainstorm
|
||||
description: "Guided game concept ideation — from zero idea to a structured game concept document. Uses professional studio ideation techniques, player psychology frameworks, and structured creative exploration."
|
||||
argument-hint: "[genre or theme hint, or 'open' for fully open brainstorm]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, WebSearch
|
||||
allowed-tools: Read, Glob, Grep, Write, WebSearch, AskUserQuestion
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
@@ -21,6 +21,14 @@ When this skill is invoked:
|
||||
exploration** where the AI acts as a creative facilitator, not a replacement
|
||||
for the human's vision.
|
||||
|
||||
**Use `AskUserQuestion`** at key decision points throughout brainstorming:
|
||||
- Constrained taste questions (genre preferences, scope, team size)
|
||||
- Concept selection ("Which 2-3 concepts resonate?") after presenting options
|
||||
- Direction choices ("Develop further, explore more, or prototype?")
|
||||
- Pillar ranking after concepts are refined
|
||||
Write full creative analysis in conversation text first, then use
|
||||
`AskUserQuestion` to capture the decision with concise labels.
|
||||
|
||||
Professional studio brainstorming principles to follow:
|
||||
- Withhold judgment — no idea is bad during exploration
|
||||
- Encourage unusual ideas — outside-the-box thinking sparks better concepts
|
||||
@@ -192,6 +200,7 @@ Ground the concept in reality:
|
||||
- "Run `/setup-engine [engine] [version]` to configure the engine and populate version-aware reference docs"
|
||||
- "Use `/design-review design/gdd/game-concept.md` to validate completeness"
|
||||
- "Discuss vision with the `creative-director` agent for pillar refinement"
|
||||
- "Decompose the concept into individual systems with `/design-systems` — maps dependencies, assigns priorities, and guides per-system GDD creation"
|
||||
- "Prototype the core loop with `/prototype [core-mechanic]`"
|
||||
- "Playtest the prototype with `/playtest-report` to validate the hypothesis"
|
||||
- "If validated, plan the first sprint with `/sprint-plan new`"
|
||||
|
||||
@@ -62,3 +62,15 @@ When this skill is invoked:
|
||||
|
||||
### Verdict: [APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED]
|
||||
```
|
||||
|
||||
9. **Contextual next step recommendations**:
|
||||
- If the document being reviewed is `game-concept.md` or `game-pillars.md`:
|
||||
- Check if `design/gdd/systems-index.md` exists
|
||||
- If it does NOT exist, add to Recommendations:
|
||||
> "This concept is ready for systems decomposition. Run `/design-systems`
|
||||
> to break it down into individual systems with dependencies and priorities,
|
||||
> then write per-system GDDs."
|
||||
- If the document is an individual system GDD:
|
||||
- Check if the systems index references this system
|
||||
- If so, suggest updating its status: "Update the systems index status for
|
||||
this system from 'In Design' to 'Designed'."
|
||||
|
||||
344
.claude/skills/design-systems/SKILL.md
Normal file
344
.claude/skills/design-systems/SKILL.md
Normal file
@@ -0,0 +1,344 @@
|
||||
---
|
||||
name: design-systems
|
||||
description: "Decompose a game concept into individual systems, map dependencies, prioritize design order, and guide creation of per-system GDDs."
|
||||
argument-hint: "[optional: 'map' to create/update the systems index, system-name to design a specific system, or 'next' for the highest-priority undesigned system]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, TodoWrite
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
|
||||
## 1. Parse Arguments
|
||||
|
||||
Three modes:
|
||||
|
||||
- **No argument / `map`**: `/design-systems` or `/design-systems map` — Run the full
|
||||
decomposition workflow (Phases 1-5) to create or update the systems index.
|
||||
- **System name**: `/design-systems combat` — Jump directly to Phase 6 to design
|
||||
a specific system's GDD. Requires the systems index to exist already.
|
||||
- **`next`**: `/design-systems next` — Pick the highest-priority undesigned system
|
||||
from the index and start designing it (Phase 6).
|
||||
|
||||
---
|
||||
|
||||
## 2. Phase 1: Read Concept (Required Context)
|
||||
|
||||
Read the game concept and any existing design work. This provides the raw material
|
||||
for systems decomposition.
|
||||
|
||||
**Required:**
|
||||
- Read `design/gdd/game-concept.md` — **fail with a clear message if missing**:
|
||||
> "No game concept found at `design/gdd/game-concept.md`. Run `/brainstorm` first
|
||||
> to create one, then come back to decompose it into systems."
|
||||
|
||||
**Optional (read if they exist):**
|
||||
- Read `design/gdd/game-pillars.md` — pillars constrain priority and scope
|
||||
- Read `design/gdd/systems-index.md` — if exists, **resume** from where it left off
|
||||
(update, don't recreate from scratch)
|
||||
- Glob `design/gdd/*.md` — check which system GDDs already exist
|
||||
|
||||
**If the systems index already exists:**
|
||||
- Read it and present current status to the user
|
||||
- Use `AskUserQuestion` to ask:
|
||||
"The systems index already exists with [N] systems ([M] designed, [K] not started).
|
||||
What would you like to do?"
|
||||
- Options: "Update the index with new systems", "Design the next undesigned system",
|
||||
"Review and revise priorities"
|
||||
|
||||
---
|
||||
|
||||
## 3. Phase 2: Systems Enumeration (Collaborative)
|
||||
|
||||
Extract and identify all systems the game needs. This is the creative core of the
|
||||
skill — it requires human judgment because concept docs rarely enumerate every
|
||||
system explicitly.
|
||||
|
||||
### Step 2a: Extract Explicit Systems
|
||||
|
||||
Scan the game concept for directly mentioned systems and mechanics:
|
||||
- Core Mechanics section (most explicit)
|
||||
- Core Loop section (implies what systems drive each loop tier)
|
||||
- Technical Considerations section (networking, procedural generation, etc.)
|
||||
- MVP Definition section (required features = required systems)
|
||||
|
||||
### Step 2b: Identify Implicit Systems
|
||||
|
||||
For each explicit system, identify the **hidden systems** it implies. Games always
|
||||
need more systems than the concept doc mentions. Use this inference pattern:
|
||||
|
||||
- "Inventory" implies: item database, equipment slots, weight/capacity rules,
|
||||
inventory UI, item serialization for save/load
|
||||
- "Combat" implies: damage calculation, health system, hit detection, status effects,
|
||||
enemy AI, combat UI (health bars, damage numbers), death/respawn
|
||||
- "Open world" implies: streaming/chunking, LOD system, fast travel, map/minimap,
|
||||
point of interest tracking, world state persistence
|
||||
- "Multiplayer" implies: networking layer, lobby/matchmaking, state synchronization,
|
||||
anti-cheat, network UI (ping, player list)
|
||||
- "Crafting" implies: recipe database, ingredient gathering, crafting UI,
|
||||
success/failure mechanics, recipe discovery/learning
|
||||
- "Dialogue" implies: dialogue tree system, dialogue UI, choice tracking, NPC
|
||||
state management, localization hooks
|
||||
- "Progression" implies: XP system, level-up mechanics, skill tree, unlock
|
||||
tracking, progression UI, progression save data
|
||||
|
||||
Explain in conversation text why each implicit system is needed (with examples).
|
||||
|
||||
### Step 2c: User Review
|
||||
|
||||
Present the enumeration organized by category. For each system, show:
|
||||
- Name
|
||||
- Category
|
||||
- Brief description (1 sentence)
|
||||
- Whether it was explicit (from concept) or implicit (inferred)
|
||||
|
||||
Then use `AskUserQuestion` to capture feedback:
|
||||
- "Are there systems missing from this list?"
|
||||
- "Should any of these be combined or split?"
|
||||
- "Are there systems listed that this game does NOT need?"
|
||||
|
||||
Iterate until the user approves the enumeration.
|
||||
|
||||
---
|
||||
|
||||
## 4. Phase 3: Dependency Mapping (Collaborative)
|
||||
|
||||
For each system, determine what it depends on. A system "depends on" another if
|
||||
it cannot function without that other system existing first.
|
||||
|
||||
### Step 3a: Map Dependencies
|
||||
|
||||
For each system, list its dependencies. Use these dependency heuristics:
|
||||
- **Input/output dependencies**: System A produces data System B needs
|
||||
- **Structural dependencies**: System A provides the framework System B plugs into
|
||||
- **UI dependencies**: Every gameplay system has a corresponding UI system that
|
||||
depends on it (but UI is designed after the gameplay system)
|
||||
|
||||
### Step 3b: Sort by Dependency Order
|
||||
|
||||
Arrange systems into layers:
|
||||
1. **Foundation**: Systems with zero dependencies (designed and built first)
|
||||
2. **Core**: Systems depending only on Foundation systems
|
||||
3. **Feature**: Systems depending on Core systems
|
||||
4. **Presentation**: UI and feedback systems that wrap gameplay systems
|
||||
5. **Polish**: Meta-systems, tutorials, analytics, accessibility
|
||||
|
||||
### Step 3c: Detect Circular Dependencies
|
||||
|
||||
Check for cycles in the dependency graph. If found:
|
||||
- Highlight them to the user
|
||||
- Propose resolutions (interface abstraction, simultaneous design, breaking the
|
||||
cycle by defining a contract between the two systems)
|
||||
|
||||
### Step 3d: Present to User
|
||||
|
||||
Show the dependency map as a layered list. Highlight:
|
||||
- Any circular dependencies
|
||||
- Any "bottleneck" systems (many others depend on them — these are high-risk)
|
||||
- Any systems with no dependents (leaf nodes — lower risk, can be designed late)
|
||||
|
||||
Use `AskUserQuestion` to ask: "Does this dependency ordering look right? Any
|
||||
dependencies I'm missing or that should be removed?"
|
||||
|
||||
---
|
||||
|
||||
## 5. Phase 4: Priority Assignment (Collaborative)
|
||||
|
||||
Assign each system to a priority tier based on what milestone it's needed for.
|
||||
|
||||
### Step 4a: Auto-Assign Based on Concept
|
||||
|
||||
Use these heuristics for initial assignment:
|
||||
- **MVP**: Systems mentioned in the concept's "Required for MVP" section, plus their
|
||||
Foundation-layer dependencies
|
||||
- **Vertical Slice**: Systems needed for a complete experience in one area
|
||||
- **Alpha**: All remaining gameplay systems
|
||||
- **Full Vision**: Polish, meta, and nice-to-have systems
|
||||
|
||||
### Step 4b: User Review
|
||||
|
||||
Present the priority assignments in a table. For each tier, explain why systems
|
||||
were placed there.
|
||||
|
||||
Use `AskUserQuestion` to ask: "Do these priority assignments match your vision?
|
||||
Which systems should be higher or lower priority?"
|
||||
|
||||
Explain reasoning in conversation: "I placed [system] in MVP because the core loop
|
||||
requires it — without [system], the 30-second loop can't function."
|
||||
|
||||
### Step 4c: Determine Design Order
|
||||
|
||||
Combine dependency sort + priority tier to produce the final design order:
|
||||
1. MVP Foundation systems first
|
||||
2. MVP Core systems second
|
||||
3. MVP Feature systems third
|
||||
4. Vertical Slice Foundation/Core systems
|
||||
5. ...and so on
|
||||
|
||||
This is the order the team should write GDDs in.
|
||||
|
||||
---
|
||||
|
||||
## 6. Phase 5: Create Systems Index (Write)
|
||||
|
||||
### Step 5a: Draft the Document
|
||||
|
||||
Using the template at `.claude/docs/templates/systems-index.md`, populate the
|
||||
systems index with all data from Phases 2-4:
|
||||
- Fill the enumeration table
|
||||
- Fill the dependency map
|
||||
- Fill the recommended design order
|
||||
- Fill the high-risk systems
|
||||
- Fill progress tracker (all systems "Not Started" initially, unless GDDs already exist)
|
||||
|
||||
### Step 5b: Approval
|
||||
|
||||
Present a summary of the document:
|
||||
- Total systems count by category
|
||||
- MVP system count
|
||||
- First 3 systems in the design order
|
||||
- Any high-risk items
|
||||
|
||||
Ask: "May I write the systems index to `design/gdd/systems-index.md`?"
|
||||
|
||||
Wait for approval. Write the file only after "yes."
|
||||
|
||||
### Step 5c: Update Session State
|
||||
|
||||
After writing, update `production/session-state/active.md` with:
|
||||
- Task: Systems decomposition
|
||||
- Status: Systems index created
|
||||
- File: design/gdd/systems-index.md
|
||||
- Next: Design individual system GDDs
|
||||
|
||||
---
|
||||
|
||||
## 7. Phase 6: Design Individual Systems (Optional, Iterative)
|
||||
|
||||
This phase is entered when:
|
||||
- The user says "yes" to designing systems after creating the index
|
||||
- The user invokes `/design-systems [system-name]`
|
||||
- The user invokes `/design-systems next`
|
||||
|
||||
### Step 6a: Select the System
|
||||
|
||||
- If a system name was provided, find it in the systems index
|
||||
- If `next` was used, pick the highest-priority undesigned system (by design order)
|
||||
- If the user just finished the index, ask:
|
||||
"Would you like to start designing individual systems now? The first system in
|
||||
the design order is [name]. Or would you prefer to stop here and come back later?"
|
||||
|
||||
Use `AskUserQuestion` for: "Start designing [system-name] now, pick a different
|
||||
system, or stop here?"
|
||||
|
||||
### Step 6b: Delegate to Agents
|
||||
|
||||
Use the Task tool to delegate GDD writing to the appropriate agent(s):
|
||||
|
||||
**For most gameplay systems:**
|
||||
Delegate to `game-designer` with this context in the Task prompt:
|
||||
- The system name and description from the systems index
|
||||
- The game concept summary (elevator pitch, pillars, core loop)
|
||||
- The dependency list (what this system depends on, what depends on it)
|
||||
- Any existing related GDDs (read and summarize for context)
|
||||
- The GDD template to follow (`.claude/docs/templates/game-design-document.md`)
|
||||
- The 8 required sections per coding standards
|
||||
- Instruction to follow the collaborative protocol and use incremental file writing
|
||||
|
||||
**For formula-heavy systems (combat, economy, progression):**
|
||||
Also delegate to `systems-designer` for detailed mathematical modeling. The
|
||||
`game-designer` handles the high-level design; the `systems-designer` fills in
|
||||
formulas, interaction matrices, and tuning knobs.
|
||||
|
||||
**For narrative systems (dialogue, quests, lore):**
|
||||
Coordinate with `narrative-director` in addition to `game-designer`.
|
||||
|
||||
**For UI systems:**
|
||||
Coordinate with `ux-designer` in addition to `game-designer`.
|
||||
|
||||
**For audio systems:**
|
||||
Coordinate with `audio-director` and `sound-designer`.
|
||||
|
||||
**For economy systems:**
|
||||
Coordinate with `economy-designer`.
|
||||
|
||||
Present the agent's output to the user for review and approval before writing.
|
||||
|
||||
### Step 6c: Write the GDD
|
||||
|
||||
After user approval, write the GDD to `design/gdd/[system-name].md`.
|
||||
(The delegated agent handles this, following the collaborative protocol.)
|
||||
|
||||
### Step 6d: Run Design Review
|
||||
|
||||
After the GDD is written, run `/design-review design/gdd/[system-name].md` to
|
||||
validate:
|
||||
- All 8 required sections are present and complete
|
||||
- Formulas are internally consistent
|
||||
- Dependencies match what other GDDs expect
|
||||
- Edge cases don't contradict other systems
|
||||
- Rules are precise enough for a programmer to implement
|
||||
|
||||
If the review finds issues:
|
||||
- Present them to the user
|
||||
- Fix the identified holes before proceeding to the next system
|
||||
- Re-run the review after fixes to confirm resolution
|
||||
|
||||
### Step 6e: Update the Systems Index
|
||||
|
||||
After each GDD passes review:
|
||||
- Update the system's Status in the enumeration table (Not Started -> Approved)
|
||||
- Update the Design Doc path column
|
||||
- Update the Progress Tracker counts
|
||||
- Ask: "May I update the systems index at `design/gdd/systems-index.md`?"
|
||||
|
||||
### Step 6f: Loop or Stop
|
||||
|
||||
After each system, use `AskUserQuestion`:
|
||||
- "Continue to the next system ([next system name])?"
|
||||
- "Pick a different system?"
|
||||
- "Stop here for this session?"
|
||||
|
||||
If continuing, return to Step 6a.
|
||||
|
||||
---
|
||||
|
||||
## 8. Phase 7: Suggest Next Steps
|
||||
|
||||
After the systems index is created (or after designing some systems), suggest
|
||||
the appropriate next actions:
|
||||
|
||||
- For each undesigned MVP system, recommend the right agent(s):
|
||||
- Gameplay mechanics: `game-designer` + `systems-designer`
|
||||
- UI systems: `game-designer` + `ux-designer`
|
||||
- Audio systems: `audio-director` + `sound-designer`
|
||||
- Narrative systems: `game-designer` + `narrative-director`
|
||||
- Economy systems: `economy-designer`
|
||||
- Level design: `level-designer`
|
||||
- "Run `/design-review [path]` on each completed GDD to validate quality"
|
||||
- "Run `/gate-check pre-production` to check if you're ready to start building"
|
||||
- "Prototype the highest-risk system with `/prototype [system]`"
|
||||
- "Plan the first implementation sprint with `/sprint-plan new`"
|
||||
|
||||
---
|
||||
|
||||
## Collaborative Protocol
|
||||
|
||||
This skill follows the collaborative design principle at every phase:
|
||||
|
||||
1. **Question -> Options -> Decision -> Draft -> Approval** at every step
|
||||
2. **AskUserQuestion** at every decision point (Explain -> Capture pattern):
|
||||
- Phase 2: "Missing systems? Combine or split?"
|
||||
- Phase 3: "Dependency ordering correct?"
|
||||
- Phase 4: "Priority assignments match your vision?"
|
||||
- Phase 5: "May I write the systems index?"
|
||||
- Phase 6: "Start designing, pick different, or stop?"
|
||||
3. **"May I write to [filepath]?"** before every file write
|
||||
4. **Incremental writing**: Update the systems index after each system is designed
|
||||
5. **Design review loop**: Every completed GDD passes `/design-review` before the
|
||||
next system starts — holes are caught early, not downstream
|
||||
6. **Session state updates**: Write to `production/session-state/active.md` after
|
||||
each milestone (index created, system designed, priorities changed)
|
||||
|
||||
**Never** auto-generate the full systems list and write it without review.
|
||||
**Never** start designing a system without user confirmation.
|
||||
**Always** show the enumeration, dependencies, and priorities for user validation.
|
||||
@@ -44,7 +44,8 @@ This skill is prescriptive ("are we ready to advance?" with a formal verdict).
|
||||
### Gate: Pre-production → Production
|
||||
|
||||
**Required Artifacts:**
|
||||
- [ ] At least 1 GDD in `design/gdd/` (beyond game-concept.md)
|
||||
- [ ] Systems index exists at `design/gdd/systems-index.md` with at least MVP systems enumerated
|
||||
- [ ] At least 1 GDD in `design/gdd/` (beyond game-concept.md and systems-index.md)
|
||||
- [ ] At least 1 Architecture Decision Record in `docs/architecture/`
|
||||
- [ ] At least 1 prototype in `prototypes/` with a README
|
||||
- [ ] Engine reference docs exist in `docs/engine-reference/`
|
||||
@@ -185,6 +186,7 @@ For items that can't be automatically verified, **ask the user**:
|
||||
|
||||
Based on the verdict, suggest specific next steps:
|
||||
|
||||
- **No systems index?** → `/design-systems` to decompose the concept into systems
|
||||
- **Missing design docs?** → `/reverse-document` or delegate to `game-designer`
|
||||
- **Missing ADRs?** → `/architecture-decision`
|
||||
- **Tests failing?** → delegate to `lead-programmer` or `qa-tester`
|
||||
|
||||
@@ -25,7 +25,8 @@ Analyze project structure and content:
|
||||
|
||||
**Design Documentation** (`design/`):
|
||||
- Count GDD files in `design/gdd/*.md`
|
||||
- Check for game-concept.md, game-pillars.md
|
||||
- Check for game-concept.md, game-pillars.md, systems-index.md
|
||||
- If systems-index.md exists, count total systems vs. designed systems
|
||||
- Analyze completeness (Overview, Detailed Design, Edge Cases, etc.)
|
||||
- Count narrative docs in `design/narrative/`
|
||||
- Count level designs in `design/levels/`
|
||||
@@ -72,11 +73,12 @@ Based on scanned artifacts, determine stage:
|
||||
- "I see combat code (`src/gameplay/combat/`) but no `design/gdd/combat-system.md`. Was this prototyped first, or should we reverse-document?"
|
||||
- "You have 15 ADRs but no architecture overview. Should I create one to help new contributors?"
|
||||
- "No sprint plans in `production/`. Are you tracking work elsewhere (Jira, Trello, etc.)?"
|
||||
- "I found a game concept but no systems index. Have you decomposed the concept into individual systems yet, or should we run `/design-systems`?"
|
||||
- "Prototypes directory has 3 projects with no READMEs. Were these experiments, or do they need documentation?"
|
||||
|
||||
### 4. Generate Stage Report
|
||||
|
||||
Use template: `docs/templates/project-stage-report.md`
|
||||
Use template: `.claude/docs/templates/project-stage-report.md`
|
||||
|
||||
**Report structure**:
|
||||
```markdown
|
||||
@@ -137,7 +139,7 @@ Recommended next steps:
|
||||
- [Priority 2]
|
||||
- [Priority 3]
|
||||
|
||||
May I write the full stage analysis to docs/project-stage-report.md?
|
||||
May I write the full stage analysis to production/project-stage-report.md?
|
||||
```
|
||||
|
||||
Wait for user approval before creating the file.
|
||||
@@ -163,6 +165,7 @@ Wait for user approval before creating the file.
|
||||
|
||||
After generating the report, suggest relevant next steps:
|
||||
|
||||
- **Concept exists but no systems index?** → `/design-systems` to decompose into systems
|
||||
- **Missing design docs?** → `/reverse-document design src/[system]`
|
||||
- **Missing architecture docs?** → `/architecture-decision` or `/reverse-document architecture`
|
||||
- **Prototypes need documentation?** → `/reverse-document concept prototypes/[name]`
|
||||
@@ -179,6 +182,6 @@ This skill follows the collaborative design principle:
|
||||
2. **Present Options**: "Should I create X, or is it tracked elsewhere?"
|
||||
3. **User Decides**: Wait for direction
|
||||
4. **Show Draft**: Display report summary
|
||||
5. **Get Approval**: "May I write to docs/project-stage-report.md?"
|
||||
5. **Get Approval**: "May I write to production/project-stage-report.md?"
|
||||
|
||||
**Never** silently write files. **Always** show findings and ask before creating artifacts.
|
||||
|
||||
@@ -291,9 +291,10 @@ Agent Config: [verified]
|
||||
|
||||
Next Steps:
|
||||
1. Review docs/engine-reference/<engine>/VERSION.md
|
||||
2. [If from /brainstorm] Run /prototype [core-mechanic] to test the core loop
|
||||
3. [If fresh start] Run /brainstorm to discover your game concept
|
||||
4. Create your first milestone: /sprint-plan new
|
||||
2. [If from /brainstorm] Run /design-systems to decompose your concept into individual systems
|
||||
3. [If from /brainstorm] Run /prototype [core-mechanic] to test the core loop
|
||||
4. [If fresh start] Run /brainstorm to discover your game concept
|
||||
5. Create your first milestone: /sprint-plan new
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -3,7 +3,7 @@ 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
|
||||
allowed-tools: Read, Glob, Grep, AskUserQuestion
|
||||
---
|
||||
|
||||
# Guided Onboarding
|
||||
@@ -77,6 +77,7 @@ technical setup — all of that comes later.
|
||||
4. Show the recommended path:
|
||||
- `/brainstorm` — discover your game concept
|
||||
- `/setup-engine` — configure the engine (brainstorm will recommend one)
|
||||
- `/design-systems` — decompose the concept into systems and plan GDD writing order
|
||||
- `/prototype` — test the core mechanic
|
||||
- `/sprint-plan` — plan the first sprint
|
||||
|
||||
@@ -90,6 +91,7 @@ The user has a seed but needs help growing it into a concept.
|
||||
4. Show the recommended path:
|
||||
- `/brainstorm [hint]` — develop the idea into a full concept
|
||||
- `/setup-engine` — configure the engine
|
||||
- `/design-systems` — decompose the concept into systems and plan GDD writing order
|
||||
- `/prototype` — test the core mechanic
|
||||
- `/sprint-plan` — plan the first sprint
|
||||
|
||||
@@ -109,6 +111,7 @@ The user knows what they want to make but hasn't documented it.
|
||||
3. Show the recommended path (adapted to their choice):
|
||||
- `/brainstorm` or `/setup-engine` (their pick)
|
||||
- `/design-review` — validate the concept doc
|
||||
- `/design-systems` — decompose the concept into individual systems with dependencies and priorities
|
||||
- `/architecture-decision` — make first technical decisions
|
||||
- `/sprint-plan` — plan the first sprint
|
||||
|
||||
|
||||
@@ -3,10 +3,15 @@ name: team-audio
|
||||
description: "Orchestrate audio team: audio-director + sound-designer + technical-artist + gameplay-programmer for full audio pipeline from direction to implementation."
|
||||
argument-hint: "[feature or area to design audio for]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
When this skill is invoked, orchestrate the audio team through a structured pipeline.
|
||||
|
||||
**Decision Points:** At each step transition, use `AskUserQuestion` to present
|
||||
the user with the subagent's proposals as selectable options. Write the agent's
|
||||
full analysis in conversation, then capture the decision with concise labels.
|
||||
The user must approve before moving to the next step.
|
||||
|
||||
1. **Read the argument** for the target feature or area (e.g., `combat`,
|
||||
`main menu`, `forest biome`, `boss encounter`).
|
||||
|
||||
@@ -3,10 +3,15 @@ name: team-combat
|
||||
description: "Orchestrate the combat team: coordinates game-designer, gameplay-programmer, ai-programmer, technical-artist, sound-designer, and qa-tester to design, implement, and validate a combat feature end-to-end."
|
||||
argument-hint: "[combat feature description]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
||||
---
|
||||
When this skill is invoked, orchestrate the combat team through a structured pipeline.
|
||||
|
||||
**Decision Points:** At each phase transition, use `AskUserQuestion` to present
|
||||
the user with the subagent's proposals as selectable options. Write the agent's
|
||||
full analysis in conversation, then capture the decision with concise labels.
|
||||
The user must approve before moving to the next phase.
|
||||
|
||||
## Team Composition
|
||||
- **game-designer** — Design the mechanic, define formulas and edge cases
|
||||
- **gameplay-programmer** — Implement the core gameplay code
|
||||
|
||||
@@ -3,11 +3,16 @@ name: team-level
|
||||
description: "Orchestrate level design team: level-designer + narrative-director + world-builder + art-director + systems-designer + qa-tester for complete area/level creation."
|
||||
argument-hint: "[level name or area to design]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
|
||||
**Decision Points:** At each step transition, use `AskUserQuestion` to present
|
||||
the user with the subagent's proposals as selectable options. Write the agent's
|
||||
full analysis in conversation, then capture the decision with concise labels.
|
||||
The user must approve before moving to the next step.
|
||||
|
||||
1. **Read the argument** for the target level or area (e.g., `tutorial`,
|
||||
`forest dungeon`, `hub town`, `final boss arena`).
|
||||
|
||||
|
||||
@@ -3,10 +3,15 @@ name: team-narrative
|
||||
description: "Orchestrate the narrative team: coordinates narrative-director, writer, world-builder, and level-designer to create cohesive story content, world lore, and narrative-driven level design."
|
||||
argument-hint: "[narrative content description]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Task
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Task, AskUserQuestion, TodoWrite
|
||||
---
|
||||
When this skill is invoked, orchestrate the narrative team through a structured pipeline.
|
||||
|
||||
**Decision Points:** At each phase transition, use `AskUserQuestion` to present
|
||||
the user with the subagent's proposals as selectable options. Write the agent's
|
||||
full analysis in conversation, then capture the decision with concise labels.
|
||||
The user must approve before moving to the next phase.
|
||||
|
||||
## Team Composition
|
||||
- **narrative-director** — Story arcs, character design, dialogue strategy, narrative vision
|
||||
- **writer** — Dialogue writing, lore entries, item descriptions, in-game text
|
||||
|
||||
@@ -3,10 +3,15 @@ name: team-polish
|
||||
description: "Orchestrate the polish team: coordinates performance-analyst, technical-artist, sound-designer, and qa-tester to optimize, polish, and harden a feature or area for release quality."
|
||||
argument-hint: "[feature or area to polish]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
||||
---
|
||||
When this skill is invoked, orchestrate the polish team through a structured pipeline.
|
||||
|
||||
**Decision Points:** At each phase transition, use `AskUserQuestion` to present
|
||||
the user with the subagent's proposals as selectable options. Write the agent's
|
||||
full analysis in conversation, then capture the decision with concise labels.
|
||||
The user must approve before moving to the next phase.
|
||||
|
||||
## Team Composition
|
||||
- **performance-analyst** — Profiling, optimization, memory analysis, frame budget
|
||||
- **technical-artist** — VFX polish, shader optimization, visual quality
|
||||
|
||||
@@ -3,10 +3,15 @@ name: team-release
|
||||
description: "Orchestrate the release team: coordinates release-manager, qa-lead, devops-engineer, and producer to execute a release from candidate to deployment."
|
||||
argument-hint: "[version number or 'next']"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
||||
---
|
||||
When this skill is invoked, orchestrate the release team through a structured pipeline.
|
||||
|
||||
**Decision Points:** At each phase transition, use `AskUserQuestion` to present
|
||||
the user with the subagent's proposals as selectable options. Write the agent's
|
||||
full analysis in conversation, then capture the decision with concise labels.
|
||||
The user must approve before moving to the next phase.
|
||||
|
||||
## Team Composition
|
||||
- **release-manager** — Release branch, versioning, changelog, deployment
|
||||
- **qa-lead** — Test sign-off, regression suite, release quality gate
|
||||
|
||||
@@ -3,10 +3,15 @@ name: team-ui
|
||||
description: "Orchestrate the UI team: coordinates ux-designer, ui-programmer, and art-director to design, implement, and polish a user interface feature from wireframe to final."
|
||||
argument-hint: "[UI feature description]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
||||
---
|
||||
When this skill is invoked, orchestrate the UI team through a structured pipeline.
|
||||
|
||||
**Decision Points:** At each phase transition, use `AskUserQuestion` to present
|
||||
the user with the subagent's proposals as selectable options. Write the agent's
|
||||
full analysis in conversation, then capture the decision with concise labels.
|
||||
The user must approve before moving to the next phase.
|
||||
|
||||
## Team Composition
|
||||
- **ux-designer** — User flows, wireframes, accessibility, input handling
|
||||
- **ui-programmer** — UI framework, screens, widgets, data binding, implementation
|
||||
|
||||
Reference in New Issue
Block a user