Put this Claude session into voice standby mode for remote voice access
From voice-multiplexernpx claudepluginhub n33kos/claude-plugins --plugin voice-multiplexerThis skill uses the workspace's default tool permissions.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.
Put this session into standby mode so it can receive remote voice input through the Claude Voice Multiplexer relay server.
Before entering standby, verify the relay server is reachable:
Verify MCP tools are reachable: Call relay_status as a connectivity check. If it fails with a tool error (MCP connection hasn't established), wait 5 seconds and retry up to 3 times. If still failing, print: "MCP connection not established. Run /mcp in the terminal to connect, then try /voice-multiplexer:standby again." and stop.
Check if the relay server is running by calling relay_status. If it indicates the relay is not reachable, print: "Relay server is not running. Start it with: launchctl start com.vmux.daemon" and stop.
Note: In v2.0+, services are managed by the vmuxd daemon (auto-starts on login via launchd). You no longer need to run start.sh manually.
When invoked, use the relay_standby MCP tool to register this session with the relay server. The server automatically detects your working directory via MCP roots — no parameters needed.
Then enter a continuous conversation loop:
relay_standby — it blocks until a voice message arrivesrelay_respond with your response textrelay_standby again to listen for the next messageNote: No session identifiers or working directory paths need to be passed to any tool. The server auto-detects your session from the MCP connection.
While in standby, you MUST stay responsive to voice input. Use the right execution tier for each task:
Tier 1 — Inline (do synchronously, <15 seconds):
Tier 2 — Foreground Agent (user waits, 15-60 seconds):
Tell the user "Working on that now, give me a moment" via relay_respond, then launch a foreground agent (default, NOT run_in_background). The parent blocks but gets the full result, enabling informed verification before responding.
Tier 3 — Background Agent (parallel work, >60 seconds):
Use this tier sparingly. Background agents have known reliability issues with result retrieval.
When running background work (Tier 3 only), follow this pattern:
relay_respondAgent(run_in_background=True, ...)"As you work, call the
relay_activityMCP tool with short status updates. Passsource='<task-name>'so the status is labeled. Example:relay_activity(activity='Found 3 matching files, analyzing...', source='code-search')""When you are FINISHED with your task, call
relay_notifywith a DETAILED summary of what you did — include files changed, key decisions, and any concerns. This wakes up the parent session. Example:relay_notify(message='Completed: edited auth.py lines 50-80 to add token validation, also updated tests in test_auth.py. Note: the existing mock may need updating for the new param.')"
relay_standby to keep listening for voice inputrelay_standby returns a [Notify] message from a background agent, VERIFY before confirming:
git diff to see actual changes (if code was modified)Important: Background agents must NOT use relay_respond — only the parent session speaks to the user. Agents use relay_activity for progress updates and relay_notify once at completion to wake up the parent.
NEVER say "it's done" based solely on a relay_notify message without verifying. The relay_notify is a signal to start verification, not a confirmation to relay.
If relay_standby fails with a tool error (the MCP connection dropped, not a content-level [System] message), follow this recovery loop:
relay_status to test if the MCP connection is backrelay_status succeeds, immediately call relay_standby again — the connection recoveredrelay_status also fails, wait another 10 seconds and try again (repeat up to 5 times total)"MCP connection lost. Run /mcp in the terminal to reconnect." and stop the loopThis handles the case where the relay server restarts and the MCP SSE connection drops temporarily.
relay_standby again.relay_standby returns a [Standby] timeout message, silently call it again — do not output anything.relay_standby returns a [System] message containing "error" or "disconnect", try relay_respond with a brief spoken acknowledgment if possible, then attempt to re-enter standby. Only stop the loop if the error is unrecoverable (e.g., explicit shutdown).relay_standby throws a tool error (MCP disconnected), follow the MCP Reconnection During Standby steps above.relay_respond text.relay_file to send large files directly to the web app without token cost.AskUserQuestion or EnterPlanMode while in standby. These tools block the CLI waiting for terminal input, which freezes the voice relay. Instead, ask conversationally via relay_respond.Before performing significant operations, call relay_activity with a short description:
relay_activity("Reading files...")relay_activity("Running command...")relay_activity("Thinking about approach...")relay_activity("Searching codebase...")relay_activity("Editing code...")# Display file in web app (no voice, no tokens)
await relay_file("path/to/file.txt")
# Display file AND read it aloud
await relay_file("path/to/output.json", read_aloud=True)