A control plane for your work across GitHub and GitLab. You hand it a goal; it splits the goal into tasks, runs an AI agent session on each one in a real repo, and gives you back change requests — pull requests, merge requests — to review.
It is one repo holding two things: a map of your projects, and the orchestration of the agent sessions run against them, using thurbox. It keeps the plan and the log and never the work itself — every branch lives in a worker's own git worktree, in the repo that work belongs to.
your prompt
│
▼
┌───────┐ one topic on disk, your words kept verbatim
│ topic │
└───┬───┘
┌─────┼─────┐ one repo, one branch, one brief each
▼ ▼ ▼
task task task
│ │ │
▼ ▼ ▼ a thurbox worker session per task,
worker worker worker each in its own git worktree
│ │ │
▼ ▼ ▼
PR PR PR you review; you merge
Independent tasks all go out at once — that is the point of it. Workers share no context with you and none with each other, so each gets a brief written from scratch, and each reports back by writing a file rather than by interrupting you. You watch it happen in the queue pane.
One line clones fleet, checks what it needs, and installs its thurbox extension:
curl -fsSL https://raw.githubusercontent.com/Thurbeen/fleet/main/install.sh | shOr read it before you run it:
curl -fsSLo install.sh https://raw.githubusercontent.com/Thurbeen/fleet/main/install.sh
less install.sh
sh install.shIt clones into ~/fleet; FLEET_DIR=<dir> or --dir <dir> puts it elsewhere,
and a machine whose Mission Control session already opens a checkout reuses
that one. Pick the place you will keep: the extension bakes the path in,
and moving the clone later costs the lead session its conversation. Run it again
and it converges — an existing clone is fast-forwarded, and one that has
diverged, or has uncommitted changes in the way, is refused rather than reset.
It installs no dependency: when a required one is missing it stops before the extension and prints the lines to run. Nor does it put the queue pane on your screen — the first Mission Control session asks you that, once.
Then open thurbox, start the Mission Control session, and run:
/fleet-onboarding
The onboarding skill does the rest rather than instructing you through it — seven steps: dependencies, this checkout, your GitHub owners, the repo map, the thurbox extension, the queue pane on screen, and the reconciler. The one-liner already did three of them, so those come back as checks. It verifies each one and names anything missing with its remedy before it writes a thing. Run it twice and it converges.
Four of those steps ask you something, and only four. Whether to install the
dependencies that are missing; which of the owners it found on your machine the
map should cover; where the queue pane goes (a column on the right, by
default), unless you already answered that; and whether to bring the reconciler
up. It reads every gh account
on the machine — not just the active one — your git config and the remotes of
the clones you already have, so the owners step is a list to confirm rather
than one to type.
What it needs, and what it will tell you itself:
./scripts/preflight.sh # every dependency, in three tiers, with why
./scripts/preflight.sh --commands # exactly what to run for the ones missinggit, gh (authenticated), jq, python3 with PyYAML and thurbox-cli
2.19.0 or newer are required; quota-axi and glab are recommended, and
each names what degrades without it. gh is not optional even on a GitLab-only
fleet — it is what builds the repo map. A glab that is logged in is also the
configuration: fleet asks it which GitLab instances this machine holds, so a
self-hosted one needs no variable exported for it.
That done, open the Mission Control session in thurbox and give it a goal.
Afterwards, when you gain an owner, a repository or a whole gh account, one
command says what your map does not cover yet and catches it up:
./scripts/add-owner.sh # what is new, grouped by the account that reaches it
./scripts/add-owner.sh --all # add them, then sync and say what moved in the mapIt logs nobody in and writes nothing until you ask it to.
The queue pane is the live view: the queue in a thurbox column, so you do
not leave the terminal for it, with a bar for each subscription's fuel above
it. Onboarding installs it and F3 opens and closes it. It displays and
does not control — ./scripts/queue.sh stays the only thing that writes.
It reads the same four files per task and no fifth: the plan, the progress, the
outcome, and the change request. A column is narrow, so it draws only what you
would act on from a glance and leaves the rest to ./scripts/queue.sh show.
The machinery is tracked; what a running fleet writes is not. Your owners file,
your generated map, your project notes, your queue and your run logs live in
your working copy and are gitignored — this repo is public, and none of that is
something to publish, so back that copy up yourself if it matters beyond this
machine. .gitignore's header names every path and the reason for each.
Your settings are yours the same way, and each has a tracked .example beside
it documenting the format: registry/owners.txt (the owners the map covers),
orchestration/voice.conf (what the lead calls you), session-glyphs.conf
(the mark fleet's sessions wear), orchestration/publish.conf (the publish
method and the command that produces it), orchestration/agent.conf (which
agent your workers run) and orchestration/auto-merge.conf — the
repositories fleet may merge in unattended, which the tracked copy deliberately
leaves empty. Clone this and fleet merges nowhere until you say otherwise; no
operator inherits another's merge rights.
AGENTS.md— how an agent should operate inside this repo, and the reasoning behind how the queue runs.CONTRIBUTING.md— the gate (./scripts/check.sh), the squash-only merge policy, the layout conventions.- Every script's header is its own full usage.
./scripts/fleet-status.shanswers "where are we?" in one read-only call — fuel, queue, sessions, pull requests, checkout.
MIT — see LICENSE.