mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
Model tier assignment: - model: haiku → help, sprint-status, story-readiness, scope-check, project-stage-detect, changelog, patch-notes, onboard (read-only/format) - model: opus → review-all-gdds, architecture-review, gate-check (multi-doc synthesis, high-stakes verdicts) PostCompact hook: - New .claude/hooks/post-compact.sh — fires after compaction, reminds Claude to re-read production/session-state/active.md to restore context - Registered in settings.json between PreCompact and Stop Parallel Task spawning: - review-all-gdds: Phase 2 (consistency) and Phase 3 (design theory) now explicitly instructed to spawn as parallel Task agents simultaneously Error Recovery Protocol: - Standard BLOCKED-handling section added to: review-all-gdds, architecture-review, dev-story, team-combat, team-qa, team-narrative, team-level, team-ui, team-audio, team-release, team-polish - Pattern: surface blocker → assess dependencies → offer 3 options via AskUserQuestion → always produce partial report Coordination rules: - Added Model Tier Assignment table with routing rationale - Added Subagents vs Agent Teams section (experimental agent teams docs) - Added Parallel Task Protocol (when/how to spawn parallel agents) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
109 lines
5.7 KiB
Markdown
109 lines
5.7 KiB
Markdown
---
|
|
name: team-polish
|
|
description: "Orchestrate the polish team: coordinates performance-analyst, technical-artist, sound-designer, and qa-tester to optimize, polish, and harden a feature or area for release quality."
|
|
argument-hint: "[feature or area to polish]"
|
|
user-invocable: true
|
|
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
|
---
|
|
When this skill is invoked, orchestrate the polish team through a structured pipeline.
|
|
|
|
**Decision Points:** At each phase transition, use `AskUserQuestion` to present
|
|
the user with the subagent's proposals as selectable options. Write the agent's
|
|
full analysis in conversation, then capture the decision with concise labels.
|
|
The user must approve before moving to the next phase.
|
|
|
|
## Team Composition
|
|
- **performance-analyst** — Profiling, optimization, memory analysis, frame budget
|
|
- **engine-programmer** — Engine-level bottlenecks: rendering pipeline, memory, resource loading (invoke when performance-analyst identifies low-level root causes)
|
|
- **technical-artist** — VFX polish, shader optimization, visual quality
|
|
- **sound-designer** — Audio polish, mixing, ambient layers, feedback sounds
|
|
- **tools-programmer** — Content pipeline tool verification, editor tool stability, automation fixes (invoke when content authoring tools are involved in the polished area)
|
|
- **qa-tester** — Edge case testing, regression testing, soak testing
|
|
|
|
## How to Delegate
|
|
|
|
Use the Task tool to spawn each team member as a subagent:
|
|
- `subagent_type: performance-analyst` — Profiling, optimization, memory analysis
|
|
- `subagent_type: engine-programmer` — Engine-level fixes for rendering, memory, resource loading
|
|
- `subagent_type: technical-artist` — VFX polish, shader optimization, visual quality
|
|
- `subagent_type: sound-designer` — Audio polish, mixing, ambient layers
|
|
- `subagent_type: tools-programmer` — Content pipeline and editor tool verification
|
|
- `subagent_type: qa-tester` — Edge case testing, regression testing, soak testing
|
|
|
|
Always provide full context in each agent's prompt (target feature/area, performance budgets, known issues). Launch independent agents in parallel where the pipeline allows it (e.g., Phases 3 and 4 can run simultaneously).
|
|
|
|
## Pipeline
|
|
|
|
### Phase 1: Assessment
|
|
Delegate to **performance-analyst**:
|
|
- Profile the target feature/area using `/perf-profile`
|
|
- Identify performance bottlenecks and frame budget violations
|
|
- Measure memory usage and check for leaks
|
|
- Benchmark against target hardware specs
|
|
- Output: performance report with prioritized optimization list
|
|
|
|
### Phase 2: Optimization
|
|
Delegate to **performance-analyst** (with relevant programmers as needed):
|
|
- Fix performance hotspots identified in Phase 1
|
|
- Optimize draw calls, reduce overdraw
|
|
- Fix memory leaks and reduce allocation pressure
|
|
- Verify optimizations don't change gameplay behavior
|
|
- Output: optimized code with before/after metrics
|
|
|
|
If Phase 1 identified engine-level root causes (rendering pipeline, resource loading, memory allocator), delegate those fixes to **engine-programmer** in parallel:
|
|
- Optimize hot paths in engine systems
|
|
- Fix allocation pressure in core loops
|
|
- Output: engine-level fixes with profiler validation
|
|
|
|
### Phase 3: Visual Polish (parallel with Phase 2)
|
|
Delegate to **technical-artist**:
|
|
- Review VFX for quality and consistency with art bible
|
|
- Optimize particle systems and shader effects
|
|
- Add screen shake, camera effects, and visual juice where appropriate
|
|
- Ensure effects degrade gracefully on lower settings
|
|
- Output: polished visual effects
|
|
|
|
### Phase 4: Audio Polish (parallel with Phase 2)
|
|
Delegate to **sound-designer**:
|
|
- Review audio events for completeness (are any actions missing sound feedback?)
|
|
- Check audio mix levels — nothing too loud or too quiet relative to the mix
|
|
- Add ambient audio layers for atmosphere
|
|
- Verify audio plays correctly with spatial positioning
|
|
- Output: audio polish list and mixing notes
|
|
|
|
### Phase 5: Hardening
|
|
Delegate to **qa-tester**:
|
|
- Test all edge cases: boundary conditions, rapid inputs, unusual sequences
|
|
- Soak test: run the feature for extended periods checking for degradation
|
|
- Stress test: maximum entities, worst-case scenarios
|
|
- Regression test: verify polish changes haven't broken existing functionality
|
|
- Test on minimum spec hardware (if available)
|
|
- Output: test results with any remaining issues
|
|
|
|
### Phase 6: Sign-off
|
|
- Collect results from all team members
|
|
- Compare performance metrics against budgets
|
|
- Report: READY FOR RELEASE / NEEDS MORE WORK
|
|
- List any remaining issues with severity and recommendations
|
|
|
|
## Error Recovery Protocol
|
|
|
|
If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete:
|
|
|
|
1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
|
|
2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input.
|
|
3. **Offer options** via AskUserQuestion with choices:
|
|
- Skip this agent and note the gap in the final report
|
|
- Retry with narrower scope
|
|
- Stop here and resolve the blocker first
|
|
4. **Always produce a partial report** — output whatever was completed. Never discard work because one agent blocked.
|
|
|
|
Common blockers:
|
|
- Input file missing (story not found, GDD absent) → redirect to the skill that creates it
|
|
- ADR status is Proposed → do not implement; run `/architecture-decision` first
|
|
- Scope too large → split into two stories via `/create-stories`
|
|
- Conflicting instructions between ADR and story → surface the conflict, do not guess
|
|
|
|
## Output
|
|
A summary report covering: performance before/after metrics, visual polish changes, audio polish changes, test results, and release readiness assessment.
|