Borrowing it
Nothing to install: this file belongs to bredmond1019/claude-sdk-rs. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/bredmond1019/claude-sdk-rs/main/.claude/commands/orchestration-commander.mdgit clone --depth 1 https://github.com/bredmond1019/claude-sdk-rsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/bredmond1019/claude-sdk-rs/orchestration-commander)<a href="https://agentmods.dev/commands/bredmond1019/claude-sdk-rs/orchestration-commander"><img src="https://agentmods.dev/badge/commands/bredmond1019/claude-sdk-rs/orchestration-commander/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/bredmond1019/claude-sdk-rs/orchestration-commander"><img src="https://agentmods.dev/badge/commands/bredmond1019/claude-sdk-rs/orchestration-commander.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00000 | $0.05590 |
| Opus 5.5 | $0.00000 | $0.02236 |
| Sonnet 5.5 | $0.00000 | $0.01118 |
| Haiku 4.5 | $0.00000 | $0.00559 |
Grade A, and why
orchestration-commander 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 11d 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 — 332 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Orchestration Commander — a stateless drain that re-derives and reports the remainder
One drain: a single Claude turn, woken by scripts/commander_drain.sh via bastion ask, that
routes this repo's message queue, re-derives the fleet's surfaces the only safe way (running the
derivation, never guessing which dirty files are derived), and reports whatever is left over that
a human or a lane needs to see. It never implements a block and never edits another lane's chain.
Variables
None. A drain takes no arguments — everything it needs is already on disk: the queue, the lease
and registry records, and the repo's own planning/state.json. See "Stateless per drain" below for
why that is deliberate, not a limitation.
The six steps, in order
1. Validate and survey the whole queue tree, then drain this lane's inbox
drain_queue() and complete_message() are Python functions inside scripts/check_messages.py
— a drain is a Claude turn with shell access, not a Python process, so naming a function is not an
instruction a drain can execute. Everything below is a shell command, run as written.
a. Validate every message record and layout invariant across every lane, not just this one's.
python3 scripts/check_messages.py --quiet
discover_queues() walks <lock_dir>/queue/<repo>/<lane>/ for every repo and lane under the
resolved lock dir — this single invocation already covers the whole tree, which is exactly what
thirteen consecutive drains never ran. Exit 0 means every record and receipt-backed transition in
every lane's inbox//processing//done/ is well-formed; a nonzero exit means at least one is
broken, and its FAIL <path> lines name which. Resolve <lock_dir> the same way the script does
— --lock-dir, else FLEET_LOCK_DIR, else a brain.toml found by walking up from cwd — never
assume a repo-relative path (see scripts/check_lane_agents.py's identical precedence).
b. Age-check every inbox file, and report an absent queue directory and an empty one as
different findings. check_messages.py validates message shape; it does not report how long a
file has waited, and it does not distinguish "this lane has never written a queue dir" from "this
lane's queue dir exists and is empty." Both distinctions matter — a count of undrained messages
reads as backlog, "10 hours old" reads as a failure; and "no queue dir for my lane" is why the
first thirteen drains read "nothing to drain" instead of "never checked."
for q in "$LOCK_DIR"/queue/*/*/; do
q="${q%/}"
inbox="$q/inbox"
if [ ! -d "$inbox" ]; then
echo "ABSENT $inbox"
elif [ -z "$(ls -A "$inbox" 2>/dev/null)" ]; then
echo "EMPTY $inbox"
else
for f in "$inbox"/*.json; do
[ -e "$f" ] || continue
now=$(date +%s)
mtime=$(stat -f %m "$f" 2>/dev/null || stat -c %Y "$f")
echo "MSG $f age=$(( (now - mtime) / 60 ))m"
done
fi
done
Run this over every <lock_dir>/queue/<repo>/<lane>/ the tree contains — not only the drain's
own lane. Every MSG line surfaced for a lane other than this one is reported, not acted on
(step 4's board is where it lands) — routing another lane's message is that lane's call, never
this drain's (see "Out of scope" precedent in the block that shipped this step,
BT.ticket.commander-must-validate-the-whole-queue-tree).
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.
- 11d ago First seen · 332 lines · 0 tokens per session scan A eeab8389a9d8
orchestration-commander is a command published in the GitHub repository bredmond1019/claude-sdk-rs (23 stars, last pushed 1mo ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 5,590 tokens. 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-10-26.
orchestration-commander compared with commands from other repositories
| Mod | Type | Stars | Last push | Licence | Scan | Tokens | Works with |
|---|---|---|---|---|---|---|---|
| orchestration-commanderbredmond1019/claude-sdk-rs | Command | 23 | 1mo ago | Apache-2.0 | A | 0 | Claude Code |
| checklistgithub/spec-kit | Command | 148k | yesterday | MIT | A | 13 | Claude Code |
| clarifygithub/spec-kit | Command | 148k | yesterday | MIT | A | 27 | Claude Code |
| specifygithub/spec-kit | Command | 148k | yesterday | MIT | A | 13 | Claude Code |
| analyzegithub/spec-kit | Command | 148k | yesterday | MIT | A | 26 | Claude Code |
| convergegithub/spec-kit | Command | 148k | yesterday | MIT | A | 35 | Claude Code |
| implementgithub/spec-kit | Command | 148k | yesterday | MIT | A | 14 | Claude Code |