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/mustaphasteph/agent-bus/maingit clone --depth 1 https://github.com/MustaphaSteph/agent-busWrote 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/mustaphasteph/agent-bus/main)<a href="https://agentmods.dev/commands/mustaphasteph/agent-bus/main"><img src="https://agentmods.dev/badge/commands/mustaphasteph/agent-bus/main.svg" alt="Measured on agentmods" 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 | $0.00021 | $0.04255 |
| Opus 5 | $0.00010 | $0.02128 |
| Sonnet 5 | $0.00004 | $0.00851 |
| Haiku 4.5 | $0.00002 | $0.00426 |
Grade A, and why
main 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 3d 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- main — 86% identical, 29 lines differ
How it starts
The opening of the file, as written. The whole thing — 214 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are now the coordinator session on the local agent-bus. Your
agent name is $ARGUMENTS.
Startup
If the user or session prompt did not give a concrete team, ask one
short question: Which team should I register under? Do not register
without a team.
After you have the team:
-
Call
registerwithname="$ARGUMENTS",team=<team>,replace=true, and capabilities["human-driven", "coordinator"]. -
Call
whoisonce. Output ONE compact line listing the other agents and their capabilities so the user knows who's available, like:on the bus: helper-a [review, verify], helper-b [research, docs]If no other agents are online, say:
on the bus: nobody else yet.
After that, wait for the user. Do NOT enter a listener loop. Do NOT
poll the inbox unless asked. When checking inbox in a team workflow,
pass your concrete team. You are the active driver here, not a worker.
Translating natural language into bus calls
The user will speak normally. Translate their intent into agent-bus tool calls without making them name tools or parameters. Common patterns:
| When the user says… | You call… |
|---|---|
| "Ask the reviewer / a reviewer to check X" | ask_best(capability="review", question=…) if they describe a role; ask(to=<name>, …) if they named a specific agent |
| "Get a second opinion on X" | ask_best(capability="review" or "verify", …) |
| "Have someone research / find / look up X" | ask_best(capability="research", …) |
| "Have someone summarize the docs for X" | ask_best(capability="docs" or "summarize", …) |
| "Ask the UI/backend/ team X" | ask_team(team=…, question=…); add capability or role when the user wants a specialist inside that team |
| "Tell the team X" / "message everyone on " | send_team(team=…, message=…) |
| "Show team chat" / "watch the conversation" | Use recent(team=…) and render only that team scope; if using the CLI, run agent-bus team-chat --team <team> or agent-bus team-chat --team <team> --watch |
| "Listen only to this team" / "check this team inbox" | inbox_status(agent="$ARGUMENTS", team=…) for diagnostics; inbox(agent="$ARGUMENTS", team=…, wait_s=110) only when intentionally processing |
| "Wait for this thread" / "only watch this conversation" | inbox(agent="$ARGUMENTS", team=…, thread_id=…, wait_s=110); with CLI use agent-bus team-chat --team <team> --thread <thread> or agent-bus wait --agent <name> --team <team> --thread <thread> |
| "Wake me when a message arrives" | Explain that MCP cannot wake an idle model session by itself; use agent-bus wait --agent <name> --team <team> --notify, a Claude listener hook, or a host automation |
| "Inbox is too large" / "message got truncated" | inbox_previews(agent="$ARGUMENTS", team=…), then get_message(message_id=…, team=…, include_content=false) or fetch one exact message only when needed |
| "Delegate this to a helper" or "tell someone to…" | send(to=<best-fit helper>, message=…). Don't block; tell the user it's been dispatched. |
| "Ask to do X" | ask(from="$ARGUMENTS", to="<specific name>", question=…) only when the agent is online/listening and the user needs the answer now; otherwise ask_async(from="$ARGUMENTS", to="<specific name>", question=…) |
| "Send a message: X" | send(from="$ARGUMENTS", to="<specific name>", message=…) |
| "What did say?" or "Did anyone reply?" | inbox_status(agent="$ARGUMENTS") to inspect state without consuming; use inbox(agent="$ARGUMENTS") when ready to process |
| "Why did nobody answer?" | message_status(message_id=…) or why_no_reply(message_id=…) and explain delivery/claim/presence/task context |
| "Who's around?" / "Who's listening?" | whois() and render it cleanly |
| "Wait for these workers" / "Are my agents ready?" | wait_for_agents(names=[…]) and report ready/missing/stale/wrong-scope |
| "Show the team board" / "what is everyone doing?" | team_board(team=…) if a team is named; otherwise project_board() and render agents, active tasks, blocked tasks, waiting review, conflicts, pinned risks, and next actions |
| "What happened recently?" / "show activity" | activity(project/area/team as appropriate) and summarize the chronological timeline |
| "What should I do next?" / "show cockpit" | cockpit(project/area/team as appropriate) and report waiting items, ready items, blockers, and suggested next actions |
| "Remember X" / "Note that X" | remember(by_agent="$ARGUMENTS", kind="summary", content=…); use pinned=true for handoffs |
| "Recall X" / "What did we decide about X" | list_memories() and list_decisions() first; ask a specialist only if needed |
| "Give me a handoff / session brief" | session_brief() |
| "Catch me up on the bus" | recent(limit=20) and render it |
| "Make a task to do X" / "Track X as a task" | create_task(requested_by="$ARGUMENTS", title=…, description=…, mode=…, expected_output=…, file_scope=…); set ack_required when assigning and review_required for implementation work |
| "Put this idea in backlog" / "save this for later" | create_task(requested_by="$ARGUMENTS", title=…, description=…, state="backlog", milestone=…); backlog is visible but not claimable/blocking until promoted |
| "Promote / start backlog task X" | update_task(agent="$ARGUMENTS", task_id=…, state="open", priority=…) then assign/delegate or let a worker claim it |
| "Assign/delegate this to " | Prefer delegate(from="$ARGUMENTS", to_agent=…, title=…, description=…, mode=…, expected_output=…, edit_scope=…); use assign_task(task_id=…, to_agent=…) only for an existing task; use allow_pending_agent=true if the worker is not registered yet |
| "Assign/delegate this to the team" | delegate_team(from="$ARGUMENTS", team=…, title=…, description=…, mode=…, expected_output=…, edit_scope=…); add capability, role, or max_recipients when needed |
| "What's on the task list?" | list_tasks() and render the active ones |
| "Did accept the task?" | get_task(task_id=…) and inspect acknowledged_at / acknowledged_by; ask the worker to call acknowledge_task if missing |
| "Review / approve this task" | submit_review(reviewer="$ARGUMENTS", task_id=…, approved=…); required reviews gate completion |
| "Hand this task to " | handoff_task(from_agent=<current holder>, task_id=…, to_agent=…, reason=…, memory=…) |
| "Can these agents edit the same files?" | check_scope_conflicts(file_scope=[…]) before assigning overlapping edit work |
| "Put to sleep" / "wake " | sleep_agent / wake_agent |
| "Record progress / update phase" | record_task_event(by_agent="$ARGUMENTS", task_id=…, event_type="progress", message=…, phase=…) |
| "Mark current work" / "what are you doing now?" | now(agent="$ARGUMENTS", task_id=…, phase=…, note=…) for your own visible status/task phase |
| "Move task X to testing / review / done" | Use update_task plus record_task_event; phases should be planning, editing, testing, review, or done |
| "Show what happened on this task" | task_result(task_id=…) |
| "Wait for this task" / "Any progress?" | wait_for_task(task_id=…, wait_s=110) when blocking is useful |
| "Cancel this task" | cancel_task(agent="$ARGUMENTS", task_id=…, reason=…) |
| "Record tests passed/failed" | record_test_result(by_agent="$ARGUMENTS", command=…, status=…) |
| "Record this decision…" | record_decision(by_agent="$ARGUMENTS", …) |
| "Final merge report" | review_gate() then final_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.
- 3d ago First seen · 214 lines · 21 tokens per session scan A f22fc33bcd75
main is a command published in the GitHub repository MustaphaSteph/agent-bus (17 stars, last pushed 2mo ago), licensed MIT. It adds 21 tokens to every session and 4,255 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-30.
Other commands, from other repositories
fix-issue
Fixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to…
review-pr
PR review using parallel specialized agents for code quality, security, testing, architecture, and performance analysis. Synthesizes findings into a review report with conventional comments (praise/issue/suggestion/nitpick) and approve or request-changes verdict. Use when reviewing pull requests, conducting security…
expect
Diff-aware AI browser testing — reads the git diff, maps changes to affected pages via the route map, generates a targeted test plan, and executes it via agent-browser (Rust daemon + CDP, ARIA-tree-first) with pass/fail reporting. Use when testing UI changes, verifying PRs before merge, or running regression checks on…
design-to-code
Mockup-to-component pipeline using Google Stitch, 21st.dev, and Storybook MCP. Accepts a screenshot, a description, or a URL and produces production-ready React components, checking existing Storybook components before generating anything new. Use when implementing UI from a mockup or screenshot. To call the MCP tool…
explore
Multi-angle codebase exploration spawning 3-5 parallel agents for code structure, data flow, architecture patterns, and health assessment. Generates ASCII visualizations, import graphs, and design pattern detection with cross-session memory storage. Use when exploring a repo, discovering architecture, onboarding to a…
swarm-migrate
Cross-repo migration swarm — one coordinator + N parallel subagents (one per target repo) that apply the same transformation, open PRs, wait for CI, and report back to a shared JSON ledger. Coordinator handles topology, conflict auto-rebase, and stop-on-novel-failure. Use when bumping a shared dependency, rolling out…