mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
Release v0.4.0: /consistency-check, skill fixes, genre-agnostic agents
New skill: /consistency-check — cross-GDD entity registry scanner New registries: design/registry/entities.yaml, docs/registry/architecture.yaml Skill fixes: no-arg guards, verdict keywords, AskUserQuestion gates on all team-* skills Agent fixes: genre-agnostic language in game-designer, systems-designer, economy-designer, live-ops-designer Docs: skill/template counts corrected, stale references cleaned up Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Donchitos
@@ -8,96 +8,96 @@ context: fork
|
||||
agent: lead-programmer
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
## Phase 1: Load Target Files
|
||||
|
||||
1. **Read the target file(s)** in full.
|
||||
Read the target file(s) in full. Read CLAUDE.md for project coding standards.
|
||||
|
||||
2. **Read the CLAUDE.md** for project coding standards.
|
||||
---
|
||||
|
||||
2.5. **Identify the active engine specialists** by reading `.claude/docs/technical-preferences.md`, section `## Engine Specialists`. Note:
|
||||
- The **Primary** specialist (used for architecture and broad engine concerns)
|
||||
- The **Language/Code Specialist** (used when reviewing the project's primary language files)
|
||||
- The **Shader Specialist** (used when reviewing shader files)
|
||||
- The **UI Specialist** (used when reviewing UI code)
|
||||
- If the section reads `[TO BE CONFIGURED]`, no engine is pinned — skip engine specialist steps below.
|
||||
## Phase 2: Identify Engine Specialists
|
||||
|
||||
3. **ADR Compliance Check**:
|
||||
Read `.claude/docs/technical-preferences.md`, section `## Engine Specialists`. Note:
|
||||
|
||||
a. Search for ADR references in: the story file associated with this work (if
|
||||
provided), any commit message context, and header comments in the files being
|
||||
reviewed. Look for patterns like `ADR-NNN`, `ADR-[name]`, or
|
||||
`docs/architecture/ADR-`.
|
||||
- The **Primary** specialist (used for architecture and broad engine concerns)
|
||||
- The **Language/Code Specialist** (used when reviewing the project's primary language files)
|
||||
- The **Shader Specialist** (used when reviewing shader files)
|
||||
- The **UI Specialist** (used when reviewing UI code)
|
||||
|
||||
b. If no ADR references are found, note:
|
||||
> "No ADR references found — skipping ADR compliance check."
|
||||
Then proceed to step 4.
|
||||
If the section reads `[TO BE CONFIGURED]`, no engine is pinned — skip engine specialist steps.
|
||||
|
||||
c. For each referenced ADR: read `docs/architecture/ADR-NNN-*.md` and extract
|
||||
the **Decision** and **Consequences** sections.
|
||||
---
|
||||
|
||||
d. Check the implementation against each ADR:
|
||||
- What pattern/approach was chosen in the Decision?
|
||||
- Are there alternatives explicitly rejected in the ADR?
|
||||
- Are there required guardrails or constraints in the Consequences?
|
||||
## Phase 3: ADR Compliance Check
|
||||
|
||||
e. Classify any deviation found:
|
||||
- **ARCHITECTURAL VIOLATION** (BLOCKING): Implementation uses a pattern
|
||||
explicitly rejected in the ADR (e.g., ADR rejected singletons for game
|
||||
state, but the code uses a singleton).
|
||||
- **ADR DRIFT** (WARNING): Implementation diverges meaningfully from the
|
||||
chosen approach without using an explicitly forbidden pattern (e.g., ADR
|
||||
chose event-based communication but code uses direct method calls).
|
||||
- **MINOR DEVIATION** (INFO): Small difference from ADR guidance that does
|
||||
not affect the overall architecture (e.g., slightly different naming from
|
||||
the ADR's example code).
|
||||
Search for ADR references in the story file, commit messages, and header comments. Look for patterns like `ADR-NNN` or `docs/architecture/ADR-`.
|
||||
|
||||
f. Include ADR compliance findings in the review output under
|
||||
`### ADR Compliance` before the Standards Compliance section.
|
||||
If no ADR references found, note: "No ADR references found — skipping ADR compliance check."
|
||||
|
||||
4. **Identify the system category** (engine, gameplay, AI, networking, UI, tools)
|
||||
and apply category-specific standards.
|
||||
For each referenced ADR: read the file, extract the **Decision** and **Consequences** sections, then classify any deviation:
|
||||
|
||||
5. **Evaluate against coding standards**:
|
||||
- [ ] Public methods and classes have doc comments
|
||||
- [ ] Cyclomatic complexity under 10 per method
|
||||
- [ ] No method exceeds 40 lines (excluding data declarations)
|
||||
- [ ] Dependencies are injected (no static singletons for game state)
|
||||
- [ ] Configuration values loaded from data files
|
||||
- [ ] Systems expose interfaces (not concrete class dependencies)
|
||||
- **ARCHITECTURAL VIOLATION** (BLOCKING): Uses a pattern explicitly rejected in the ADR
|
||||
- **ADR DRIFT** (WARNING): Meaningfully diverges from the chosen approach without using a forbidden pattern
|
||||
- **MINOR DEVIATION** (INFO): Small difference from ADR guidance that doesn't affect overall architecture
|
||||
|
||||
6. **Check architectural compliance**:
|
||||
- [ ] Correct dependency direction (engine <- gameplay, not reverse)
|
||||
- [ ] No circular dependencies between modules
|
||||
- [ ] Proper layer separation (UI does not own game state)
|
||||
- [ ] Events/signals used for cross-system communication
|
||||
- [ ] Consistent with established patterns in the codebase
|
||||
---
|
||||
|
||||
7. **Check SOLID compliance**:
|
||||
- [ ] Single Responsibility: Each class has one reason to change
|
||||
- [ ] Open/Closed: Extendable without modification
|
||||
- [ ] Liskov Substitution: Subtypes substitutable for base types
|
||||
- [ ] Interface Segregation: No fat interfaces
|
||||
- [ ] Dependency Inversion: Depends on abstractions, not concretions
|
||||
## Phase 4: Standards Compliance
|
||||
|
||||
8. **Check for common game development issues**:
|
||||
- [ ] Frame-rate independence (delta time usage)
|
||||
- [ ] No allocations in hot paths (update loops)
|
||||
- [ ] Proper null/empty state handling
|
||||
- [ ] Thread safety where required
|
||||
- [ ] Resource cleanup (no leaks)
|
||||
Identify the system category (engine, gameplay, AI, networking, UI, tools) and evaluate:
|
||||
|
||||
9. **Engine Specialist Review** — If an engine is configured (step 2.5), spawn engine specialists via Task in parallel with your own review above:
|
||||
- Determine which specialist applies to each file being reviewed:
|
||||
- Primary language files (`.gd`, `.cs`, `.cpp`) → Language/Code Specialist
|
||||
- Shader files (`.gdshader`, `.hlsl`, shader graph) → Shader Specialist
|
||||
- UI screen/widget code → UI Specialist
|
||||
- Cross-cutting or unclear → Primary Specialist
|
||||
- Spawn the relevant specialist(s) with: the file(s), the engine reference docs path (`docs/engine-reference/[engine]/`), and the task: "Review for engine-idiomatic patterns, deprecated or incorrect API usage, engine-specific performance concerns, and any patterns the engine's documentation recommends against."
|
||||
- Also spawn the **Primary Specialist** for any file that touches engine architecture (scene structure, node hierarchy, component design, lifecycle hooks).
|
||||
- Collect findings and include them in the review output under `### Engine Specialist Findings` (placed between `### Game-Specific Concerns` and `### Positive Observations`).
|
||||
- If no engine is configured, omit the `### Engine Specialist Findings` section.
|
||||
- [ ] Public methods and classes have doc comments
|
||||
- [ ] Cyclomatic complexity under 10 per method
|
||||
- [ ] No method exceeds 40 lines (excluding data declarations)
|
||||
- [ ] Dependencies are injected (no static singletons for game state)
|
||||
- [ ] Configuration values loaded from data files
|
||||
- [ ] Systems expose interfaces (not concrete class dependencies)
|
||||
|
||||
10. **Output the review** in this format:
|
||||
---
|
||||
|
||||
## Phase 5: Architecture and SOLID
|
||||
|
||||
**Architecture:**
|
||||
- [ ] Correct dependency direction (engine <- gameplay, not reverse)
|
||||
- [ ] No circular dependencies between modules
|
||||
- [ ] Proper layer separation (UI does not own game state)
|
||||
- [ ] Events/signals used for cross-system communication
|
||||
- [ ] Consistent with established patterns in the codebase
|
||||
|
||||
**SOLID:**
|
||||
- [ ] Single Responsibility: Each class has one reason to change
|
||||
- [ ] Open/Closed: Extendable without modification
|
||||
- [ ] Liskov Substitution: Subtypes substitutable for base types
|
||||
- [ ] Interface Segregation: No fat interfaces
|
||||
- [ ] Dependency Inversion: Depends on abstractions, not concretions
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Game-Specific Concerns
|
||||
|
||||
- [ ] Frame-rate independence (delta time usage)
|
||||
- [ ] No allocations in hot paths (update loops)
|
||||
- [ ] Proper null/empty state handling
|
||||
- [ ] Thread safety where required
|
||||
- [ ] Resource cleanup (no leaks)
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Engine Specialist Review
|
||||
|
||||
If an engine is configured, spawn engine specialists via Task in parallel with the review above. Determine which specialist applies to each file:
|
||||
|
||||
- Primary language files (`.gd`, `.cs`, `.cpp`) → Language/Code Specialist
|
||||
- Shader files (`.gdshader`, `.hlsl`, shader graph) → Shader Specialist
|
||||
- UI screen/widget code → UI Specialist
|
||||
- Cross-cutting or unclear → Primary Specialist
|
||||
|
||||
Also spawn the **Primary Specialist** for any file touching engine architecture (scene structure, node hierarchy, lifecycle hooks).
|
||||
|
||||
Collect findings and include them under `### Engine Specialist Findings`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 8: Output Review
|
||||
|
||||
```
|
||||
## Code Review: [File/System Name]
|
||||
@@ -131,3 +131,13 @@ When this skill is invoked:
|
||||
|
||||
### Verdict: [APPROVED / APPROVED WITH SUGGESTIONS / CHANGES REQUIRED]
|
||||
```
|
||||
|
||||
This skill is read-only — no files are written.
|
||||
|
||||
---
|
||||
|
||||
## Phase 9: Next Steps
|
||||
|
||||
- If verdict is APPROVED: run `/story-done [story-path]` to close the story.
|
||||
- If verdict is CHANGES REQUIRED: fix the issues and re-run `/code-review`.
|
||||
- If an ARCHITECTURAL VIOLATION is found: run `/architecture-decision` to record the correct approach.
|
||||
|
||||
Reference in New Issue
Block a user