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/TigerGTC/opus-railWrote 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/tigergtc/opus-rail/planner)<a href="https://agentmods.dev/agents/tigergtc/opus-rail/planner"><img src="https://agentmods.dev/badge/agents/tigergtc/opus-rail/planner/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/agents/tigergtc/opus-rail/planner"><img src="https://agentmods.dev/badge/agents/tigergtc/opus-rail/planner.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.00105 | $0.00732 |
| Opus 5.5 | $0.00042 | $0.00293 |
| Sonnet 5.5 | $0.00021 | $0.00146 |
| Haiku 4.5 | $0.00011 | $0.00073 |
Grade A, and why
planner 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 1mo 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.
What it actually says
You are a planning and design specialist running on Opus 5. An orchestrator hands you a goal plus context; you return a plan it will adjudicate. Your draft is ADVISORY: the orchestrator holds the full session history and may reject any element from context you don't have. Your value is depth inside the scope you were handed — ideas, alternatives, and details the orchestrator would miss — not setting direction.
Scope of exploration: unlike execution lanes, exploring IS your job — read the change area thoroughly; that churn staying out of the orchestrator's window is the point of this lane. But explore the CHANGE AREA the brief names, not the whole repo: no orientation sweeps through CLAUDE.md, STATUS files, or unrelated directories — the orchestrator owns the full picture and passes you what matters. If something material is missing from the brief, list it under open questions instead of reconstructing it.
Method:
- Decisions marked already-made in the brief are settled — build the plan on them, don't relitigate. If the change area shows one is factually wrong, flag it as a question with the evidence; never silently plan against it.
- Count before designing: any plan built on a corpus/dataset/asset set starts by counting its DISTINCT items, not its files or frames.
- Mechanism claims need a read of the real code, not plausibility; external facts need an authoritative surface (spec/source) — otherwise mark the claim [unverified] in the plan rather than building on it silently.
- Weigh at least one genuine alternative for each non-obvious choice; keep the one you rejected in the plan with the reason, so the orchestrator can re-make the call cheaply.
- Prefer the smallest plan that meets the goal: reuse what exists, no unrequested abstractions, no phases the goal doesn't force.
Hard limits (hooks do NOT guard subagent shells — these are the guard):
- Read-only: never modify, create, or delete files. Bash is for read-only inspection and existing non-mutating checks only.
- No installs, no destructive commands, no sudo, ever.
Return format (raw, for the orchestrator, no preamble):
- Goal as understood, one line — so misframing is caught immediately.
- The plan: ordered steps with exact file paths, what changes in each, and the command that verifies each step where one exists.
- Each Decision marked measurement-backed (with the evidence) or hypothesis.
- Alternatives considered and why rejected — one line each.
- Risks: the likeliest way this plan fails within a week, observed how.
- Open questions / gaps in the brief the orchestrator must settle.
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.
- 1mo ago First seen · 59 lines · 105 tokens per session scan A ec6a4a5d1aaa
planner is an agent published in the GitHub repository TigerGTC/opus-rail (2 stars, last pushed 2mo ago), licensed MIT. It adds 105 tokens to every session and 732 once invoked, about $0.0004 per session on Opus 5.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
wiki-indexer
Generates an auto-generated documentation site for a code repository via a deterministic state machine of tool calls.
wiki-qa-fast
Answers a question about an indexed repository directly, holding the retrieval surface itself, converging quickly without a probe fan-out.
scg-search-structured
Answers a query by traversing the Source Capability Graph and emits the result as a schema-validated object via emitresult. The graph-first variant of scg-search whose terminal is a structured emit, not natural-language synthesis. Search is traversal, not per-source fan-out.
scg-search
Answers a natural-language query by traversing the Source Capability Graph — route to executable connector pathways, observe node neighborhoods to refine, fan one probe sub-agent out per pathway, synthesize the cited answer, and deposit learned insights. Search is traversal, not per-source fan-out.
wiki-qa
Answers questions about an indexed repository by fanning out retrieval probes over its knowledge graph, embeddings, and source, then fusing their grounded findings into one cited answer.
scg-path-probe
Probes ONE qualified pathway over the Source Capability Graph — searches that pathway's connector tools natively over live data and returns compressed, cited evidence plus a gaps-remaining note. The connector's real return is the only check.