Makes a project fleet-ready: applies standard Claude Code settings and runs the fleet mod, so the session can orchestrate a fleet of delegated workers.

This plugin ships no credentials. Every secret is referenced by environment-variable name; the values stay with the user. Nothing the plugin writes is unsafe to commit.

Scope — lead-side only

This plugin configures the session you are sitting in: a lead, or any human-started Claude Code session that wants to talk to the daemon. It deliberately does not carry the worker playbook skills or the role agent definitions, and it cannot:

the launcher adds --agent only when <worktree>/.claude/agents/<role>.md exists in the member's own tree (ClaudeCodeLauncher.java:371,391), so agent files must live in the repo;
a member's CLAUDE_CONFIG_DIR points at its profile's config directory (ClaudeCodeLauncher.java:285), so it never reads the operator's plugin store.

Member-facing assets travel in the worktree, not in this plugin. See fleetd #362.

What it is not

The plugin is the client-side setup, not the bridge. fleetd is a separate daemon and herdr is a separate PTY multiplexer, each with its own lifecycle and install, and the plugin does not try to install either on your behalf. It also does not mount the daemon for you — mounting is the instance's or the project's own .mcp.json, and /fleet:setup is the one thing in this plugin that still helps with that (it writes the project-level entry).

Install

/plugin marketplace add https://git.ltms.dev/fleet/fleetd
/plugin install fleet@fleetd

Mount the daemon yourself — this plugin carries no mount of its own. Either add the entry below to your Claude Code instance's own .claude.json, so every project you open there gets it, or run /fleet:setup in the project you want to onboard, which writes the same entry into that project's .mcp.json:

{
  "mcpServers": {
    "fleet": {
      "type": "http",
      "url": "http://127.0.0.1:8765/mcp"
    }
  }
}

Then, in the project you want to onboard:

/fleet:setup

What you get

Component	Effect
`skills/setup`	`/fleet:setup` — preflight, project settings, credential guidance, and verification. Also the only thing in this plugin that helps mount `fleet`: it writes the project `.mcp.json` entry shown above.
`hooks/register.js` (the fleet mod)	Cross-account session messaging while the plugin is enabled: `/fleet-peers`, `/fleet-mail`, `/fleet-whoami`, and a background poll that delivers mail fleetd queued for this pane. A spawned worker or architect skips that poll, because it already gets its brief pasted into its pane.

Whichever file mounts the daemon, name the server fleet. That is PeerLauncher.MCP_MOUNT_NAME in the daemon, the name a spawned member's own mount carries, and the name the mcp__fleet__* role heuristic in CLAUDE.md keys on.

Upgrading from 0.2.0 — breaking

The plugin no longer mounts the daemon. It used to carry its own .mcp.json, pointed at ${FLEETD_MCP_URL}, and that file is gone. The mod still reads FLEETD_MCP_URL, but only as an optional override of the address it calls (default http://127.0.0.1:8765/mcp). Mount fleet yourself: add the entry under Install above to your instance's .claude.json or to the project's own .mcp.json, by hand or with /fleet:setup.

Version 0.1.0 named the mounted server fleetd, which produced two mounts of one daemon for anyone who also had a project-level .mcp.json. A project that pre-allowed mcp__fleetd__fleet_whoami in .claude/settings.json must be updated to mcp__fleet__*.

Verifying a setup

The setup skill ends by requiring a real spawn, not a health check. /healthz only reports that the daemon can reach herdr; a protocol mismatch between the daemon's adapter and the herdr binary leaves health green while every spawn fails. Only a spawn that reaches ready proves the fleet.

Local development

claude --plugin-dir ./plugin
claude plugin validate ./plugin

/reload-plugins picks up edits without restarting the session.