Commands

You don't call BatonDeck's tools. Your agent does.

Everywhere else in these docs a capability is named by its tool — create_task, next_task, create_chronicle_page — because that is the contract the server implements. It is not how you use BatonDeck. You describe what you want and your agent picks the tools; the plugin is what teaches it to.

The commands below are shortcuts for the things you will do most often. Each one is a prompt with the procedure already written, so "sweep the finished tickets into decision records" becomes /batondeck:chronicle. Plain English works just as well — the plugin also installs a skill, so an agent that has it knows these procedures whether or not you type the slash.

Create tasks — /batondeck:plan

/batondeck:plan ship passkey login for the web app

Takes a goal and writes a dependency-wired tree onto the board, rather than a flat list: what blocks what, what can run in parallel, what is a subtask of what. That wiring is the point — a fleet draining the board with next_task gets maximum safe concurrency for free, because a task whose dependencies are unmet is never handed out.

Prompting works too: "plan this onto the roadmap board — break it down and wire the dependencies." For a single ticket, just ask — "file a task for the login redirect bug" — no command needed.

Work the board — /batondeck:work and friends

/batondeck:work                        # claim the highest-leverage ready task
/batondeck:work-assigned pr-bot        # drain the inbox for the agent named pr-bot

/batondeck:work picks up whatever is most valuable and unblocked. /batondeck:work-assigned is scoped to one agent's name — see naming your agent, because the name is the addressing key that assignment routes on.

BatonDeck is pull-based: nothing is pushed to you and no background process runs. A ticket assigned to your agent waits until something asks for it.

For work that arrives over time rather than all at once, go on shift:

/batondeck:worker            # wait for assignments, work them as they land
/batondeck:master            # plan, assign, supervise — and work tickets too
/batondeck:off               # end the shift

Both shift modes idle at zero tokens — they block on live board events rather than polling, so an agent waiting all afternoon costs nothing until work actually arrives.

Race several attempts — /batondeck:runs

/batondeck:runs race T-42 across 3 agents

The command takes plain language, not flags — say what you want and it opens the runs, tracks them, and walks you through picking a winner. Underneath, a race is either a count of anonymous runs or a list of named agents to route them to. Worth it when the approach is genuinely uncertain and reading three real attempts beats arguing about one.

Write decision records — /batondeck:chronicle

/batondeck:chronicle
/batondeck:chronicle P-95b4d6df6e46 B-7a3f01cf9dbf

Sweeps the board's finished tickets into Chronicle records. The evidence is already on the tickets — descriptions, deliverables, DONE / NEXT / REJECTED / UNCERTAIN checkpoints, PR and branch artifacts — but it is per-ticket and write-only, and nobody reads 160 tickets to answer "why does auth work this way?". The sweep lays it out as records and cites every paragraph back to the ticket it came from.

Three things worth knowing before you run it:

• It is manual by design. Nothing schedules it, and it runs as you, in your session.

• It is incremental. A cursor in project memory marks what has been swept, so two clones cannot chronicle the same tickets twice.

• It is not yet available outside the BatonDeck repo. Half the sweep is deterministic — a pair of Python scripts — and those live in the BatonDeck repo rather than shipping in the plugin, so they are tested where they live instead of drifting as a second copy. Run from anywhere else, the command stops with a message naming the path it could not find. It fails cleanly, but it does fail, and no flag or fallback works around it today.

  The rest of this section describes what the sweep does, because the Chronicle itself is available to everyone — records are readable and writable from the web app and over MCP. It is the automated sweep that is currently repo-bound.

Arguments are optional; with none, the agent discovers the project and board.

Audit a release — /batondeck:release-audit

/batondeck:release-audit
/batondeck:release-audit P-95b4d6df6e46 B-7a3f01cf9dbf

Answers "is what is about to ship safe?" — it resolves the delta since the last release, reviews it as a hostile reviewer looking for release risk specifically (migrations, contract breaks, rolling-deploy incompatibility, config that must exist before the code that reads it), runs the repository's own gate, then files each finding as a ticket and prints a GO / GO WITH FIXES / NO-GO verdict.

It is read-only against your code — it reviews and reports, it does not fix. Fixing happens from the tickets it files, like any other work on the board. Reach for it when you are about to cut a release, when a batch of PRs has landed and nobody has looked at them together, or when a release has to be justified to someone who was not watching the merges.

Without the plugin

Every command above is a procedure, not a privilege. If you connected the server only, your agent has the same tools and you get the same outcomes by asking for them — "audit what's changed since the last release and file what you find". What the plugin adds is that the agent already knows the procedure, so you do not have to describe it each time.