Listen and Recap

The point of /listen and /recap is not a new product. It is the live transcript, sitting in the same host that already has your domain skills and tools.

Parrot Scribe already runs MCP inside the app. The commands use those app MCP tools. They do not start a second server.

/listen

/listen is a live sidebar, not a second recorder. If the app is idle, it starts a session. Then it stays in the slash-command turn and polls live_transcript.

It stays quiet unless a skill already loaded in the host gives it a reason to speak. Notes stay in that chat. They are not spoken into the recorded conversation.

The live cursor

Each poll returns a cursor: epoch, sinceSequence, and gap.

Send the last epoch and sinceSequence back on the next live_transcript call. That is how the host asks for only what it has not seen.

gap is a resync, not an empty poll. When gap is true, adopt the returned epoch and sinceSequence, and treat the text as the current ring snapshot.

The ring is best-effort and in memory. It is lost on restart. sinceSequence is not a crash-safe cursor.

/recap

/recap closes the loop. If a session is still live, it stops recording. Then it resolves the session and reads the transcript.

The shape of the recap comes from the host. The command does not bake a recap methodology.

Pair it with the host

The commands are thin. They start, poll, stop, and read. The useful work is the skill and tool the host already has: your repo, your tracker, your house style.

That pairing is the product. /listen and /recap feed the transcript into the place you already work. They are not a plugin dump, and they are not a second methodology.

Repo conventions

You are in a design review. /listen is already polling. The host already loaded this repo's conventions: no helper layers, prefer the module that already owns the type, do not invent a second policy check.

Someone says "we can just wrap that in a small utility." The sidebar can speak because the convention is already loaded. It points at the existing owner. It does not invent a new architecture, and it does not talk into the recorded call.

Issue tracker

You are planning the next slice. The host already has the issue tracker: GitHub, Linear, whatever you actually use.

Someone speaks the acceptance criteria out loud. /listen can file or update the ticket with the words from the room, using the tracker tool the host already has. The note stays in the chat. The ticket is the follow-up, not a second source of truth invented by the plugin.

House style

You are reviewing copy, or a UI string, or an error that customers will read. The host already has the house style: short sentences, no filler, the words this product actually uses.

Someone says "make it friendlier." The sidebar can apply the style that is already loaded. It does not ship a voice of its own, and /recap will not later invent one.

Local notes

You are in a 1:1 or a research call. The host can already read your local notes, last week's recap, the constraint you wrote down after the last incident.

Someone says "same problem as last Thursday." The sidebar can pull that note instead of guessing. The live transcript is the new input. The notes you already keep are the memory.

Recap takes the host's shape

After the session, /recap stops recording if it is still live, then reads the transcript. What it writes depends on those same host skills and tools.

If the tracker is loaded, the recap can be tickets. If the house style is loaded, the recap can be a note in that voice. If the repo conventions are loaded, the recap can be the change list this codebase would accept. The command does not bake a recap methodology. It closes the loop and lets the host finish the work.

For host setup and maintenance, see Listen Install. For the MCP access model and tool tables, see MCP Server.