mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +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>
128 lines
2.8 KiB
Markdown
128 lines
2.8 KiB
Markdown
# 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.]
|
|
|
|
1. [Step 1 -- what changes, what breaks, how to verify]
|
|
2. [Step 2]
|
|
3. [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]
|