mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios
synced 2026-04-21 21:37:19 +00:00
ad540fe75d
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>
63 lines
2.3 KiB
Markdown
63 lines
2.3 KiB
Markdown
# Engine Reference Documentation
|
|
|
|
This directory contains curated, version-pinned documentation snapshots for the
|
|
game engine(s) used in this project. These files exist because **LLM knowledge
|
|
has a cutoff date** and game engines update frequently.
|
|
|
|
## Why This Exists
|
|
|
|
Claude's training data has a knowledge cutoff (currently May 2025). Game engines
|
|
like Godot, Unity, and Unreal ship updates that introduce breaking API changes,
|
|
new features, and deprecated patterns. Without these reference files, agents will
|
|
suggest outdated code.
|
|
|
|
## Structure
|
|
|
|
Each engine gets its own directory:
|
|
|
|
```
|
|
<engine>/
|
|
├── VERSION.md # Pinned version, verification date, knowledge gap window
|
|
├── breaking-changes.md # API changes between versions, organized by risk level
|
|
├── deprecated-apis.md # "Don't use X → Use Y" lookup tables
|
|
├── current-best-practices.md # New practices not in model training data
|
|
└── modules/ # Per-subsystem quick references (~150 lines max each)
|
|
├── rendering.md
|
|
├── physics.md
|
|
└── ...
|
|
```
|
|
|
|
## How Agents Use These Files
|
|
|
|
Engine-specialist agents are instructed to:
|
|
|
|
1. Read `VERSION.md` to confirm the current engine version
|
|
2. Check `deprecated-apis.md` before suggesting any engine API
|
|
3. Consult `breaking-changes.md` for version-specific concerns
|
|
4. Read relevant `modules/*.md` for subsystem-specific work
|
|
|
|
## Maintenance
|
|
|
|
### When to Update
|
|
|
|
- After upgrading the engine version
|
|
- When the LLM model is updated (new knowledge cutoff)
|
|
- After running `/refresh-docs` (if available)
|
|
- When you discover an API the model gets wrong
|
|
|
|
### How to Update
|
|
|
|
1. Update `VERSION.md` with the new engine version and date
|
|
2. Add new entries to `breaking-changes.md` for the version transition
|
|
3. Move newly deprecated APIs into `deprecated-apis.md`
|
|
4. Update `current-best-practices.md` with new patterns
|
|
5. Update relevant `modules/*.md` with API changes
|
|
6. Set "Last verified" dates on all modified files
|
|
|
|
### Quality Rules
|
|
|
|
- Every file must have a "Last verified: YYYY-MM-DD" date
|
|
- Keep module files under 150 lines (context budget)
|
|
- Include code examples showing correct/incorrect patterns
|
|
- Link to official documentation URLs for verification
|
|
- Only document things that differ from the model's training data
|