Change request queue

The change request queue holds recordings until a watcher agent files them. You send a recording to the queue and move on. Your watcher, a Claude Code session you leave running, picks each one up, works out which repo it belongs to and files it as a GitHub issue there, each on its own Agent Workstreams board.

What the change request queue is

The queue is a list of recordings that are waiting to become issues. It suits the times you record several asks in a row, for different projects, and do not want to stop and hand each one to an agent yourself.

It is different from Give to your agent. That button copies a prompt for the agent in front of you right now, which then files the issue in the repo you have open. The queue waits for your watcher instead, and the watcher picks the repo.

Add a recording to the queue

Connect GitHub and pick a default repository first (see GitHub). Then any of these adds a recording:

• the Add to change request queue card on the "What's next?" step right after you record,
• the recording's Agent tab,
• the recording's menu in your Library,
• the Vidmatic Chrome extension.

A recording is in the queue once. Adding it again shows the request it already has, and a recording that already has an issue is not queued twice.

Write a request instead

Not every ask needs a recording. Choose New change request at the top of the queue, write what should change, and choose Add to queue. A title is optional: the first line of your request is used when you leave it empty. Keep Let Vidmatic suggest and your watcher picks the repo, or pick one of your repos and the watcher files it there.

An agent can do the same with the enqueue_change_request_text tool on the Vidmatic MCP server, for example a voice assistant you dictate to. A written request moves through the same statuses as a recording.

Set up the watcher

The watcher runs in Claude Code with the Vidmatic MCP server connected (see the quickstart). Open Claude Code in the folder that holds your checkouts, for example ~/dev, and run:

Every 10 minutes it checks the queue. It finds the git repos under that folder, and for each request a helper agent reads it, picks the repo and files the issue there by the repo's own rules. If the repo is not checked out yet, it clones it there.

The same loop can also ship the work. Name the repos you want built with --repos, for example --repos you/web,you/api. For each of them it hands the issues that are ready to one orchestrator agent, which plans the order and builds them in parallel lanes, one pull request per lane. A repo you did not name is never built: when it has work waiting, or has no checkout the loop can use, you get a note in your Inbox instead.

To see what is waiting without claiming anything, run /mcp__vidmatic__dispatcher --dry-run. Add --root <folder> to watch a folder other than the current one.

The queue shows Watcher running when your watcher checked in within the last 20 minutes. When none has, it shows the command again so you can start one. Set up your watcher, at the top of the queue, always has the command and a Copy button.

How a request moves

The watcher takes one request at a time, and each run stops after 3 requests or 8 minutes, leaving the rest for the next run. Each row shows one status:

Find the queue

Open Agent Workstreams in the app sidebar and choose Change requests. The address is /workstreams?view=requests.