Skip to main content

04.19Voice

Voice sessions: Claude Code skill for talking to AI agents

Claude Code skill from AR Labs that starts a spoken conversation with an AI voice agent about a document, a design interview or a list of items, in the browser.

Engraved plate: a tuning fork rings on a sounding box, a mallet in front and a document leaning against it.An engraved tuning fork stands on a wooden sounding box, sound waves ringing from its tines, with a mallet in front and a document leaning against the box.AR LABS · INSTRUMENT CABINET · DRAWER 04CALL NO. 04.190123456789ABCDFIG. 19 · VOICE SESSIONSTUNING FORK& SOUNDING BOXPARTSAPresents a documentaloud, takes questionsBOne command froma coding sessionCRuns in the browserDDesign interviewscarry on by voiceSTRUCK FROM A CODING SESSION
On this page
  1. How it works
  2. The judgement it encodes
  3. What exists today
  4. Example

The voice skill is a Claude Code skill, built at AR Labs, that lets a developer step away from the keyboard and talk to an AI agent about the work in front of them. From an ordinary Claude Code session, one command starts a voice conversation in the browser: an agent presents a document aloud and answers questions about it, continues a design interview by voice, or walks through a list of items such as open pull requests. It is the bridge between our text-based agent sessions and our voice system, VOX Presenter, a voice pipeline built on the open-source Pipecat framework, in which a fast conversational agent talks while a slower background agent, the scribe, writes analysis to the screen.

How it works

The skill is a launcher. It checks its arguments, writes a context file for the voice backend, starts the backend or reuses one already running, opens the browser page, and confirms through the backend's control interface that it is serving. The conversation then runs in the browser. Ending the session is a request to the same interface.

FIG. 01
flowchart LR
  C["Claude Code session"] --> L["/voice command"]
  L --> X["Write session context"]
  X --> B["Start or reuse voice backend"]
  B --> W["Open browser page"]
  W --> T["Spoken conversation"]
  T --> O["Output read back into Claude Code"]

There are three session types.

  • /voice explain-aloud <document> presents one document. The session protocol, the instructions the voice agent starts with, tells it to begin on the first key point at once, with no greeting and no "where would you like to start", then walk the document section by section in spoken register while the person interrupts with questions. When the person says they are done, the agent gives a spoken summary of three or four sentences and asks them to confirm or correct it. The session writes a transcript and the scribe's accumulated analysis, and the Claude Code session reads both back so the text conversation carries on where the spoken one ended.
  • /voice grill continues a Grill Me design interview already under way in this session, and /voice grill <prompt> starts a new one. A separate headless Claude Code session asks the questions and the browser presents them. When the person presses Finish, the backend writes the design brief and reports its path back to the original session.
  • /voice explain <items> walks a tree of items aloud, one per turn, while the page shows the tree. The items can be a prepared file, a set of pull requests or files, or whatever the session was just discussing, in which case the session writes the tree itself. The person can queue items on the page, and the whole tree is in the voice agent's context, so they can interrupt to ask about any part. This is the newest of the three.

The judgement it encodes

Start from a summary, not a reread. For a voice interview, the text session first writes a full summary of itself, quoting the person's own words where they gave them, and the voice session starts fresh from that summary. In the live test, rereading the whole conversation for each spoken question cost far too much to be usable.

Open with content. A voice agent that opens with "what would you like to know?" puts the work back on the listener. The protocol makes it start presenting at once.

Close by checking understanding. The spoken summary at the end is confirmed or corrected by the person, so the transcript ends with an agreed account rather than the agent's guess.

Check before starting. A missing document, an unknown session type or a malformed item tree is reported and nothing is started. Summaries and trees that contain anything shaped like a credential are refused.

Ask the backend, do not guess. The session's output folder is read from the backend's status report rather than reconstructed, and a transcript without its closing footer is reported as a session that did not close cleanly, not as a corrupt file.

What exists today

All three session types are built and run on our own machine, through the browser, with the voice pipeline from VOX Presenter. The item walk-through is the most recent and does not yet write a transcript.

Example

Illustrative example. Starting a session on a design document:

> /voice explain-aloud build/DESIGN.md
 
Context written for: explain-aloud, build/DESIGN.md
Voice backend: running (reused)
Browser: opened
Status: serving; the session starts when the page connects
 
[spoken, first turn]
"The design splits the exporter into two parts: a handler that
decides the format, and writers that own the output. The reason is
that the old exporter mixed both, so every new format touched the
route..."