mco-org/squad: four clients installed three different ways, one command that clears all state, and a protocol version baked into the slash template

Seven runtime dependencies, no argument parser, nineteen command rows

The manifest is short enough to read in full. There are seven runtime dependencies: anyhow, serde with derive, serde_json, serde_yaml at 0.9, rusqlite at 0.31 with the bundled feature, chrono, uuid with v4, and fs2. The development set is tempfile, assert_cmd and predicates. Two details do real work. The bundled feature on rusqlite means the SQLite library is compiled into the binary rather than linked against a system copy, which is what lets the whole coordination state be a single file with nothing to install. fs2 provides advisory file locking, which is the mechanism that keeps several processes from corrupting that file. And there is no async runtime in the list, which matches the promise that there is no daemon and no background process and that every command is a one-shot operation. The surprise is on the other side. That manifest has to support a table of nineteen command rows, including flags such as --json, --wait, --timeout, --refresh-roles, --protocol-version and a --since value that accepts either RFC 3339 or Unix seconds, and no argument-parsing crate appears anywhere in the dependency list.

Four clients, three file formats, and one that uses a skill instead of a command

The setup step writes the same slash command into four different places in four different formats. Claude Code gets a markdown file at ~/.claude/commands/squad.md. Gemini CLI gets a TOML file at ~/.gemini/commands/squad.toml. OpenCode gets markdown at ~/.config/opencode/commands/squad.md. Codex is the odd one: it gets a skill file at ~/.codex/skills/squad/SKILL.md, which is a different mechanism, and the document notes that Codex users invoke it as $squad with a dollar sign rather than /squad with a slash. So the headline promise of one slash command is really four integrations, three file formats, two invocation syntaxes and two different configuration directories, one of them under .config rather than a dotfile directory named after the tool. The generated templates are the part that ties them together, joining with the platform client type and the current supported protocol version at generation time, so the slash command each tool reads is written to match the tool that will run it.

init writes three instruction files and Codex is not one of them

squad init does more than create a directory. It creates .squad/, appends .squad/ to .gitignore, and adds a short squad collaboration section to CLAUDE.md, AGENTS.md and GEMINI.md, but only when those files do not already contain one. Three files for four supported clients, and the missing one is Codex. That omission lines up with the mechanism difference above: Codex consumes a skill under its own configuration directory rather than a project instruction file, so a project-level markdown convention has no obvious place to go. It also means a team where half the agents run Codex gets a project where the Codex agents have no in-repo note explaining the collaboration protocol, and the only written guidance they get is whatever the generated skill file carries. The --refresh-roles flag is narrower still: it rewrites only the builtin manager, worker and inspector files under .squad/roles/. Roles you wrote yourself survive a refresh, and nothing in the command list validates them.

One command clears all state, and the state is gitignored

The last row of the command table is squad clean, described as clearing all state. There is no confirmation flag, no dry run, no --force and no subset option anywhere in the entry, unlike the tmux launcher, which does document a --dry-run. What it removes is the .squad/ directory, which init has just added to .gitignore, and that directory is where the SQLite database lives along with the role files and any prompt files the launcher generated. Two things follow. Because the directory is gitignored, none of it is in version control, so there is no history to restore from and no other machine to copy it from. And the state is not only a cache: it holds in-flight task assignments, the message history the history command reads, and the unread-message queue that pending reports. A tool whose normal operating mode is one-shot commands, with no server to reconstruct from, has put its durable state in the one directory the user has been told to keep out of version control, and given the user one unqualified word to delete it.

Auto-suffixed IDs mean an agent may not know its own name

Identifiers are assigned by arrival order. The usage diagram shows two workers in separate terminals, and the second is auto-assigned worker-2 with the note that the ID conflict was resolved automatically; the document states that multiple agents with the same role get worker, worker-2 and worker-3. join confirms it, auto-suffixing if the ID is taken, and the agents command will list them. That is convenient right up to the point where an agent has to address someone. Most commands take identifiers as positional arguments: send takes a from, a to and a message, leave takes an id, receive takes an id, and the task subcommands take an agent and a task id. An agent that asked for worker and was given worker-2 has to be told its new name, or discover it by listing agents, before it can send, receive, complete a task or leave. The state does not record which terminal asked for which role, so nothing can match the two back up automatically. The default of two workers therefore needs one round of discovery before the loop described in the diagram can actually start.

The protocol version is baked into the template at generation time

Two entries in the command table point at a version negotiation layer that the rest of the document never explains. join takes --client with a fixed set of four values and --protocol-version with a number, and its description says omitted capability metadata stays NULL. The agents command is more revealing, because its --json output is documented as emitting one JSON object per line including raw and effective capability fields and protocol-derived support booleans. So the database distinguishes an agent that reported no capabilities from an agent that reported nothing at all, and derives support flags from the protocol version. That is a reasonable design for tools that will be installed at different times on different machines. The gap is the upgrade path. The generated slash templates join with the current supported protocol version when setup runs, which means the version is baked into a file under the user's home directory at a moment in the past. Nothing in the visible text says whether re-running setup after a binary upgrade is required, and an older template against a newer binary is exactly the case the NULL field was built to survive.

The optional launcher needs Ruby, reads YAML, and only speaks Claude

There is a second implementation in this repository, and the document is explicit that it is separate from the Rust CLI. The helper is scripts/squad-tmux-launch.sh, and its requirements are tmux, ruby and claude, with ruby named as the thing used to parse launcher.yaml. It can read project-local launcher config from .squad/launcher.yaml, read a task brief from .squad/run-task.md, generate manager and inspector prompt files under .squad/quickstart/, start a tiled tmux session, inject /squad into Claude panes, and optionally create an isolated git worktree before launching agents. Three things follow from that list. The launcher is Claude-only, while the core binary supports four clients, so the automation and the client support cover different subsets. It is a shell script that shells out to Ruby to parse a YAML file, in the same repository where the Rust manifest already carries serde_yaml, so both stacks can read YAML and only one of them is compiled. And it is the only documented command in the project with a dry run.

Three install paths, one of them manual on Windows

The install section gives three routes, and they are not equally complete. macOS gets a Homebrew tap. Windows gets a manual sequence: download squad-x86_64-pc-windows-msvc.zip from the releases page, extract squad.exe into a folder such as C:\Tools\squad, then add that folder to PATH. Source builds go through cargo install against the git URL. So the only path for a Linux user without a Rust toolchain is to compile it, there is no package in the section for apt, a .deb, an rpm, nix, scoop or winget, and the Windows instructions are the only ones that require a manual configuration change to the machine. The whole list fits in one block:

# Homebrew (macOS)
brew install mco-org/tap/squad

# Windows (GitHub Releases)
# 1. Download squad-x86_64-pc-windows-msvc.zip
# 2. Extract squad.exe to a folder like C:\Tools\squad
# 3. Add that folder to PATH

# Or download another prebuilt binary from GitHub Releases
# https://github.com/mco-org/squad/releases

# Or build from source
cargo install --git https://github.com/mco-org/squad.git

The front page is also not the whole of what the repository holds. Alongside the documented paths there is an install.sh at the root and a Formula/ directory for the Homebrew tap, and the releases page is named as the place to get other prebuilt binaries. The Windows triple in the file name, x86_64-pc-windows-msvc, is also the only architecture the document commits to.

Editorial conclusion

squad is an interesting answer to a question most multi-agent tools skip: how do independent CLI processes in separate terminals find each other without a server. A gitignored directory, a statically linked SQLite file and an advisory lock is a defensible design for a single machine, and the four-client setup table is more complete than most projects of this size manage. Four things to check before you rely on it. The state is not version controlled, so read squad clean as a destructive command with no confirmation flag, no backup and no undo. Roles are files, and the refresh flag rewrites only the three builtin ones, so anything you write yourself survives but nothing validates it. The slash templates carry the protocol version they were generated with, and nothing says whether re-running setup after a binary upgrade is required. And the only install path for Linux is cargo install, while Windows means extracting a zip and editing PATH by hand. If you need a hosted, shared, audited coordination layer, this is not it. If four terminals on one laptop is the problem, it is a small enough tool to read end to end in an evening.

Frequently asked questions

Official sources

1. License: MIT
2. mco-org/squad on GitHub
3. Project website
4. README
5. Releases