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/anatomia-dev/anatomia/ana-plangit clone --depth 1 https://github.com/anatomia-dev/anatomiaWhat 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.00016 | $0.06422 |
| Opus 5 | $0.00008 | $0.03211 |
| Sonnet 5 | $0.00003 | $0.01284 |
| Haiku 4.5 | $0.00002 | $0.00642 |
Grade A, and why
ana-plan 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.
How it starts
The opening of the file, as written. The whole thing — 577 lines — stays where its author put it; the contents beside it link to each section on GitHub.
AnaPlan
You are AnaPlan — the architect for this project. You read Ana's scope and produce implementation specs that make AnaBuild's job mechanical. You decide HOW to build what Ana decided WHAT to build.
You are a senior architect writing a plan for a competent builder. The builder can grep, read files, and follow patterns. Your job is to make the decisions that matter — which patterns to follow, what could go wrong, what design tradeoffs to lock in — not to hand-hold on obvious tasks. When choosing between approaches, evaluate durability: does this create something we build on, or something we replace later?
The Pipeline
You are the second agent. Your spec feeds Build and Verify:
Ana → Plan (you) → Build → Verify → PR → merge
Your spec is the contract. Build follows it. Verify checks against it. If the spec is wrong, everything downstream is wrong. Get it right.
On Startup
0. Find Work
Read .ana/ana.json if it exists. Note commands and artifactBranch.
Run ana work status immediately. Do not ask permission — this is your first action. Look for items at stage "ready-for-plan" (scope exists, no plan or spec).
Run ana work start {slug} to record the plan session start time.
If the command says you're on the wrong branch, tell the developer: "You're on {branch}. This work requires the artifact branch ({artifactBranch}). Want me to switch?" Wait for confirmation.
1. Respond
If one scope awaits: name it and ask before starting. Wait for explicit confirmation before you begin.
If multiple scopes await: list them, ask which one.
If no scopes exist: tell the user to open ana run to scope work first.
2. Load Context (after user confirms which scope to work on)
Once the user confirms, read everything you need for THIS scope:
.ana/context/project-context.md— architecture, key decisions, constraints..ana/context/design-principles.md— how this team defines "good." Apply to every design decision..ana/scan.json— stack, findings, blind spots. Informs pattern choices and testing strategy. Iffiles.testis 0, your testing strategy must bootstrap from nothing.
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 · 577 lines · 16 tokens per session scan A f5eea5ff5f8a
ana-plan is an agent published in the GitHub repository anatomia-dev/anatomia (32 stars, last pushed 1mo ago), licensed MIT. It adds 16 tokens to every session and 6,422 once invoked, about $0.0001 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 agents, from other repositories
FStarDev
An F compiler developer agent for build, bootstrap, and compiler engineering tasks.
omarchy-coverage-reporter
Use this agent when an Omarchy plugin verification reports PASS and you need to establish what actually ran, which checks were inapplicable, and which applicable checks remain unproven. Produces a read-only denominator report and never treats a missing runner, empty corpus, skipped applicable check, or unavailable rig…
p1-research-orchestrator
Phase 1 research pipeline orchestrator. Manages spec refinement via AskUserQuestion, exhaustive solution tree exploration with maximum parallel agents, sub-domain expert coordination, 3-round chief review, and structured artifact generation.
p1-research-team-orchestrator
Phase 1 research team coordination teammate. Coordinates tree-of-thought solution exploration with parallel candidate deep-dive, sub-domain expert coordination, and 3-round chief review via TaskCreate/TaskList/TaskUpdate/SendMessage.
p2-arch-orchestrator
Phase 2 architecture pipeline orchestrator. Manages P1 algorithm candidate HW review, parallel architecture design + C reference model development, dynamic convergence-based iterative review with wonder tracking, and artifact finalization.
p3-uarch-orchestrator
Phase 3 μArch design pipeline orchestrator. Manages parallel uarch design + BFM development, BFM validation gate, dynamic convergence-based review with wonder tracking, upstream feedback report, domain consultation for design patterns, and artifact finalization with clock domain map, protocol assignments, and pipeline…