$npx -y skills add dannyjpwilliams/ui-sound-design-skill --skill ui-sound-designProgrammatic UI sound design using Web Audio API and Tone.js. Use when creating click sounds, notification chimes, toggle feedback, hover sounds, success/error audio, whoosh effects, or building a sound library for UI interactions. Provides an iterative describe-generate-listen-r
| 1 | ``` |
| 2 | ▁ ▃ ▅ ▇ ▅ ▃ ▁ ▁ ▃ ▅ ▇ ▅ ▃ ▁ ▁ ▃ ▅ ▇ ▅ ▃ ▁ |
| 3 | ██╗ ██╗██╗ ███████╗ ██████╗ ██╗ ██╗███╗ ██╗██████╗ |
| 4 | ██║ ██║██║ ██╔════╝██╔═══██╗██║ ██║████╗ ██║██╔══██╗ |
| 5 | ██║ ██║██║ ███████╗██║ ██║██║ ██║██╔██╗ ██║██║ ██║ |
| 6 | ██║ ██║██║ ╚════██║██║ ██║██║ ██║██║╚██╗██║██║ ██║ |
| 7 | ╚██████╔╝██║ ███████║╚██████╔╝╚██████╔╝██║ ╚████║██████╔╝ |
| 8 | ╚═════╝ ╚═╝ ╚══════╝ ╚═════╝ ╚═════╝ ╚═╝ ╚═══╝╚═════╝ |
| 9 | ░ ▒ ▓ █ ▓ ▒ ░ ░ ▒ ▓ █ ▓ ▒ ░ ░ ▒ ▓ █ ▓ ▒ ░ |
| 10 | ██████╗ ███████╗███████╗██╗ ██████╗ ███╗ ██╗ |
| 11 | ██╔══██╗██╔════╝██╔════╝██║██╔════╝ ████╗ ██║ |
| 12 | ██║ ██║█████╗ ███████╗██║██║ ███╗██╔██╗ ██║ |
| 13 | ██║ ██║██╔══╝ ╚════██║██║██║ ██║██║╚██╗██║ |
| 14 | ██████╔╝███████╗███████║██║╚██████╔╝██║ ╚████║ |
| 15 | ╚═════╝ ╚══════╝╚══════╝╚═╝ ╚═════╝ ╚═╝ ╚═══╝ |
| 16 | ▇ ▅ ▃ ▁ ▃ ▅ ▇ ▇ ▅ ▃ ▁ ▃ ▅ ▇ ▇ ▅ ▃ ▁ ▃ ▅ ▇ |
| 17 | ``` |
| 18 | |
| 19 | Describe what your UI should sound like. |
| 20 | Preview it, tweak it, and download it from the browser. |
| 21 | |
| 22 | # UI Sound Design |
| 23 | |
| 24 | Translate plain-English sound descriptions into working Web Audio API code. No audio engineering background needed — describe what you want to hear, and this skill provides the synthesis knowledge to make it real. |
| 25 | |
| 26 | ## Workflow |
| 27 | |
| 28 | Every sound follows this loop: **Describe → Generate → Listen → Refine** (with optional **Review** for auditing existing code) |
| 29 | |
| 30 | ### 1. Describe |
| 31 | |
| 32 | The user describes the sound in plain language. Ask clarifying questions using this framework: |
| 33 | |
| 34 | **Four questions before generating any sound:** |
| 35 | |
| 36 | 1. **What triggers it?** (click, hover, toggle, notification, transition, success, error) |
| 37 | 2. **What's the emotional tone?** (satisfying, subtle, urgent, playful, professional, minimal) |
| 38 | 3. **How prominent should it be?** (barely perceptible, noticeable, attention-grabbing) |
| 39 | 4. **Any reference points?** (iOS keyboard, Slack notification, macOS trash, game UI, "like a bubble popping") |
| 40 | 5. **Have an audio reference file?** If the user has a .wav or .mp3 file they want to match, direct them to run the analyzer: |
| 41 | |
| 42 | ``` |
| 43 | node skills/ui-sound-design/tools/analyze-sound.mjs path/to/reference.wav |
| 44 | ``` |
| 45 | |
| 46 | Then paste the output back. When a sound profile is provided: |
| 47 | 1. Load `references/audio-file-references.md` for interpretation guidance |
| 48 | 2. Read the `synthesis_suggestion` block for initial parameters |
| 49 | 3. Match to the closest **sound category** using `recipe_starting_point` |
| 50 | 4. Load that recipe from `references/sound-recipes.md` |
| 51 | 5. Override recipe defaults with the profile's suggested parameters |
| 52 | 6. Apply any vocabulary bridge terms from the profile's `VOCABULARY MATCH` section |
| 53 | 7. Proceed to Generate as normal |
| 54 | |
| 55 | If the user gives a vague request like "make a click sound", use sensible defaults from the recipes and generate immediately — don't over-ask. |
| 56 | |
| 57 | ### 2. Generate |
| 58 | |
| 59 | 1. Match the description to a **sound category** (see quick reference below) |
| 60 | 2. Load the recipe from `references/sound-recipes.md` |
| 61 | 3. Apply the **vocabulary bridge** to translate adjectives into parameter changes |
| 62 | 4. For novel sounds not covered by recipes, compose from building blocks in `references/web-audio-api.md` |
| 63 | 5. Output format: **HTML preview** by default (adapt `assets/sound-preview.html`), or ES module / React hook / class if requested |
| 64 | |
| 65 | ### 3. Listen |
| 66 | |
| 67 | Provide the HTML preview file so the user can open it in a browser and hear the sound immediately. Each sound includes a download button that exports a .wav file for use in production code or handoff to developers. Include labeled buttons for each sound variation. The preview must: |
| 68 | - Handle AudioContext suspension (user gesture to start) |
| 69 | - Use the singleton AudioContext pattern |
| 70 | - Include visual feedback on play (the template handles this) |
| 71 | |
| 72 | ### 4. Refine |
| 73 | |
| 74 | When the user gives feedback, translate it using the vocabulary bridge and adjust parameters. Common refinement patterns: |
| 75 | - "I like it but..." → tweak 1-2 parameters |
| 76 | - "Completely wrong" → try a different recipe/approach |
| 77 | - "Too much/little" → scale the relevant parameter up/down |
| 78 | - "More like X" → identify what makes X distinctive and match those characteristics |
| 79 | |
| 80 | ### 5. Review (optional) |
| 81 | |
| 82 | Enter review mode when the user says "review", "audit", or "check my sound code", or pastes existing Web Audio code for evaluation. |
| 83 | |
| 84 | **Steps:** |
| 85 | 1. Load rules from `references/audio-rules.md` |
| 86 | 2. Scan the code against each rule, starting with Critical priority |
| 87 | 3. Report findings using the format in `audio-rules.md` — one line per violation with `file:line — [rule-id] description` |
| 88 | 4. Provide a summary table (pass/fail co |