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
@@ -329,6 +329,127 @@ Skill: "Writing design/concept.md..."
|
||||
|
||||
---
|
||||
|
||||
## 🎛️ Structured Decision UI (AskUserQuestion)
|
||||
|
||||
Use the `AskUserQuestion` tool to present decisions as a **selectable UI** instead
|
||||
of plain markdown text. This gives the user a clean interface to pick from options
|
||||
(or type "Other" for a custom answer).
|
||||
|
||||
### The Explain → Capture Pattern
|
||||
|
||||
Detailed reasoning doesn't fit in the tool's short descriptions. So use a two-step
|
||||
pattern:
|
||||
|
||||
1. **Explain first** — Write your full expert analysis in conversation text:
|
||||
detailed pros/cons, theory references, example games, pillar alignment. This is
|
||||
where the reasoning lives.
|
||||
|
||||
2. **Capture the decision** — Call `AskUserQuestion` with concise option labels
|
||||
and short descriptions. The user picks from the UI or types a custom answer.
|
||||
|
||||
### When to Use AskUserQuestion
|
||||
|
||||
✅ **Use it for:**
|
||||
- Every decision point where you'd present 2-4 options
|
||||
- Initial clarifying questions with constrained answers
|
||||
- Batching up to 4 independent questions in one call
|
||||
- Next-step choices ("Draft formulas or refine rules first?")
|
||||
- Architecture decisions ("Static utility or singleton?")
|
||||
- Strategic choices ("Simplify scope, slip deadline, or cut feature?")
|
||||
|
||||
❌ **Don't use it for:**
|
||||
- Open-ended discovery questions ("What excites you about roguelikes?")
|
||||
- Single yes/no confirmations ("May I write to file?")
|
||||
- When running as a Task subagent (tool may not be available)
|
||||
|
||||
### Format Guidelines
|
||||
|
||||
- **Labels**: 1-5 words (e.g., "Hybrid Discovery", "Full Randomized")
|
||||
- **Descriptions**: 1 sentence summarizing the approach and key trade-off
|
||||
- **Recommended**: Add "(Recommended)" to your preferred option's label
|
||||
- **Previews**: Use `markdown` field for comparing code structures or formulas
|
||||
- **Multi-select**: Use `multiSelect: true` when choices aren't mutually exclusive
|
||||
|
||||
### Example — Multi-Question Batch (Clarifying Questions)
|
||||
|
||||
After introducing the topic in conversation, batch constrained questions:
|
||||
|
||||
```
|
||||
AskUserQuestion:
|
||||
questions:
|
||||
- question: "Should crafting recipes be discovered or learned?"
|
||||
header: "Discovery"
|
||||
options:
|
||||
- label: "Experimentation"
|
||||
description: "Players discover by trying combinations — high mystery"
|
||||
- label: "NPC/Book Learning"
|
||||
description: "Recipes taught explicitly — accessible, lower mystery"
|
||||
- label: "Tiered Hybrid"
|
||||
description: "Basic recipes learned, advanced discovered — best of both"
|
||||
- question: "How punishing should failed crafts be?"
|
||||
header: "Failure"
|
||||
options:
|
||||
- label: "Materials Lost"
|
||||
description: "All consumed on failure — high stakes, risk/reward"
|
||||
- label: "Partial Recovery"
|
||||
description: "50% returned — moderate risk"
|
||||
- label: "No Loss"
|
||||
description: "Materials returned, only time spent — forgiving"
|
||||
```
|
||||
|
||||
### Example — Design Decision (After Full Analysis)
|
||||
|
||||
After writing the full pros/cons analysis in conversation text:
|
||||
|
||||
```
|
||||
AskUserQuestion:
|
||||
questions:
|
||||
- question: "Which crafting approach fits your vision?"
|
||||
header: "Approach"
|
||||
options:
|
||||
- label: "Hybrid Discovery (Recommended)"
|
||||
description: "Discovery base with earned hints — balances exploration and accessibility"
|
||||
- label: "Full Discovery"
|
||||
description: "Pure experimentation — maximum mystery, risk of frustration"
|
||||
- label: "Hint System"
|
||||
description: "Progressive hints reveal recipes — accessible but less surprise"
|
||||
```
|
||||
|
||||
### Example — Strategic Decision
|
||||
|
||||
After presenting the full strategic analysis with pillar alignment:
|
||||
|
||||
```
|
||||
AskUserQuestion:
|
||||
questions:
|
||||
- question: "How should we handle crafting scope for Alpha?"
|
||||
header: "Scope"
|
||||
options:
|
||||
- label: "Simplify to Core (Recommended)"
|
||||
description: "Recipe discovery only, 10 recipes — makes deadline, pillar visible"
|
||||
- label: "Full Implementation"
|
||||
description: "Complete system, 30 recipes — slips Alpha by 1 week"
|
||||
- label: "Cut Entirely"
|
||||
description: "Drop crafting, focus on combat — deadline met, pillar missing"
|
||||
```
|
||||
|
||||
### Team Skill Orchestration
|
||||
|
||||
In team skills, subagents return their analysis as text. The **orchestrator**
|
||||
(main session) calls `AskUserQuestion` at each decision point between phases:
|
||||
|
||||
```
|
||||
[game-designer returns 3 combat approaches with analysis]
|
||||
|
||||
Orchestrator uses AskUserQuestion:
|
||||
question: "Which combat approach should we develop?"
|
||||
options: [concise summaries of the 3 approaches]
|
||||
|
||||
[User picks → orchestrator passes decision to next phase]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📄 File Writing Protocol
|
||||
|
||||
### NEVER Write Files Without Explicit Approval
|
||||
@@ -352,6 +473,39 @@ Every file write must follow:
|
||||
[Returns to step 1]
|
||||
```
|
||||
|
||||
### Incremental Section Writing (Design Documents)
|
||||
|
||||
For multi-section documents (design docs, lore entries, architecture docs), write
|
||||
each section to the file as it's approved instead of building the full document
|
||||
in conversation. This prevents context overflow during long iterative sessions.
|
||||
|
||||
```
|
||||
1. Agent creates file with skeleton (all section headers, empty bodies)
|
||||
Agent: "May I create design/gdd/crafting-system.md with the section skeleton?"
|
||||
User: "Yes"
|
||||
|
||||
2. For EACH section:
|
||||
Agent: [Drafts section in conversation]
|
||||
User: [Reviews, requests changes]
|
||||
Agent: [Revises until approved]
|
||||
Agent: "May I write this section to the file?"
|
||||
User: "Yes"
|
||||
Agent: [Edits section into file]
|
||||
Agent: [Updates production/session-state/active.md with progress]
|
||||
─── Context for this section can now be safely compacted ───
|
||||
─── The decisions are IN THE FILE ───
|
||||
|
||||
3. If session crashes or compacts mid-document:
|
||||
Agent: [Reads the file — completed sections are all there]
|
||||
Agent: [Reads production/session-state/active.md — knows what's next]
|
||||
Agent: "Sections 1-4 are complete. Ready to work on section 5?"
|
||||
```
|
||||
|
||||
Why this matters: A full design doc session with 8 sections and 2-3 revision
|
||||
cycles per section can accumulate 30-50k tokens of conversation. Incremental
|
||||
writing keeps the live context at ~3-5k tokens (only the current section's
|
||||
discussion), because completed sections are persisted to disk.
|
||||
|
||||
### Multi-File Writes
|
||||
|
||||
When a change affects multiple files:
|
||||
@@ -455,21 +609,6 @@ The orchestration is automated, but **decision points stay with the user**.
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Updating All Documentation
|
||||
|
||||
This principle needs to be embedded in:
|
||||
|
||||
### Files to Update:
|
||||
|
||||
1. **CLAUDE.md** — Add "Collaboration Protocol" section
|
||||
2. **WORKFLOW-GUIDE.md** — Rewrite all "What happens" sections
|
||||
3. **Agent Roster** — Add "Questions to Ask" to each agent description
|
||||
4. **.claude/agents/*.md** — Update system prompts to enforce this
|
||||
5. **Skills** — Update all skills to ask before writing
|
||||
6. **README.md** — Clarify this is collaborative, not autonomous
|
||||
|
||||
---
|
||||
|
||||
## ✅ Quick Validation: Is Your Session Collaborative?
|
||||
|
||||
After any agent interaction, check:
|
||||
@@ -537,14 +676,13 @@ WHEN implementing:
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Next Steps
|
||||
## Implementation Status
|
||||
|
||||
To fully implement this principle:
|
||||
This principle has been fully embedded across the project:
|
||||
|
||||
1. **Update CLAUDE.md** with collaboration protocol
|
||||
2. **Update agent definitions** to enforce question-asking
|
||||
3. **Update WORKFLOW-GUIDE.md** to show collaborative examples
|
||||
4. **Update all skills** to require approval before writing
|
||||
5. **Add /collaborative-check skill** to audit if sessions are collaborative
|
||||
|
||||
Would you like me to implement these updates now?
|
||||
- **CLAUDE.md** — Collaboration protocol section added
|
||||
- **All 48 agent definitions** — Updated to enforce question-asking and approval
|
||||
- **All skills** — Updated to require approval before writing
|
||||
- **WORKFLOW-GUIDE.md** — Rewritten with collaborative examples
|
||||
- **README.md** — Clarifies collaborative (not autonomous) design
|
||||
- **AskUserQuestion tool** — Integrated into 10 skills for structured option UI
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
> **How to go from zero to a shipped game using the Agent Architecture.**
|
||||
>
|
||||
> This guide walks you through every phase of game development using the
|
||||
> 48-agent system, 35 slash commands, and automated hooks. It assumes you
|
||||
> 48-agent system, 36 slash commands, and automated hooks. It assumes you
|
||||
> have Claude Code installed and are working from the project root.
|
||||
|
||||
---
|
||||
@@ -252,7 +252,31 @@ Also define **anti-pillars** -- things your game intentionally avoids:
|
||||
You create all the design documents that define how your game works. Nothing
|
||||
gets coded yet -- this is pure design and architecture.
|
||||
|
||||
### Step 2.1: Create the Game Design Document (GDD)
|
||||
### Step 2.1: Decompose Your Concept Into Systems
|
||||
|
||||
Before writing individual GDDs, enumerate all the systems your game needs:
|
||||
|
||||
```
|
||||
/design-systems map
|
||||
```
|
||||
|
||||
This creates `design/gdd/systems-index.md` — a master tracking document that:
|
||||
|
||||
- Lists every system your game needs (combat, movement, UI, etc.)
|
||||
- Maps dependencies between systems
|
||||
- Assigns priority tiers (MVP, Vertical Slice, Alpha, Full Vision)
|
||||
- Determines design order (Foundation → Core → Feature → Presentation → Polish)
|
||||
|
||||
Then design each system in dependency order:
|
||||
|
||||
```
|
||||
/design-systems next
|
||||
```
|
||||
|
||||
This picks the highest-priority undesigned system and guides you through creating
|
||||
its GDD. Each completed GDD goes through `/design-review` before the next starts.
|
||||
|
||||
### Step 2.2: Create the Game Design Document (GDD)
|
||||
|
||||
For each major system in your game, create a design document in `design/gdd/`.
|
||||
Use the template:
|
||||
@@ -1690,7 +1714,7 @@ conflicts go to `producer`.
|
||||
|-------|----------|
|
||||
| **Onboarding** | `/start` |
|
||||
| **Ideation** | `/brainstorm` |
|
||||
| **Design** | `/design-review`, `/architecture-decision` |
|
||||
| **Design** | `/design-systems`, `/design-review`, `/architecture-decision` |
|
||||
| **Sprint** | `/sprint-plan`, `/estimate`, `/scope-check`, `/retrospective` |
|
||||
| **Implementation** | `/code-review`, `/prototype`, `/tech-debt` |
|
||||
| **Testing** | `/balance-check`, `/playtest-report`, `/perf-profile` |
|
||||
|
||||
@@ -91,6 +91,12 @@ All examples follow the **collaborative workflow pattern:**
|
||||
Question → Options → Decision → Draft → Approval
|
||||
```
|
||||
|
||||
> **Note:** These examples show the collaborative pattern as conversational text.
|
||||
> In practice, agents now use the `AskUserQuestion` tool at decision points to
|
||||
> present structured option pickers (with labels, descriptions, and multi-select).
|
||||
> The pattern is **Explain → Capture**: agents explain their analysis in
|
||||
> conversation first, then present a structured UI picker for the user's decision.
|
||||
|
||||
### ✅ **Collaborative Behaviors Shown:**
|
||||
|
||||
1. **Agents Ask Before Assuming**
|
||||
|
||||
Reference in New Issue
Block a user