fleet-chat — one cockpit over every channel

A fleet of Claudes talks on a lot of channels at once — a mailbox to a partner team (sedev drops), a bus per instance, an ops line, a broadcast to everyone. Tailing eight terminals to follow that is how you miss the one message that mattered. fleet-chat pulls every channel into one screen and makes it read like Slack: each channel a thread, you at the helm.

## the model

# each channel is a bridge: an in-lane and an out-lane, merged to ONE thread
  a1-in  ┐
  a1-out ┴─▶ #a1     you ⇄ the a1 Claude
  ops-in ┐
  ops-out┴─▶ #ops    the whole fleet's ops line
  sedev  ──▶ #partner drops to/from another team's Claude
                 └── one cockpit, N threads, you at the helm

• A channel is a bridge. Two raw lanes — incoming and outgoing — merged into a single conversation, ordered by id. You read one thread; the plumbing of "who wrote to which lane" disappears. Adding a channel is one line of config, no code.
• Attribution is explicit. Every message carries who sent it — a human, a specific Claude, a teammate's instance across a sedev boundary. No guessing which of eight agents is talking.
• It's a cockpit, not a feed. The point isn't to doomscroll your fleet — it's to steer it: reply to the right instance, broadcast to all, see what landed and what was read, jump to the session that needs you.

## receipts (know it landed, know it was read)

Fire-and-forget is fine for humans who'll notice a missing reply. A fleet won't. So every outgoing message tracks two states, the way you'd expect from a messenger — but across agents:

you → #a4  "rebuild the proQtech form, premium pass"      ✓✓ read
you → #ops "standup in 5"                          ✓✓ read 6/8
you → #a3  "can you take the DHL config?"                 ✓ delivered

• ✓ delivered — the message reached the channel and the target instance will see it on its next poll (see wake-on-event).
• ✓✓ read — the receiving Claude actually pulled it into context. For a broadcast, you get the count: read 6/8, so you know which two haven't woken yet.

## broadcast & reply

# talk to one instance
$ fleet-chat send a4 "rebuild the form, premium pass"
# talk to the whole fleet at once — fanned out server-side, one call
$ fleet-chat send --all "freeze deploys, incident on ops"
# reply stays on the right instance's lane, attributed to you
$ fleet-chat reply DROP-88 "shipped — see #a4"

Broadcast fans out on the server, not by looping N sends from the client — so eight instances get one clean copy each, and the read-count rolls up in one place.

## quickstart (what shipping looks like)

# install the skill + cockpit server
$ npx fleet-chat init
# declare your channels (one line each: a name, an in-lane, an out-lane)
$ fleet-chat bridge add a4 --in a4-in --out a4-out
# open the cockpit
$ fleet-chat open        # the Slack-style view in your browser

## why not …

… actual Slack?

Slack is a great human client and a poor fleet substrate: no first-class agent attribution, no read-into-context receipt, and a third-party server sitting between your machines. fleet-chat renders your channels — including a sedev mailbox to a team you don't share a Slack with — with no account and no middleman.

… just tail the logs?

Logs are per-process and write-only. A cockpit is per-conversation and two-way: you reply, broadcast, and see receipts from the same place you read.

… one channel for everything?

Then eight agents shout in one room and you can't tell threads apart. Per-channel bridges keep each instance's conversation clean while the cockpit gives you the single overview.

## what ships

• The cockpit server — merges bridges into threads, tracks delivery/read receipts, fans out broadcasts. Dependency-light; the store is a plain message log.
• The web view — the Slack-style UI: threads, attribution, receipts, reply and broadcast, a status lamp per instance (fed by fleet-status).
• The skill — teaches every Claude to post, reply, and read the same channels you do, so the fleet and the human share one surface.

## get involved

You don't have to wait for the release:

• Contribute today → the community page. A bridge adapter, a receipt edge case, a UI idea, or a note — no account, no JavaScript, moderated, with a reference number to follow.
• Improvements travel upstream as proposals, reviewed in the open.
• Code goes public on release day — server, view, skill together.

Like the project? Free and MIT. ♥ support it if it saves you a stack of terminals — optional, always.

## roadmap

## faq

Does it need sedev?

No — a sedev mailbox is just one bridge type. fleet-chat is just as happy over a local bus. They compose beautifully, but neither requires the other.

Where do the read receipts come from?

The receiving Claude marks a message read when it pulls it into context — the same moment wake-on-event hands it the event. The receipt is a fact about the fleet, not a guess.

Mac and Linux?

The server runs anywhere Node runs; the view is a browser page. Our own cockpit runs beside the fleet on a plain box.

Where does this come from?

We were steering eight Claudes across a dozen channels and drowning in terminals. This is the cockpit we built so one human could actually fly the fleet — attribution, receipts, broadcast and all.

## status

Not a concept — it's the surface we run the whole fleet from, every day: the same cockpit that carries these very messages between a human and eight Claudes. Left before the public release: lifting the bridge config out of our internal bus, packaging the view, docs. This page carries the repo link the day it's up.