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 agents/tigergtc/opus-rail/plannergit clone --depth 1 https://github.com/TigerGTC/opus-railWhat 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.00105 | $0.00732 |
| Opus 5 | $0.00053 | $0.00366 |
| Sonnet 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 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.
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.
- 2d 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 1mo ago), licensed MIT. It adds 105 tokens to every session and 732 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
polymath
Cross-disciplinary synthesis; spawns domain-specific subagents, synthesizes findings across domains, and produces integrated insights.
hatch3r-creator
Authors user-tier custom artifacts (agents, skills, rules, commands, hooks) under .hatch3r/overrides/. Validates frontmatter schema, runs strict + gentle quality gates, and writes the artifact only when all strict gates pass.
devops
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
aiox-master
Agent "aiox-master" from SynkraAI/aiox-core, covering aiox-master, all commands require prefix when used (e.g., help), ids pre-action hooks (story ids-7), quick commands and agent collaboration.
architect
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
data-engineer
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.