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>

.claude/docs/coding-standards.md

@@ -0,0 +1,25 @@
+# Coding Standards
+
+- All game code must include doc comments on public APIs
+- Every system must have a corresponding architecture decision record in `docs/architecture/`
+- Gameplay values must be data-driven (external config), never hardcoded
+- All public methods must be unit-testable (dependency injection over singletons)
+- Commits must reference the relevant design document or task ID
+- **Verification-driven development**: Write tests first when adding gameplay systems.
+  For UI changes, verify with screenshots. Compare expected output to actual output
+  before marking work complete. Every implementation should have a way to prove it works.
+
+# Design Document Standards
+
+- All design docs use Markdown
+- Each mechanic has a dedicated document in `design/gdd/`
+- Documents must include these 8 required sections:
+  1. **Overview** -- one-paragraph summary
+  2. **Player Fantasy** -- intended feeling and experience
+  3. **Detailed Rules** -- unambiguous mechanics
+  4. **Formulas** -- all math defined with variables
+  5. **Edge Cases** -- unusual situations handled
+  6. **Dependencies** -- other systems listed
+  7. **Tuning Knobs** -- configurable values identified
+  8. **Acceptance Criteria** -- testable success conditions
+- Balance values must link to their source formula or rationale