Skip to content
cyberfleetcyberfleetcyberfleet

Operator

Part of the cyberfleet plugin. See that page for install instructions.

Trigger: invoked for fleet-level dispatch: spawning, listing, and pruning ships, and routing messages between sessions. Invoking the skill connects your session to the command center, wherever you invoke it. Not for in-ship mission work (that’s the Pod).

The Operator is your interface to the fleet. It talks with you, and with no one else.

In the design

Section titled “In the design”
  • One seat. The Operator sits on the Command Center’s Dashboard. The session in that seat need not stay running; you start it when you want to talk.
  • Answers questions itself. It reads cyberfleet status, gh, and channels, and never wakes a Captain to answer a question.
  • Relays work up. It files the issue or finds the one you named, and finds its ship in the ship registry. For a repository that is not cloned on this machine, it asks you where to put it, suggesting a path. It then opens the mission’s channel with your words, verbatim, as the first entry, and mentions the ship’s Captain, which starts the Captain if it is not running. The Operator stays a member: the Captain posts the mission’s outcome there and mentions it, which wakes it but never starts it.
  • Coordinates nothing. It never spawns a Pod and never lands a pull request. Planning belongs to the Captain, and landing to the Coordinator.
  • Calling takes over nothing. Invoking /operator outside the Operator’s seat reaches the one Operator. It never makes the calling session an Operator.

The full path a request travels is in lifecycle.

What ships today

Section titled “What ships today”

The Captain and the Coordinator are not shipped, so the shipped operator skill also does their work:

  • Spawns every ship: your first, a new peer session, or a parallel worktree-ship on a project that’s already a ship. Pod never spawns.
  • Lists the live ships and, via cyberfleet missions, which need the Council’s hands: ships × SDD-mission × gate × leash, derived from SDD state.
  • Watches the ships it spawns and lands their work. Each ship opens a pull request and reports back to the session that spawned it, not to whichever session opened Operator most recently. When it dispatches, Operator tells you it will merge each of those pull requests once it is clean (the ship reported it done, it has no merge conflict, no review is blocking it, and CI is green on the merged result), and asks you to reply. Your reply is what lets it merge them without asking you again. The order to dispatch alone does not, and neither does Claude Code auto mode, which blocks a merge you did not ask for in your own words. Until you reply, a clean pull request waits for you to approve that merge. A merge the harness refuses waits for you too; Operator never retries it or works around it. Anything short of clean waits for you.
  • Orchestrates several ships on one order: merges their work in dependency order, and after each merge tells the ships still open to rebase, adapt to what landed, and re-verify.
  • Keeps one holder of the command center. The standing operator is a single long-lived session working from its home (~/code, say). A session you open Operator in takes that claim only when nobody holds it, so dispatching from inside a project never pulls the command center away, and only the holder reads and clears the command center’s mailbox. Register the operator owner with a home (--home) so that, once your cyberlegion release supports it, mail arriving with no holder spawns one there.
  • Routes messages between ships and sweeps away the dead ones.
  • Needs a multiplexer to spawn. Outside tmux or herdr the spawn fails and Operator reports it. Dispatching the Pod as a sub-agent instead is tracked in cyberfleet#113.
  • Relays what the Council decided, never an approval of its own: the ship receives your own words (just “Approve”, or your sentence nearly verbatim) with nothing added, and Operator records your words, who relayed them, and what they cover on the work’s thread. Operator can pass on no more authority than it holds, so it cannot tell a ship that a merge is approved. The merge authority your reply gives it stays with Operator; a ship never merges its own work on that authority. A ship’s Pod merges only when you answer, in its own session, the merge offer it made itself.

The headless counterpart, the headless-operator subagent, runs the same dispatch loop unattended.

Section titled “Related”