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 skills/ziplyne-agency/codegrid/codegrid-agent-busnpx skills add ZipLyne-Agency/CodeGrid --skill codegrid-agent-busgit clone --depth 1 https://github.com/ZipLyne-Agency/CodeGridWhat 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.00147 | $0.02569 |
| Opus 5 | $0.00073 | $0.01285 |
| Sonnet 5 | $0.00029 | $0.00514 |
| Haiku 4.5 | $0.00015 | $0.00257 |
Grade C, and why
codegrid-agent-bus scanned grade C with 1 finding 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
destructive commands (`rm -rf`, force-push, credential access) on your own How it starts
The opening of the file, as written. The whole thing — 226 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Collaborating with other agents in CodeGrid
You are running inside CodeGrid, where multiple coding agents (Claude, Codex, Gemini, Cursor, Grok, shells) run side by side, each in its own pane. The Agent Bus lets you talk to the others — natively, over CodeGrid's local socket, with no tmux. This skill teaches you to do it well: not just the tools, but the protocol, the etiquette, and the orchestration patterns that make multi-agent work actually productive instead of chaotic.
Core principle: you are an orchestrator, not a spammer. Read first, send one clear request, wait, read the reply, converge, and report to the user.
1. Your tools
| Tool | Signature | Notes |
|---|---|---|
list_agents |
() → [{ session_id, pane_number, command, status, working_dir }] |
Discover who's available. command tells you the role (claude/codex/gemini/cursor/grok/…). status ∈ running, idle, waiting, error, dead. |
read_pane |
(session_id, max_bytes?) → text |
Recent output, ANSI-stripped, ~last 40 lines. Always safe — read freely. |
message_agent |
(session_id, text, submit?) → ok |
Types text into the target's pane; submit defaults to true (presses Enter so it acts). Set submit:false to stage a draft without sending. |
The session_id is the address. Never target a pane by number or by
guessing — pane numbers shift, session_id is stable. Get it from list_agents.
2. The protocol — read → message → read
Every interaction follows the same loop. Skipping a step is the #1 cause of garbled, unproductive multi-agent sessions.
- List.
list_agents→ find the target by role (itscommand) and grab itssession_id. Confirm it isn'tdead. - Read first.
read_pane(target)→ make sure it's idle/ready and you understand its current state. Don't talk over a busy agent. - Message once.
message_agent(target, text)with a clear, self- contained request. Include:- who you are (
[from Claude]), - exactly what you want done,
- the expected output and any constraints ("reply with a bullet list", "propose only, don't edit files", "reply DONE when finished").
- who you are (
- Wait, then read. Give the agent time to think and work. Re-
read_paneafter a pause to collect the reply. If it's still working, read again — do not send another message.
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 · 226 lines · 147 tokens per session scan C e5e0a96665c9
codegrid-agent-bus is a skill published in the GitHub repository ZipLyne-Agency/CodeGrid (23 stars, last pushed 20d ago), licensed MIT. It adds 147 tokens to every session and 2,569 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
claude-api
Build, debug, and optimize Claude API / Anthropic SDK apps. Apps built with this skill should include prompt caching. Also handles migrating existing Claude API code between Claude model versions (4.5 → 4.6, 4.6 → 4.7, retired-model replacements). TRIGGER when: code imports anthropic/@anthropic-ai/sdk; user asks for…
gui-onboarding-verification-skill
GUI desktop app only. Launch two parallel Oz cloud agents with computer use to download and install the latest stable Linux Warp build, capture screenshots while walking through first-time onboarding in both logged-out and logged-in states, then selectively fan out follow-up cloud agents for distinct onboarding…
create-skill
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
gui-integration-test
GUI desktop app only. Writes, runs, and debugs Warp integration tests using the custom Builder/TestStep framework in crates/integration. Use when adding a new integration test, fixing a failing integration test, wiring a test into the manual runner or nextest suite, or verifying end-to-end UI and terminal behavior in…
gui-settings-ui
GUI desktop app only. How to build a Settings page in the Warp client (app/src/settingsview) so its widgets and settings search behave correctly — picking a PageType, deciding whether a heading belongs in the page-title slot or inside a widget, gating a widget, and scoping searchterms per widget. Use when adding or…
logging-and-error-reporting
How and when to log (log:: levels, safe macros) and report errors to Sentry (reporterror!) in the Warp codebase. Use when adding or reviewing any logging or error reporting — picking a log level, deciding log vs. reporterror!, keeping sensitive data out of logs, or surfacing an error to Sentry.