Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/chankov/agent-fleet/setup-agent-fleetgit clone --depth 1 https://github.com/chankov/agent-fleetWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00017 | $0.01082 |
| Opus 5 | $0.00009 | $0.00541 |
| Sonnet 5 | $0.00003 | $0.00216 |
| Haiku 4.5 | $0.00002 | $0.00108 |
Grade A, and why
setup-agent-fleet scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 26 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Invoke the agent-fleet:guided-workspace-setup skill.
Run the guided install for a target workspace. If the user passed a workspace path, use it; otherwise ask for it. Detect the running coding agent and confirm it with the user.
Analyse the workspace. If prior install state is found (.ai/agent-fleet-setup.md or a populated agent directory), run the Doctor preflight first (Step 5) — scan for broken symlinks and stale persona references, present findings as a table, and apply the fixes the user picks before continuing.
The Skills group draws from two roots: fleet-native skills/ and the vendored upstream import vendor/agent-skills-upstream/skills/ (see docs/UPSTREAM-SKILLS.md). On a name collision the native copy wins — never offer the vendored duplicate as a separate row.
Then present the install menu as one multi-select per group — 7 groups (4 shared: Skills, Agent personas, Commands/prompts, References & Hooks; 3 pi-only: pi extensions & runtime skills, pi harnesses, External pi packages — so a claude-code workspace sees just the 4 shared groups) with ★ marking recommendations. Multi-type groups carry a leading Group column labelling the sub-category (lifecycle phase for Skills, rw/ro/pi-only for personas, etc.). Each group renders as a Pick | Item | Group | Status | Rec | Purpose table; every row carries an explicit status text — installed · up to date, installed · outdated, installed · modified, not installed, or broken · skipped in preflight. Installed items are pre-checked [x] so unchecking = remove; not-installed items start [ ]. Per-group reply shortcuts: all, recommended (adds ★ items on top of the pre-selection — never unticks installed ones), none, keep (accept the pre-selection unchanged), or a list of picks. Never offer setup, doctor, or guided-workspace-setup — those are installer-only and live in the source agent-fleet repo.
Unchecking an installed item means remove it, but removal is scoped: only act on items whose name is in the agent-fleet inventory and that are recorded in ## install-status (or are symlinks resolving into the source repo). User-authored skills, custom commands, third-party plugins, and unrelated settings/env keys are left untouched and logged as "Skipped — not owned by agent-fleet".
No cross-tool substitution. Each row is offered only when the source file the chosen agent needs already exists — for pi, that means .pi/prompts/<name>.md, .pi/extensions/<name>/, etc. Never fall back to .claude/commands/ (or another agent's tree) to satisfy a pi prompt request; items missing their per-agent source are filtered out of the menu entirely.
Personas are generated for non-pi targets. The personas group lists the full availability roster from node <source-root>/bin/cli.js transform-persona --list --agent <agent> (pi-only personas — bowser, orchestrator — appear only when the agent is pi). For claude-code/opencode the apply step installs personas via transform-persona --agent <agent> --workspace <workspace> <name…> — always a generated copy, even in symlink mode — and records the rows with transformed: true; status checks diff against the generated output, not the raw canonical source.
pi harness companions. When the agent is pi, installing/refreshing/removing any harness also refreshes its companions — the justfile launch recipes, the team-up/coms-net scripts, the peer/team YAML, .pi/damage-control-rules.yaml, and .pi/harnesses/package.json. Refresh the justfile from the current source (rewriting only the agent-fleet:harnesses managed region so user recipes survive) so retired-harness recipes are pruned and new ones added; a stale justfile left after a harness change is the regression this prevents.
No mid-apply overwrite prompts. The Step 6 status text already warns that installed · modified rows will have local edits overwritten if kept ticked. The user's tick is the consent; the Step 9 confirmation is the single gate. During apply, refresh ticked items unconditionally — never pause to ask "should I overwrite this file?". Genuine errors (permission denied, missing source) still stop and report.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 26 lines · 17 tokens per session scan A 198682ad9968
setup-agent-fleet is a command published in the GitHub repository chankov/agent-fleet (10 stars, last pushed 7d ago), licensed MIT. It adds 17 tokens to every session and 1,082 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
git
Git operations with intelligent commit messages and workflow optimization.
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.