mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
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>
2.8 KiB
2.8 KiB
ADR-[NNNN]: [Title]
Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXXX]
Date
[YYYY-MM-DD]
Decision Makers
[Who was involved in this decision]
Context
Problem Statement
[What problem are we solving? Why must this decision be made now? What is the cost of not deciding?]
Current State
[How does the system work today? What is wrong with the current approach?]
Constraints
- [Technical constraints -- engine limitations, platform requirements]
- [Timeline constraints -- deadline pressures, dependencies]
- [Resource constraints -- team size, expertise available]
- [Compatibility requirements -- must work with existing systems]
Requirements
- [Functional requirement 1]
- [Functional requirement 2]
- [Performance requirement -- specific, measurable]
- [Scalability requirement]
Decision
[The specific technical decision, described in enough detail for someone to implement it without further clarification.]
Architecture
[ASCII diagram showing the system architecture this decision creates.
Show components, data flow direction, and key interfaces.]
Key Interfaces
[Pseudocode or language-specific interface definitions that this decision
creates. These become the contracts that implementers must respect.]
Implementation Guidelines
[Specific guidance for the programmer implementing this decision.]
Alternatives Considered
Alternative 1: [Name]
- Description: [How this approach would work]
- Pros: [What is good about this approach]
- Cons: [What is bad about this approach]
- Estimated Effort: [Relative effort compared to chosen approach]
- Rejection Reason: [Why this was not chosen]
Alternative 2: [Name]
[Same structure as above]
Consequences
Positive
- [Good outcomes of this decision]
Negative
- [Trade-offs and costs we are accepting]
Neutral
- [Changes that are neither good nor bad, just different]
Risks
| Risk | Probability | Impact | Mitigation |
|---|
Performance Implications
| Metric | Before | Expected After | Budget |
|---|---|---|---|
| CPU (frame time) | [X]ms | [Y]ms | [Z]ms |
| Memory | [X]MB | [Y]MB | [Z]MB |
| Load Time | [X]s | [Y]s | [Z]s |
| Network (if applicable) | [X]KB/s | [Y]KB/s | [Z]KB/s |
Migration Plan
[If this changes existing systems, the step-by-step plan to migrate.]
- [Step 1 -- what changes, what breaks, how to verify]
- [Step 2]
- [Step 3]
Rollback plan: [How to revert if this decision proves wrong]
Validation Criteria
[How we will know this decision was correct after implementation.]
- [Measurable criterion 1]
- [Measurable criterion 2]
- [Performance criterion]
Related
- [Link to related ADRs]
- [Link to related design documents]
- [Link to relevant code files]