What this prompt does
This prompt asks the AI to build a voice-enabled assistant for [assistant_purpose] on [platform]. It wires a streaming pipeline: speech-to-text via [stt_provider] with streaming recognition, wake-word or push-to-talk activation, intent detection and entity extraction, LLM reasoning with [model_provider], and natural text-to-speech via [tts_provider] in a [voice_style] voice. It manages conversation state across turns, handles interruptions when the user speaks over a response, filters ambient noise, and targets [latency_target] milliseconds end to end.
The structure works because voice feels broken the moment latency creeps up or the assistant talks over you, so the prompt treats streaming, interruption handling, and a graceful low-confidence fallback as core requirements rather than polish. Naming [stt_provider], [model_provider], and [tts_provider] pins a concrete pipeline, and the [latency_target] budget forces real architectural decisions about where to stream and where to buffer, implemented in [language]. Conversation-state management across turns is what lets the assistant follow a multi-step request like [demo_scenario] without losing the thread, and noise filtering plus ambient adaptation keep recognition usable outside a quiet recording booth.
When to use it
- You are building a hands-free experience where typing is impractical and natural turn-taking matters.
- You want streaming STT to LLM to TTS so the assistant starts responding before the user finishes thinking.
- You need interruption handling so users can cut in mid-response without the assistant steamrolling.
- You have a hard latency budget like
[latency_target]ms and want the architecture built around it. - You want a graceful fallback for low-confidence or unrecognized speech instead of a confident wrong answer.
- You are integrating specific providers (
[stt_provider],[tts_provider]) and want them composed into one pipeline.
Example output
Expect a streaming pipeline architecture covering activation, [stt_provider] streaming recognition, intent/entity extraction, [model_provider] reasoning, and [tts_provider] synthesis in a [voice_style] voice. You get conversation-state management, interruption handling, noise filtering, low-confidence fallback logic, an architecture diagram, and a demo of [demo_scenario], implemented in [language].
Pro tips
- Treat
[latency_target]as the design constraint, not a wish — it dictates streaming at every stage and where you can afford to buffer. - Pick
[stt_provider]for streaming quality on your audio conditions; batch STT alone will blow the latency budget no matter how fast the LLM is. - Get interruption handling right early; nothing makes a voice assistant feel more robotic than talking over the user.
- Tune
[voice_style]to the use case — a clear, moderate-pace voice reads better for technical content than an overly expressive one. - Build the low-confidence fallback as a real branch (re-prompt or escalate), not a generic "I didn't catch that" loop that frustrates users.
- Stream partial LLM output into
[tts_provider]where it supports it, so speech starts before the full response is generated.
