mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 04:51:46 +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
@@ -6,110 +6,120 @@ user-invocable: true
|
||||
agent: performance-analyst
|
||||
allowed-tools: Read, Glob, Grep, Bash
|
||||
---
|
||||
When this skill is invoked:
|
||||
|
||||
1. **Determine scope** from the argument:
|
||||
- If a system name: focus profiling on that specific system
|
||||
- If `full`: run a comprehensive profile across all systems
|
||||
## Phase 1: Determine Scope
|
||||
|
||||
2. **Read performance budgets** — Check for existing performance targets in design docs or CLAUDE.md:
|
||||
- Target FPS (e.g., 60fps = 16.67ms frame budget)
|
||||
- Memory budget (total and per-system)
|
||||
- Load time targets
|
||||
- Draw call budgets
|
||||
- Network bandwidth limits (if multiplayer)
|
||||
Read the argument:
|
||||
|
||||
3. **Analyze the codebase** for common performance issues:
|
||||
- System name → focus profiling on that specific system
|
||||
- `full` → run a comprehensive profile across all systems
|
||||
|
||||
**CPU Profiling Targets**:
|
||||
- `_process()` / `Update()` / `Tick()` functions — list all and estimate cost
|
||||
- Nested loops over large collections
|
||||
- String operations in hot paths
|
||||
- Allocation patterns in per-frame code
|
||||
- Unoptimized search/sort over game entities
|
||||
- Expensive physics queries (raycasts, overlaps) every frame
|
||||
---
|
||||
|
||||
**Memory Profiling Targets**:
|
||||
- Large data structures and their growth patterns
|
||||
- Texture/asset memory footprint estimates
|
||||
- Object pool vs instantiate/destroy patterns
|
||||
- Leaked references (objects that should be freed but aren't)
|
||||
- Cache sizes and eviction policies
|
||||
## Phase 2: Load Performance Budgets
|
||||
|
||||
**Rendering Targets** (if applicable):
|
||||
- Draw call estimates
|
||||
- Overdraw from overlapping transparent objects
|
||||
- Shader complexity
|
||||
- Unoptimized particle systems
|
||||
- Missing LODs or occlusion culling
|
||||
Check for existing performance targets in design docs or CLAUDE.md:
|
||||
|
||||
**I/O Targets**:
|
||||
- Save/load performance
|
||||
- Asset loading patterns (sync vs async)
|
||||
- Network message frequency and size
|
||||
- Target FPS (e.g., 60fps = 16.67ms frame budget)
|
||||
- Memory budget (total and per-system)
|
||||
- Load time targets
|
||||
- Draw call budgets
|
||||
- Network bandwidth limits (if multiplayer)
|
||||
|
||||
4. **Generate the profiling report**:
|
||||
---
|
||||
|
||||
```markdown
|
||||
## Performance Profile: [System or Full]
|
||||
Generated: [Date]
|
||||
## Phase 3: Analyze Codebase
|
||||
|
||||
### Performance Budgets
|
||||
| Metric | Budget | Estimated Current | Status |
|
||||
|--------|--------|-------------------|--------|
|
||||
| Frame time | [16.67ms] | [estimate] | [OK/WARNING/OVER] |
|
||||
| Memory | [target] | [estimate] | [OK/WARNING/OVER] |
|
||||
| Load time | [target] | [estimate] | [OK/WARNING/OVER] |
|
||||
| Draw calls | [target] | [estimate] | [OK/WARNING/OVER] |
|
||||
**CPU Profiling Targets:**
|
||||
- `_process()` / `Update()` / `Tick()` functions — list all and estimate cost
|
||||
- Nested loops over large collections
|
||||
- String operations in hot paths
|
||||
- Allocation patterns in per-frame code
|
||||
- Unoptimized search/sort over game entities
|
||||
- Expensive physics queries (raycasts, overlaps) every frame
|
||||
|
||||
### Hotspots Identified
|
||||
| # | Location | Issue | Estimated Impact | Fix Effort |
|
||||
|---|----------|-------|------------------|------------|
|
||||
| 1 | [file:line] | [description] | [High/Med/Low] | [S/M/L] |
|
||||
| 2 | [file:line] | [description] | [High/Med/Low] | [S/M/L] |
|
||||
**Memory Profiling Targets:**
|
||||
- Large data structures and their growth patterns
|
||||
- Texture/asset memory footprint estimates
|
||||
- Object pool vs instantiate/destroy patterns
|
||||
- Leaked references (objects that should be freed but aren't)
|
||||
- Cache sizes and eviction policies
|
||||
|
||||
### Optimization Recommendations (Priority Order)
|
||||
1. **[Title]** — [Description of the optimization]
|
||||
- Location: [file:line]
|
||||
- Expected gain: [estimate]
|
||||
- Risk: [Low/Med/High]
|
||||
- Approach: [How to implement]
|
||||
**Rendering Targets (if applicable):**
|
||||
- Draw call estimates
|
||||
- Overdraw from overlapping transparent objects
|
||||
- Shader complexity
|
||||
- Unoptimized particle systems
|
||||
- Missing LODs or occlusion culling
|
||||
|
||||
### Quick Wins (< 1 hour each)
|
||||
- [Simple optimization 1]
|
||||
- [Simple optimization 2]
|
||||
**I/O Targets:**
|
||||
- Save/load performance
|
||||
- Asset loading patterns (sync vs async)
|
||||
- Network message frequency and size
|
||||
|
||||
### Requires Investigation
|
||||
- [Area that needs actual runtime profiling to determine impact]
|
||||
```
|
||||
---
|
||||
|
||||
5. **Output the report** with a summary: top 3 hotspots, estimated headroom vs budget, and recommended next action.
|
||||
## Phase 4: Generate Profiling Report
|
||||
|
||||
6. **Scope & Timeline Decision** — activate this phase only if any hotspot has Fix Effort rated M or L.
|
||||
```markdown
|
||||
## Performance Profile: [System or Full]
|
||||
Generated: [Date]
|
||||
|
||||
Present a summary of the significant-effort items:
|
||||
### Performance Budgets
|
||||
| Metric | Budget | Estimated Current | Status |
|
||||
|--------|--------|-------------------|--------|
|
||||
| Frame time | [16.67ms] | [estimate] | [OK/WARNING/OVER] |
|
||||
| Memory | [target] | [estimate] | [OK/WARNING/OVER] |
|
||||
| Load time | [target] | [estimate] | [OK/WARNING/OVER] |
|
||||
| Draw calls | [target] | [estimate] | [OK/WARNING/OVER] |
|
||||
|
||||
> "The following optimizations require significant effort: [list titles and effort ratings from the Hotspots table]"
|
||||
### Hotspots Identified
|
||||
| # | Location | Issue | Estimated Impact | Fix Effort |
|
||||
|---|----------|-------|------------------|------------|
|
||||
|
||||
For each M/L item, ask the user to choose one of:
|
||||
### Optimization Recommendations (Priority Order)
|
||||
1. **[Title]** — [Description]
|
||||
- Location: [file:line]
|
||||
- Expected gain: [estimate]
|
||||
- Risk: [Low/Med/High]
|
||||
- Approach: [How to implement]
|
||||
|
||||
- **A) Implement the optimization** (estimated effort: [S/M/L] — proceed with fix now or schedule it)
|
||||
- **B) Reduce feature scope to avoid the bottleneck** (run `/scope-check [feature]` to analyze the trade-offs)
|
||||
- **C) Accept the performance hit and defer to Polish phase** (log it as a known issue)
|
||||
- **D) Escalate to technical-director for an architectural decision** (the bottleneck warrants an ADR)
|
||||
### Quick Wins (< 1 hour each)
|
||||
- [Simple optimization 1]
|
||||
|
||||
For choice B, remind the user:
|
||||
> "Run `/scope-check [feature]` to see what simplifications are available without sacrificing player experience."
|
||||
### Requires Investigation
|
||||
- [Area that needs actual runtime profiling to confirm impact]
|
||||
```
|
||||
|
||||
For choice D, note:
|
||||
> "A bottleneck requiring architectural change should become a new Architecture Decision Record. Run `/architecture-decision` to capture the decision and its trade-offs."
|
||||
Output the report with a summary: top 3 hotspots, estimated headroom vs budget, and recommended next action.
|
||||
|
||||
If multiple items are deferred to Polish (choice C), record them in the report under a `### Deferred to Polish` section so they are not lost.
|
||||
---
|
||||
|
||||
## Phase 5: Scope and Timeline Decision
|
||||
|
||||
Activate this phase only if any hotspot has Fix Effort rated M or L.
|
||||
|
||||
Present significant-effort items and ask the user to choose for each:
|
||||
|
||||
- **A) Implement the optimization** (proceed with fix now or schedule it)
|
||||
- **B) Reduce feature scope** (run `/scope-check [feature]` to analyze trade-offs)
|
||||
- **C) Accept the performance hit and defer to Polish phase** (log as known issue)
|
||||
- **D) Escalate to technical-director for an architectural decision** (run `/architecture-decision`)
|
||||
|
||||
If multiple items are deferred to Polish (choice C), record them under `### Deferred to Polish`.
|
||||
|
||||
This skill is read-only — no files are written. Verdict: **COMPLETE** — performance profile generated.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Next Steps
|
||||
|
||||
- If bottlenecks require architectural change: run `/architecture-decision`.
|
||||
- If scope reduction is needed: run `/scope-check [feature]`.
|
||||
- To schedule optimizations: run `/sprint-plan update`.
|
||||
|
||||
### Rules
|
||||
- Never optimize without measuring first — gut feelings about performance are unreliable
|
||||
- Recommendations must include estimated impact — "make it faster" is not actionable
|
||||
- Profile on target hardware, not just development machines
|
||||
- Distinguish between CPU-bound, GPU-bound, and I/O-bound bottlenecks
|
||||
- Consider worst-case scenarios (maximum entities, lowest spec hardware, worst network conditions)
|
||||
- Static analysis (this skill) identifies candidates; runtime profiling confirms
|
||||
|
||||
Reference in New Issue
Block a user