# Spoken Feedback

> Provide real-time spoken feedback to the user via text-to-speech while performing tasks. Use this skill ONLY when the user explicitly requests spoken feedback during a conversation, for example "use spoken feedback", "give me audio updates", "talk to me while you work", "announce what you're doing", "keep me posted out loud", "use say command", "speak to me", or "use TTS". Once activated, provide consistent spoken updates for the rest of the session at key moments including task start, progress checkpoints, completion, and errors. Detect the available TTS method (macOS `say`, PowerShell on Windows or WSL) at the moment of activation.

- Skill: `rperez030/spoken-feedback` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add rperez030/spoken-feedback`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rperez030/spoken-feedback/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: rperez030 (https://skillmd.com/u/rperez030)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rperez030/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:

```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:

```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:

```bash
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.