Say something out loud to the user and hear their spoken reply. Speaks text_to_speak through the computer's speakers, then listens like a conversation turn — it waits for the user to start talking and stops when they finish — and returns an on-device transcript of what they said.

Write text_to_speak for the ear, not the screen:

• 1–3 short sentences, under ~40 words; lead with the outcome, then one question.

• Plain words only: no markdown, bullets, emoji, code, file paths, URLs, stack traces or tables.

• Describe code instead of reading it ("I added a retry to the upload function"), say file names not paths ("in index.ts"), round numbers ("about two hundred ms"), spell out symbols.

• Ask one question at a time, answerable in a few words ("Should I deploy it — yes or no?").

• Put the details (diffs, logs, links) in your normal on-screen reply, and say so out loud.

• Tool output (Bash stdout, file writes) is NOT the on-screen reply. Only your own assistant message text renders.

• A spoken turn with no assistant message text shows the user nothing — never skip the on-screen reply.

Good: "The build passed and all tests are green. Want me to open the pull request?" Bad: "## Results\n- npm test ✅ 42/42\n- see /Users/x/repo/src/index.ts:120"

Once the user is talking with you by voice, keep the conversation in voice: answer each transcript with another speak_and_listen call (not a text reply) until they say stop or start typing. To end voice mode, or for a one-way announcement, pass listen: false: it returns at once and speaks while you work. A reply of "(No speech detected …)" means the user did not answer — never treat it as consent. Ask once more; if still nothing, stop and say on screen that voice mode is paused and they can type to carry on (not speak: the mic is off). The "voice-mcp timing" line at the end is diagnostics: ignore it unless the user asks why things feel slow. If it reports that voice-mcp is not set up, call voice_setup.

Start or end a call: a hands-free session where the microphone stays open and the user talks whenever they like, like a phone call, until they hang up. action start takes the speaker and microphone, says a short greeting and returns the rules of the call; action end hangs up (also happens when the user says "hang up" or "bye Claude", or after a long silence). During the call, speak with say and hear the user with listen.

During a call: say text out loud and return at once, so you carry on working while it plays. The result includes anything the user said meanwhile. Only during a call: use speak_and_listen otherwise.

Write text for the ear, not the screen:

• 1–3 short sentences, under ~40 words; lead with the outcome, then one question.

• Plain words only: no markdown, bullets, emoji, code, file paths, URLs, stack traces or tables.

• Describe code instead of reading it ("I added a retry to the upload function"), say file names not paths ("in index.ts"), round numbers ("about two hundred ms"), spell out symbols.

• Ask one question at a time, answerable in a few words ("Should I deploy it — yes or no?").

• Put the details (diffs, logs, links) in your normal on-screen reply, and say so out loud.

• Tool output (Bash stdout, file writes) is NOT the on-screen reply. Only your own assistant message text renders.

• A spoken turn with no assistant message text shows the user nothing — never skip the on-screen reply.

During a call: return what the user has said since you last heard from them, at once if something is waiting, otherwise wait up to wait_seconds (default and maximum 40) for their next words. "(still on the call, nothing said)" means nobody spoke yet: call listen again to keep waiting, or say something. Once it reports that the call ended, don't call it again.

Check whether this computer has everything speak_and_listen needs — text-to-speech, a microphone recorder (SoX), whisper.cpp speech-to-text and the speech model — and optionally install what's missing. Anything already installed is reused (an existing model elsewhere on disk is symlinked, not re-downloaded). Call it with install=false (the default) first and tell the user what is missing. Only call it with install=true after the user agrees: it runs brew install for the missing packages and downloads the speech model once. It never uninstalls or changes anything else. kokoro=true (also only after the user agrees) installs the optional Kokoro voice: more natural than the built-in one, runs on this Mac, about 1 GB on disk. Once installed it's used automatically; the built-in voice stays as the fallback. bubble=true (also only after the user agrees) builds the floating call bubble on this Mac with swiftc: a small window during calls with mute and hang up. If it reports INSTALLING, the install continues in the background — wait a minute and call it again to check.