mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
b1cad29b68
## New Skills (9) - /quick-design: lightweight spec path for small changes (bypasses full GDD pipeline) - /story-readiness: validates stories are implementation-ready before pickup - /story-done: end-of-story completion review (criteria verification, deviation check, status update) - /sprint-status: fast 30-line sprint snapshot, read-only - /ux-design: guided section-by-section UX spec authoring (screen/flow/HUD/patterns) - /ux-review: UX spec validation with APPROVED/NEEDS REVISION/MAJOR REVISION verdict - /architecture-review, /create-architecture, /create-control-manifest, /create-epics-stories, /propagate-design-change, /review-all-gdds (pipeline completion) ## New Templates (7) - player-journey.md: 6-phase emotional arc, critical moments, retention hooks - difficulty-curve.md: difficulty axes, onboarding ramp, cross-system interactions - ux-spec.md: per-screen UX spec with states, interaction map, data requirements, events - hud-design.md: whole-game HUD with philosophy, info architecture, element specs - accessibility-requirements.md: project-wide accessibility tier commitment and audit - interaction-pattern-library.md: 26 standard + game-specific patterns with full state specs - architecture-traceability.md: GDD requirements to ADR coverage matrix ## Updated Skills & Templates - gate-check: Vertical Slice hard gate, playtesting strengthened, UX artifacts required - team-ui: full UX pipeline integration (/ux-design + /ux-review + accessibility-specialist) - game-design-document: Game Feel section (input latency, animation frames, impact moments) - implementation-agent-protocol: /story-done as explicit final step of every story - architecture-decision, design-system: pipeline completion updates Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
164 lines
4.8 KiB
Markdown
164 lines
4.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]
|
|
|
|
## Engine Compatibility
|
|
|
|
| Field | Value |
|
|
|-------|-------|
|
|
| **Engine** | [e.g. Godot 4.6 / Unity 6 / Unreal Engine 5.4] |
|
|
| **Domain** | [Physics / Rendering / UI / Audio / Navigation / Animation / Networking / Core / Input / Scripting] |
|
|
| **Knowledge Risk** | [LOW — in training data / MEDIUM — near cutoff, verify / HIGH — post-cutoff, must verify] |
|
|
| **References Consulted** | [e.g. `docs/engine-reference/godot/modules/physics.md`, `breaking-changes.md`] |
|
|
| **Post-Cutoff APIs Used** | [Specific APIs from post-cutoff engine versions this decision depends on, or "None"] |
|
|
| **Verification Required** | [Concrete behaviours to test against the target engine version before shipping, or "None"] |
|
|
|
|
> **Note**: If Knowledge Risk is MEDIUM or HIGH, this ADR must be re-validated if the
|
|
> project upgrades engine versions. Flag it as "Superseded" and write a new ADR.
|
|
|
|
## ADR Dependencies
|
|
|
|
| Field | Value |
|
|
|-------|-------|
|
|
| **Depends On** | [ADR-NNNN (must be Accepted before this can be implemented), or "None"] |
|
|
| **Enables** | [ADR-NNNN (this ADR unlocks that decision), or "None"] |
|
|
| **Blocks** | [Epic/Story name — cannot start until this ADR is Accepted, or "None"] |
|
|
| **Ordering Note** | [Any sequencing constraint that isn't captured above] |
|
|
|
|
## 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]
|
|
|
|
## GDD Requirements Addressed
|
|
|
|
<!-- This section is MANDATORY. Every ADR must trace back to at least one GDD
|
|
requirement, or explicitly state it is a foundational decision with no GDD
|
|
dependency. Traceability is audited by /architecture-review. -->
|
|
|
|
| GDD Document | System | Requirement | How This ADR Satisfies It |
|
|
|-------------|--------|-------------|--------------------------|
|
|
| [e.g. `design/gdd/combat.md`] | [e.g. Combat] | [e.g. "Hitbox detection must resolve within 1 frame"] | [e.g. "Jolt physics collision queries run synchronously in _physics_process"] |
|
|
|
|
> If this is a foundational decision with no direct GDD dependency, write:
|
|
> "Foundational — no GDD requirement. Enables: [list what GDD systems this
|
|
> decision unlocks or constrains]"
|
|
|
|
## Related
|
|
|
|
- [Link to related ADRs — note if supersedes, contradicts, or depends on]
|
|
- [Link to relevant code files once implemented]
|