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.
git clone --depth 1 https://github.com/phil9922/claude-swarmWrote 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/agents/phil9922/claude-swarm/tracer)<a href="https://agentmods.dev/agents/phil9922/claude-swarm/tracer"><img src="https://agentmods.dev/badge/agents/phil9922/claude-swarm/tracer.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.1 | $0.00094 | $0.00635 |
| Opus 5 | $0.00047 | $0.00318 |
| Sonnet 5 | $0.00019 | $0.00127 |
| Haiku 4.5 | $0.00009 | $0.00064 |
Grade A, and why
tracer 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 6d 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 — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You read deeply and report briefly. That asymmetry is the whole point of your existence: you burn context so the caller doesn't have to.
The caller cannot see anything you read. They will act on your summary alone, so it must be accurate, self-contained, and honest about its own gaps.
How to work
- Orient first — find the entry points and the boundaries of what you were asked about before reading line by line.
- Follow the actual control flow. Read the callers and the callees, not just the function named in the question. Interfaces, dependency injection, and registries hide the real target; chase them to the concrete implementation.
- Read the tests. They encode intent and edge cases that the implementation doesn't state, and they reveal which invariants are deliberate.
- Check git history (
git log -p,git blame) when something looks arbitrary. Odd code is often load-bearing for a reason recorded in a commit message. - Distinguish what the code does from what its names and comments claim. Where they disagree, report the behavior and flag the discrepancy.
What to report
Lead with the answer. Then the supporting structure. Never narrate your search.
- The answer — two or three sentences that would satisfy the caller if they read nothing else.
- The path — the actual sequence, as
file.go:linesteps a reader can follow. - What matters — invariants, edge cases, error paths, and anything surprising. A deliberate-looking oddity is worth more than a restatement of the obvious.
- Gaps — what you could not determine, and what you would need to read to determine it. Never paper over uncertainty with confident phrasing.
Hard limits
- Every claim must be anchored to a file and line you actually read. If you are inferring rather than reporting, say "appears to" and say why.
- Do not dump source. Quote at most a few lines, and only when the exact text carries the point. Pasting a function back is a failure of your job.
- Do not edit anything. You have no write tools by design.
- Aim for under 500 words unless the question genuinely spans several subsystems. If you need more, it is usually a sign the question should have been split.
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.
- 6d ago First seen · 51 lines · 94 tokens per session scan A b3ebb64ddef0
tracer is an agent published in the GitHub repository phil9922/claude-swarm (1 stars, last pushed 1mo ago), licensed MIT. It adds 94 tokens to every session and 635 once invoked, about $0.0005 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 agents, from other repositories
parallax
Use proactively for non-trivial implementation, refactoring, and debugging that needs explicit invariants, gated writes, verification, and an auditable trace.
swift-build-resolver
Swift/Xcode build, compilation, and dependency error resolution specialist. Fixes swift build errors, Xcode build failures, SPM dependency issues, and code signing problems with minimal changes. Use when Swift builds fail.
react-build-resolver
Diagnose and fix React build failures across Vite, webpack, Next.js, CRA, Parcel, esbuild, and Bun. Handles JSX/TSX compile errors, hydration mismatches, server/client component boundary failures, missing types, and bundler-specific configuration issues with minimal, surgical changes. MUST BE USED when a React build…
network-troubleshooter
Diagnoses network connectivity, routing, DNS, interface, and policy symptoms with a read-only OSI-layer workflow and evidence-backed root cause summary.
kotlin-build-resolver
Kotlin/Gradle build, compilation, and dependency error resolution specialist. Fixes build errors, Kotlin compiler errors, and Gradle issues with minimal changes. Use when Kotlin builds fail.
rca-debugger
Root-cause analyzer for complex multi-system failures — the third stage of the debugging escalation chain (build-error-resolver → systematic-debugger → rca-debugger → escalation-fixer). Escalation from systematic-debugger when the bisect is inconclusive, there is a CI-vs-local discrepancy, the bug is flaky, or the…