Spoken Feedback

Spoken Feedback Skill

Provide real-time spoken feedback via text-to-speech while working on tasks. Especially valuable for developers who use a screen reader, and useful for anyone who wants audible progress updates during long-running work.

Activation

This skill is user-initiated only. Do not attempt TTS unless the user explicitly asks for spoken feedback during the conversation. Once the user requests it, activate spoken feedback for the rest of the session.

Environment Detection

When the user requests spoken feedback, detect the platform once (e.g., uname -a, $OSTYPE, or check /proc/version for "microsoft" to identify WSL) and use the matching method for the rest of the session.

macOS

Call say directly via Bash:

say -r 220 "Your message here"

• Default speech rate: 220 (adjustable per user preference).
• say and VoiceOver use separate audio channels — they coexist without interrupting each other.

Windows (native)

Call PowerShell via Bash:

powershell -Command "Add-Type -AssemblyName System.Speech; \$s = New-Object System.Speech.Synthesis.SpeechSynthesizer; \$s.Rate = 2; \$s.Speak('Your message here')"

WSL

Same PowerShell command, but use powershell.exe so WSL invokes the Windows binary:

powershell.exe -Command "Add-Type -AssemblyName System.Speech; \$s = New-Object System.Speech.Synthesis.SpeechSynthesizer; \$s.Rate = 2; \$s.Speak('Your message here')"

No TTS available (e.g., headless Linux)

Tell the user spoken feedback isn't available in this environment and continue with written responses only.

When to Speak

Once activated, announce at these moments:

• Task start: Briefly say what you're about to do. Example: "Searching the web for recent accessibility guidelines."
• Progress checkpoints: During multi-step work, give brief updates at meaningful transitions. Example: "Found 4 articles. Now reading the first one."
• Completion of every response: Always signal when your written response is fully complete. This is especially important when the user is in a setting where they can't easily tell when output has stopped — for example, a screen reader user, or anyone controlling the session remotely from claude.ai.
  • Short answers (one or two sentences): Speak the answer itself — this delivers the content and implicitly signals completion. No need for a separate "Done."
  • Longer responses: Announce completion with a brief phrase like "Done." or "Response ready." after the written response is finished. Never skip this.
• Errors and recovery: Say what went wrong and what you'll try next. Example: "That page failed to load. Trying an alternative source."
• Permission requests: When you need the user's approval to proceed (e.g., committing, pushing, installing packages, posting comments), announce the request audibly so the user knows you're waiting. Example: "I need your approval before pushing."

When NOT to Speak

• Don't narrate the content of your written responses — the user's screen reader handles that.
• Don't announce trivial actions that complete instantly.
• Don't repeat information already in your written response unless the spoken version adds clarity.
• Keep announcements to one or two sentences maximum.

Speech Style

• Use natural, concise phrasing — like a colleague giving a quick status update.
• Avoid jargon or technical details in speech — save those for the written response.
• Vary your phrasing. Don't start every utterance with "I'm" or "Now I'm".

User Preferences

The user may ask to adjust:

• Speech rate: Default is 220 for say, 2 for PowerShell. Adjust if asked.
• Verbosity: Default to the full announcement pattern. Reduce if the user asks for less.
• Voice: On macOS, specify with say -v VoiceName. List voices with say -v ? if asked.