mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 04:51:46 +00:00
Game Studio Agent Architecture — complete setup (Phases 1-7)
48 coordinated Claude Code subagents for indie game development: - 3 leadership agents (creative-director, technical-director, producer) - 10 department leads (game-designer, lead-programmer, art-director, etc.) - 23 specialist agents (gameplay, engine, AI, networking, UI, tools, etc.) - 12 engine-specific agents (Godot, Unity, Unreal with sub-specialists) Infrastructure: - 34 skills (slash commands) for workflows, reviews, and team orchestration - 8 hooks for commit validation, asset checks, session management - 11 path-scoped rules enforcing domain-specific standards - 28 templates for design docs, reports, and collaborative protocols Key features: - User-driven collaboration protocol (Question → Options → Decision → Draft → Approval) - Engine version awareness with knowledge-gap detection (Godot 4.6 pinned) - Phase gate system for development milestone validation - CLAUDE.md kept under 80 lines with extracted doc imports Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
99
.claude/skills/prototype/SKILL.md
Normal file
99
.claude/skills/prototype/SKILL.md
Normal file
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: prototype
|
||||
description: "Rapid prototyping workflow. Skips normal standards to quickly validate a game concept or mechanic. Produces throwaway code and a structured prototype report."
|
||||
argument-hint: "[concept-description]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
|
||||
1. **Read the concept description** from the argument. Identify the core
|
||||
question this prototype must answer. If the concept is vague, state the
|
||||
question explicitly before proceeding.
|
||||
|
||||
2. **Read CLAUDE.md** for project context and the current tech stack. Understand
|
||||
what engine, language, and frameworks are in use so the prototype is built
|
||||
with compatible tooling.
|
||||
|
||||
3. **Create a prototype plan**: Define in 3-5 bullet points what the minimum
|
||||
viable prototype looks like. What is the core question? What is the absolute
|
||||
minimum code needed to answer it? What can be skipped?
|
||||
|
||||
4. **Create the prototype directory**: `prototypes/[concept-name]/` where
|
||||
`[concept-name]` is a short, kebab-case identifier derived from the concept.
|
||||
|
||||
5. **Implement the prototype** in the isolated directory. Every file must begin
|
||||
with:
|
||||
```
|
||||
// PROTOTYPE - NOT FOR PRODUCTION
|
||||
// Question: [Core question being tested]
|
||||
// Date: [Current date]
|
||||
```
|
||||
Standards are intentionally relaxed:
|
||||
- Hardcode values freely
|
||||
- Use placeholder assets
|
||||
- Skip error handling
|
||||
- Use the simplest approach that works
|
||||
- Copy code rather than importing from production
|
||||
|
||||
6. **Test the concept**: Run the prototype. Observe behavior. Collect any
|
||||
measurable data (frame times, interaction counts, feel assessments).
|
||||
|
||||
7. **Generate the Prototype Report** and save it to
|
||||
`prototypes/[concept-name]/REPORT.md`:
|
||||
|
||||
```markdown
|
||||
## Prototype Report: [Concept Name]
|
||||
|
||||
### Hypothesis
|
||||
[What we expected to be true -- the question we set out to answer]
|
||||
|
||||
### Approach
|
||||
[What we built, how long it took, what shortcuts we took]
|
||||
|
||||
### Result
|
||||
[What actually happened -- specific observations, not opinions]
|
||||
|
||||
### Metrics
|
||||
[Any measurable data collected during testing]
|
||||
- Frame time: [if relevant]
|
||||
- Feel assessment: [subjective but specific -- "response felt sluggish at
|
||||
200ms delay" not "felt bad"]
|
||||
- Player action counts: [if relevant]
|
||||
- Iteration count: [how many attempts to get it working]
|
||||
|
||||
### Recommendation: [PROCEED / PIVOT / KILL]
|
||||
|
||||
[One paragraph explaining the recommendation with evidence]
|
||||
|
||||
### If Proceeding
|
||||
[What needs to change for a production-quality implementation]
|
||||
- Architecture requirements
|
||||
- Performance targets
|
||||
- Scope adjustments from the original design
|
||||
- Estimated production effort
|
||||
|
||||
### If Pivoting
|
||||
[What alternative direction the results suggest]
|
||||
|
||||
### If Killing
|
||||
[Why this concept does not work and what we should do instead]
|
||||
|
||||
### Lessons Learned
|
||||
[Discoveries that affect other systems or future work]
|
||||
```
|
||||
|
||||
8. **Output a summary** to the user with: the core question, the result, and
|
||||
the recommendation. Link to the full report at
|
||||
`prototypes/[concept-name]/REPORT.md`.
|
||||
|
||||
### Important Constraints
|
||||
|
||||
- Prototype code must NEVER import from production source files
|
||||
- Production code must NEVER import from prototype directories
|
||||
- If the recommendation is PROCEED, the production implementation must be
|
||||
written from scratch -- prototype code is not refactored into production
|
||||
- Total prototype effort should be timeboxed to 1-3 days equivalent of work
|
||||
- If the prototype scope starts growing, stop and reassess whether the
|
||||
question can be simplified
|
||||
Reference in New Issue
Block a user