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>
101 lines
2.4 KiB
Markdown
101 lines
2.4 KiB
Markdown
---
|
|
name: architecture-decision
|
|
description: "Creates an Architecture Decision Record (ADR) documenting a significant technical decision, its context, alternatives considered, and consequences. Every major technical choice should have an ADR."
|
|
argument-hint: "[title]"
|
|
user-invocable: true
|
|
allowed-tools: Read, Glob, Grep, Write
|
|
---
|
|
|
|
When this skill is invoked:
|
|
|
|
1. **Determine the next ADR number** by scanning `docs/architecture/` for
|
|
existing ADRs.
|
|
|
|
2. **Gather context** by reading related code and existing ADRs.
|
|
|
|
3. **Guide the user through the decision** by asking clarifying questions if
|
|
the title alone is not sufficient.
|
|
|
|
4. **Generate the ADR** following this format:
|
|
|
|
```markdown
|
|
# ADR-[NNNN]: [Title]
|
|
|
|
## Status
|
|
[Proposed | Accepted | Deprecated | Superseded by ADR-XXXX]
|
|
|
|
## Date
|
|
[Date of decision]
|
|
|
|
## Context
|
|
|
|
### Problem Statement
|
|
[What problem are we solving? Why does this decision need to be made now?]
|
|
|
|
### Constraints
|
|
- [Technical constraints]
|
|
- [Timeline constraints]
|
|
- [Resource constraints]
|
|
- [Compatibility requirements]
|
|
|
|
### Requirements
|
|
- [Must support X]
|
|
- [Must perform within Y budget]
|
|
- [Must integrate with Z]
|
|
|
|
## Decision
|
|
|
|
[The specific technical decision made, described in enough detail for someone
|
|
to implement it.]
|
|
|
|
### Architecture Diagram
|
|
[ASCII diagram or description of the system architecture this creates]
|
|
|
|
### Key Interfaces
|
|
[API contracts or interface definitions this decision creates]
|
|
|
|
## Alternatives Considered
|
|
|
|
### Alternative 1: [Name]
|
|
- **Description**: [How this would work]
|
|
- **Pros**: [Advantages]
|
|
- **Cons**: [Disadvantages]
|
|
- **Rejection Reason**: [Why this was not chosen]
|
|
|
|
### Alternative 2: [Name]
|
|
- **Description**: [How this would work]
|
|
- **Pros**: [Advantages]
|
|
- **Cons**: [Disadvantages]
|
|
- **Rejection Reason**: [Why this was not chosen]
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
- [Good outcomes of this decision]
|
|
|
|
### Negative
|
|
- [Trade-offs and costs accepted]
|
|
|
|
### Risks
|
|
- [Things that could go wrong]
|
|
- [Mitigation for each risk]
|
|
|
|
## Performance Implications
|
|
- **CPU**: [Expected impact]
|
|
- **Memory**: [Expected impact]
|
|
- **Load Time**: [Expected impact]
|
|
- **Network**: [Expected impact, if applicable]
|
|
|
|
## Migration Plan
|
|
[If this changes existing code, how do we get from here to there?]
|
|
|
|
## Validation Criteria
|
|
[How will we know this decision was correct? What metrics or tests?]
|
|
|
|
## Related Decisions
|
|
- [Links to related ADRs]
|
|
- [Links to related design documents]
|
|
```
|
|
|
|
5. **Save the ADR** to `docs/architecture/adr-[NNNN]-[slug].md`.
|