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 instructions/anombyte93/prd-taskmaster/claude-mdgit clone --depth 1 https://github.com/anombyte93/prd-taskmasterWhat 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.02637 | $0.02637 |
| Opus 5 | $0.01319 | $0.01319 |
| Sonnet 5 | $0.00527 | $0.00527 |
| Haiku 4.5 | $0.00264 | $0.00264 |
Grade A, and why
prd-taskmaster CLAUDE.md 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 yesterday.
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 — 158 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Claude Code Instructions — Atlas
The end goal (north star — test every change against this)
Atlas's entry point is a frontier model (Fable, or whatever the best frontier model is) acting as the driver. The driver understands the user's intent using skills built for it, then — inside a loop — decomposes the goal into optimal components and routes each to the cheapest capable executor, to save as many tokens as possible while delivering an outcome as good as if the frontier model had done all the work itself, at a fraction of the cost.
The executor pool is any CLI agent harness (Claude Code, Codex, Gemini, whatever ships next) plus direct API paths (the native backend's parse/expand/rate), all in parallel. Not a fixed provider list. Every feature decision is tested against: does this make the frontier-driver-decomposes-to-cheap-executors loop better, cheaper, or more provable?
What makes Atlas a product, not a prompt pack (the four moats):
- Cross-vendor arbitrage — route work across any harness/API by cost and capability.
- Engine-enforced unfakable gates — validate-tasks, ship-check (
SHIP_CHECK_OK), the two-axis "done" (oracle + reachability, below), structural tests. If a feature could be a skill, it's not a product feature until the engine enforces it. - Persistent vendor-neutral task graph — tasks.json survives across vendors/sessions.
- Cross-vendor cost ledger — telemetry + economy-report prove the savings.
Unfakable "done" — the two gates (5.3.0+, the trust backbone)
A task ships only when both axes pass — done = oracle-PASS AND code WIRED/EXEMPT.
This is the property the whole product (and the marketplace below) rests on; do not weaken it.
- Gate 5 — re-execution oracle. The binding ship gate is
skel/ship-check.py(oracle-backed). It re-runs the operator-held tests at the claimed commit in a network-isolated, digest-pinned podman sandbox, so a submitter cannot pass by editing their own logs.prd_taskmaster/oracle_bridge.pymaps a CDD card → graded verdict via the spine'satlas oracleCLI; it is fail-closed (any ambiguity → FAIL, never PASS). The self-grantableSHIP_CHECK_OVERRIDE_ADMINbypass was removed. (prd_taskmaster/shipcheck.pyis a NON-binding display heuristic only — never add an oracle call there.) - Gate 6 — reachability (
prd_taskmaster/reachability.py,reachability-sweepCLI). A green test on an orphan module (imported by nothing) is blocked and surfaced as⚠ scaffolded. Verdicts: WIRED (a non-test file imports it) / EXEMPT (declaredcli:|route:|tool:|hook:|plugin:|dynamic:scheme, accepted on trust in v1) / ORPHAN (fail). Read-only at runtime.
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.
- yesterday First seen · 158 lines · 2,637 tokens per session scan A 212d7192deb1
prd-taskmaster CLAUDE.md is an instructions file published in the GitHub repository anombyte93/prd-taskmaster (592 stars, last pushed 18d ago), licensed MIT. It adds 2,637 tokens to every session, about $0.0132 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 instructions, from other repositories
productskills CLAUDE.md
Instructions for assimovt/productskills, covering productskills, what this repo is, architecture, skill design rules and skill.md format.
ai-prd-generator CLAUDE.md
Claude Code instructions for cdeust/ai-prd-generator, covering ai prd generator plugin, cowork mode — important, slash commands, license flow and license key activation (only when user provides a new key).
aider-desk AGENTS.md
Instructions for hotovo/aider-desk, covering agents.md, common commands, development, type checking and linting and formatting.
core copilot-instructions.md
Instructions for asdecided/core: These decisions are already accepted. Do not re-open or contradict them; ask the AsDecided MCP tools (getartifact, searchartifacts) for the full text before proposing a change that touches one.
FrameCode-VibeWork AGENTS.md
Instructions for Sistema2D/FrameCode-VibeWork, covering agents.md, instruction order, reading-trigger rule, regression rule and when a plan is required.
sugar AGENTS.md
AGENTS.md instructions for roboticforce/sugar, covering sugar - agents.md, git branching rules (strict), always create branches from develop, after work is complete and then create pr targeting develop.