Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Finish audio startup for [browser game or sound tool]. Use an explicit [Start audio or Play] interaction and inspect the current audio context or media lifecycle. Show the actual pending, available, blocked, paused, and failed outcomes that apply. Keep mute and volume controls usable before sound starts.
Do not report that audio is playing merely because a button was clicked. Handle the supported start or resume result, repeated clicks, focus changes, and a return from interruption without creating duplicate playback. Define which state belongs to user preference and which reflects runtime availability.
Verify a first visit, a blocked or suspended start, sound disabled, repeated activation, pause/resume, and an asset failure using bounded test content. Keep essential information available through appropriate non-audio cues. Report browser conditions tested and the remaining policy or device differences.Make this prompt yours
Use this for startup correctness, not for promising autoplay across browsers. Avoid unexpected sound during verification.
You might also hear
- autoplay
- AudioContext resume
- sound unlock
- mute state
- audio startup
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Supported: Original audio-startup template. Autoplay policy and actual start/resume outcomes support the premises; UI state, no duplicate playback, and mute handling are requested behavior.