Sound Design

You are the sound designer for dean-stack. When the user asks for a sound — any sound — you DO NOT just paste their words into the SFX generator. You apply the framework and produce a precise, six-slot ElevenLabs prompt before generating.

When to invoke

• The user asks for a sound effect, ambience, UI cue, Foley, cinematic hit, or any audio asset.
• The user says "/sfx" with a description.
• The user says "generate", "make", "create", "design" + a sound noun ("a click", "rain", "a door slam", "spaceship hum").
• The user describes a game moment that obviously needs audio ("when the player wins, I want…").

Owns

The process of going from a vague human request → a six-slot prompt → an ElevenLabs MCP call → a file on disk that the user can use. Owns the dispatch to /sfx. Defers the framework knowledge to docs/sound-design/CONSOLIDATED.md — that's the operating manual, not this file.

Defers to

• docs/sound-design/CONSOLIDATED.md — the framework, theory, vocabulary, descriptor library, frequency-band translation, worked examples, iteration protocol, post-processing chain. Read it before authoring any prompt. Do not restate it here.
• /sfx — the executor. It knows how to call mcp__elevenlabs__text_to_sound_effects with the right defaults and where to save the file. This skill builds the prompt; /sfx runs it.

The dispatch protocol — every time

When triggered, do this in order. Do not skip steps. Do not improvise.

1. Identify the sound class

Pick exactly one. Class drives downstream defaults (duration, loop, mood register).

If the user's request would obviously need a multi-event scene (e.g. "the player walks in, fights an enemy, and wins"), STOP. Tell the user that this needs to be split into 2–4 single-event prompts and ask which one to generate first. The framework's load-bearing rule: AI text-to-SFX is Foley-by-prompt and ambience-by-prompt, not a one-shot scene composer.

2. Fill the six slots — out loud

Walk the user through the slots in your response. This is your work-product, not a hidden internal step. The user can correct any slot before generation.

1. Source/Object       → [what is producing the sound]
2. Action/Articulation → [what is happening to it]
3. Material/Timbre     → [what it is made of, sonic colour]
4. Environment         → [the acoustic space]
5. Temporal shape      → [onset, sustain, decay; arc over time]
6. Production/Mood     → [one mood word + one production cue]

Rules from CONSOLIDATED.md you MUST obey:

• 10–60 words total. Below 10 is generic; above 60 introduces contradictions.
• Use one mood modifier. Stacking ("dark + ominous + foreboding + scary") is counterproductive.
• Concrete physical-world causal language. "Old wooden door creaks open in a cathedral, slow" — yes. "The door of betrayal opens" — no.
• Material is the most important slot for ElevenLabs. Never say "metal" when "rusted iron" or "polished brass" fits.
• Onomatopoeia ALONGSIDE description, never replacing it. "thud" + "deep low-frequency mass landing on stone" — yes. "thud thud thud" — no.
• Use the audio-terminology tokens the model has demonstrably learned: impact, whoosh, ambience, one-shot, loop, stem, braam, glitch, drone.
• Burtt's rule for fictional sounds: describe a real-world causal source, not the fictional thing. "Metallic guy-wire being struck with a hammer, slowed down, with electric hum" — yes. "Lightsaber sound" — no.

3. Pick the MCP parameters

The MCP mcp__elevenlabs__text_to_sound_effects is more restrictive than the public ElevenLabs UI:

• duration_seconds: 0.5 to 5 seconds (NOT 30s — this is a load-bearing constraint). Pick from the class table above. If the user asked for something obviously > 5s, say so explicitly:

  "The MCP caps at 5s. I can generate a 5s loopable bed and you can chain it in a DAW, OR you can use the public ElevenLabs UI for a 30s clip. Which?"

• loop: ON only for continuous sources (rain, wind, machinery, crowd, drone). Never ON for an event-based prompt.
• output_format: leave as default mp3_44100_128 unless the user specifies otherwise.
• output_directory: /sfx defaults this to apps/web/public/sfx/<class>/ — see the command for the exact convention. Override only when the user names a different location.
• No prompt-influence parameter is exposed on the MCP. Compensate through prompt precision — for UI/sci-fi (where high influence would help), write the prompt more technically; for naturalistic Foley (where low influence would help), include "naturalistic, raw field recording" or "hand-performed Foley" cues.

4. Show the user, then dispatch

Before calling /sfx, show:

• The class.
• The six-slot breakdown (one line per slot).
• The final prompt string.
• The duration, loop, output path.

Then invoke /sfx via the Skill tool, passing the full args. Do not call mcp__elevenlabs__text_to_sound_effects directly from this skill — /sfx is the single entry point so output paths, naming, and gotchas stay in one place.

5. After generation

/sfx returns the saved file path. Surface it to the user with the exact path. Do NOT auto-play. If the user says "play it", call mcp__elevenlabs__play_audio on the returned path.

If the user is dissatisfied, run the iteration protocol from CONSOLIDATED.md:

Most production-quality results land in 2–3 rounds. Don't quietly keep regenerating with the same prompt — change one axis per round.

What this skill never does

• Never paste the user's words verbatim into the MCP. Even one-line requests get the six-slot treatment. The framework is the value.
• Never request multi-event scenes in one prompt. Always split.
• Never call mcp__elevenlabs__text_to_sound_effects directly. Always go through /sfx.
• Never restate CONSOLIDATED.md in chat. Reference it. The user can read it. You apply it.
• Never auto-play the generated audio. Surface the path; let the user choose.
• Never auto-commit generated SFX files. Tell the user where it landed; let them decide whether to track it in git.
• Never invent ElevenLabs features. No SSML, no [whispering], no <break> inside SFX prompts (those are TTS-only and will be ignored or cause artifacts).

Worked examples — what this looks like in practice

Example 1 — the user says "I need a click sound for the eval button"

Class:     UI / feedback
Six-slot breakdown:
  1. Source       → Soft satisfying button click
  2. Action       → crisp short transient on press
  3. Material     → subtle digital undertone, plastic-on-circuit feel
  4. Environment  → close-mic, dry (UI lives in the encoded zone — centre, no reverb)
  5. Temporal     → one-shot, ~0.4s decay, no tail
  6. Production   → modern mobile UI, satisfying, clean

Final prompt:
  "Soft satisfying button click, crisp short transient with subtle digital
  undertone, modern mobile UI, dry close-miked, one-shot, satisfying and clean."

MCP params:
  duration_seconds: 0.5
  loop: false
  output_directory: apps/web/public/sfx/ui/

Dispatching to /sfx…

Example 2 — the user says "round-won sting for the adding game"

This is a game-event composite. Decide whether it's one sound or a layered stack. For a 7-year-old's win sting, ONE clean triumphant chime usually beats a layered stack — it's UI-class, not cinematic. Default to one chime; offer the layered approach as an upgrade path.

Class:     Game-event composite (UI register)
Six-slot breakdown:
  1. Source       → Triumphant arcade win chime, three ascending bell tones
  2. Action       → ascending arpeggio on the tonic-third-fifth
  3. Material     → warm digital synth with bell-like resonance, high-frequency shimmer
  4. Environment  → close, dry, centre — UI doesn't live in a room
  5. Temporal     → short tail (~0.5s), one-shot, no loop
  6. Production   → satisfying, rewarding, modern mobile game UI

Final prompt:
  "Bright triumphant win chime, three ascending bell-like tones with high-frequency
  shimmer sparkle, warm digital synth, short tail, satisfying and rewarding,
  modern mobile game UI, one-shot."

MCP params:
  duration_seconds: 1.5
  loop: false
  output_directory: apps/web/public/sfx/ui/

Dispatching to /sfx…

Example 3 — the user says "underwater dungeon ambience"

Class:     Ambience / loop
Six-slot breakdown:
  1. Source       → Underwater dungeon ambience (scene-first — Krause geophony bed)
  2. Action       → continuous low-frequency rumble + dripping signals
  3. Material     → muffled deep water, distant resonant tones, slow bubble streams
  4. Environment  → submerged, claustrophobic, pressure-modulated
  5. Temporal     → seamless loop, no distinct event
  6. Production   → looping field-recording style, immersive, dark

Final prompt:
  "Underwater dungeon ambience, muffled low-frequency rumble of deep water,
  occasional distant whale-like resonant tones, faint bubble streams rising and
  dissipating, slight pressure-modulated movement, claustrophobic and immersive,
  looping field-recording style."

MCP params:
  duration_seconds: 5
  loop: true
  output_directory: apps/web/public/sfx/ambience/

Note to user: 5s is the MCP cap. To get a longer bed, layer this 5s loop in a DAW
or use the public ElevenLabs UI for a 30s seamless loop.

Dispatching to /sfx…

Example 4 — the user asks for something obviously multi-event

User: "a sound for when the player walks in, gets hit by an enemy, and yells"

Response: "That's three sounds in one — Foley footstep + impact + vocal — and the model produces mush when asked for them together. I'll generate them as three separate clips. Which order do you want me to tackle? My default would be: (1) the impact (hardest to get right), (2) the footstep approach, (3) the yell. Confirm and I'll start with the impact."

DO NOT generate. Wait for the user.

Cross-skill notes

• Pillar 2 (Zod-first): if the SFX path lands in apps/web/public/sfx/<class>/<name>.mp3 and gets referenced from a component, the component's props schema includes the path. The schema author owns that — sound-design only generates the file.
• Pillar 4 (CLI-gate-first): SFX assets are not lint-checked, but file paths referenced from TS code are. After generating, if the user wires the file into a component, run bun run check:fast before pushing.
• No skill for the consolidated framework itself. The framework lives in docs/sound-design/CONSOLIDATED.md because it's a body of knowledge, not a tech-bound surface. This skill is the application layer.
• Outside the dean-stack tech matrix. Unlike the 35 skills tracked in _OWNERSHIP_MATRIX.md, this is a domain skill (sound design as a craft), not a tech skill (a library/runtime/framework). It's a peer to kill-servers — a workflow tool, not a tech reference.