mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
f36494e70c
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-audio
|
|
description: "Orchestrate audio team: audio-director + sound-designer + technical-artist + gameplay-programmer for full audio pipeline from direction to implementation."
|
|
argument-hint: "[feature or area to design audio for]"
|
|
user-invocable: true
|
|
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
|
---
|
|
|
|
When this skill is invoked, orchestrate the audio team through a structured pipeline.
|
|
|
|
**Decision Points:** At each step 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 step.
|
|
|
|
1. **Read the argument** for the target feature or area (e.g., `combat`,
|
|
`main menu`, `forest biome`, `boss encounter`).
|
|
|
|
2. **Gather context**:
|
|
- Read relevant design docs in `design/gdd/` for the feature
|
|
- Read the sound bible at `design/gdd/sound-bible.md` if it exists
|
|
- Read existing audio asset lists in `assets/audio/`
|
|
- Read any existing sound design docs for this area
|
|
|
|
## How to Delegate
|
|
|
|
Use the Task tool to spawn each team member as a subagent:
|
|
- `subagent_type: audio-director` — Sonic identity, emotional tone, audio palette
|
|
- `subagent_type: sound-designer` — SFX specifications, audio events, mixing groups
|
|
- `subagent_type: technical-artist` — Audio middleware, bus structure, memory budgets
|
|
- `subagent_type: [primary engine specialist]` — Validate audio integration patterns for the engine
|
|
- `subagent_type: gameplay-programmer` — Audio manager, gameplay triggers, adaptive music
|
|
|
|
Always provide full context in each agent's prompt (feature description, existing audio assets, design doc references).
|
|
|
|
3. **Orchestrate the audio team** in sequence:
|
|
|
|
### Step 1: Audio Direction (audio-director)
|
|
Spawn the `audio-director` agent to:
|
|
- Define the sonic identity for this feature/area
|
|
- Specify the emotional tone and audio palette
|
|
- Set music direction (adaptive layers, stems, transitions)
|
|
- Define audio priorities and mix targets
|
|
- Establish any adaptive audio rules (combat intensity, exploration, tension)
|
|
|
|
### Step 2: Sound Design and Audio Accessibility (parallel)
|
|
Spawn the `sound-designer` agent to:
|
|
- Create detailed SFX specifications for every audio event
|
|
- Define sound categories (ambient, UI, gameplay, music, dialogue)
|
|
- Specify per-sound parameters (volume range, pitch variation, attenuation)
|
|
- Plan audio event list with trigger conditions
|
|
- Define mixing groups and ducking rules
|
|
|
|
Spawn the `accessibility-specialist` agent in parallel to:
|
|
- Identify which audio events carry critical gameplay information (damage received, enemy nearby, objective complete) and require visual alternatives for hearing-impaired players
|
|
- Specify subtitle requirements: which audio events need captions, what text format, on-screen duration
|
|
- Check that no gameplay state is communicated by audio alone (all must have a visual fallback)
|
|
- Review the audio event list for any that could cause issues for players with auditory sensitivities (high-frequency alerts, sudden loud events)
|
|
- Output: audio accessibility requirements list integrated into the audio event spec
|
|
|
|
### Step 3: Technical Implementation (parallel)
|
|
Spawn the `technical-artist` agent to:
|
|
- Design the audio middleware integration (Wwise/FMOD/native)
|
|
- Define audio bus structure and routing
|
|
- Specify memory budgets for audio assets per platform
|
|
- Plan streaming vs preloaded asset strategy
|
|
- Design any audio-reactive visual effects
|
|
|
|
Spawn the **primary engine specialist** in parallel (from `.claude/docs/technical-preferences.md` Engine Specialists) to validate the integration approach:
|
|
- Is the proposed audio middleware integration idiomatic for the engine? (e.g., Godot's built-in AudioStreamPlayer vs FMOD, Unity's Audio Mixer vs Wwise, Unreal's MetaSounds vs FMOD)
|
|
- Any engine-specific audio node/component patterns that should be used?
|
|
- Known audio system changes in the pinned engine version that affect the integration plan?
|
|
- Output: engine audio integration notes to merge with the technical-artist's plan
|
|
|
|
If no engine is configured, skip the specialist spawn.
|
|
|
|
### Step 4: Code Integration (gameplay-programmer)
|
|
Spawn the `gameplay-programmer` agent to:
|
|
- Implement audio manager system or review existing
|
|
- Wire up audio events to gameplay triggers
|
|
- Implement adaptive music system (if specified)
|
|
- Set up audio occlusion/reverb zones
|
|
- Write unit tests for audio event triggers
|
|
|
|
4. **Compile the audio design document** combining all team outputs.
|
|
|
|
5. **Save to** `design/gdd/audio-[feature].md`.
|
|
|
|
6. **Output a summary** with: audio event count, estimated asset count,
|
|
implementation tasks, and any open questions between team members.
|
|
|
|
## 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
|