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/day1labs/openava/agents-mdgit clone --depth 1 https://github.com/Day1Labs/OpenAvaWhat 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.00550 | $0.00550 |
| Opus 5 | $0.00275 | $0.00275 |
| Sonnet 5 | $0.00110 | $0.00110 |
| Haiku 4.5 | $0.00055 | $0.00055 |
Grade A, and why
OpenAva AGENTS.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 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 — 35 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent Operating Rules
Goal: complete the user's current requirement with the lowest necessary complexity, and make the result easy to verify and explain.
Highest Priority (Hard Rules)
- State the requirement before acting: summarize the user-visible behavior change in 1 sentence. If uncertain, ask only the minimum necessary clarification.
- Read before changing: inspect the relevant files/types before editing, and make the smallest change that fits the existing structure.
- Prefer existing flows: if the requirement can be solved inside existing types/functions/flows, do not add a manager / wrapper / service / helper.
- Do not design for the future: do not solve hypothetical future needs; do not add extension points unless the current task clearly requires them.
- Simplify after it works: after the first working version, do one simplification pass to remove dead code, redundant branches, one-off parameters, and misleading names.
- Verification is required: validate the change using the most direct available method (tests / compile / direct path validation). “It should work” is not enough.
Triggered Rules (When / Then)
- When adding a new entity: first prove that modifying the existing code cannot express the requirement cleanly. Then explain why the new entity is necessary, what it owns, and why editing the existing code was not enough.
- When two solutions both work: choose the one with fewer new concepts, fewer lines of code, and fewer indirection layers.
- When a change touches multiple modules: keep data flow explicit, with clear ownership of parameters, return values, and state. Avoid hidden global state or opaque cross-layer flow.
- When fixing a bug: state the reproduction condition or visible failure first, then make the smallest fix, then add a regression validation point.
Anti-Patterns
- Adding a new abstraction only to avoid editing the existing code
- Adding a helper/wrapper used only once, unless it clearly improves readability and removes duplication
- Keeping dead branches or compatibility code “just in case”
- Skipping verification after changes
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 · 35 lines · 550 tokens per session scan A 7f4bf40500ad
OpenAva AGENTS.md is an instructions file published in the GitHub repository Day1Labs/OpenAva (10 stars, last pushed 1mo ago), licensed MIT. It adds 550 tokens to every session, about $0.0028 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 instructions, from other repositories
solo AGENTS.md
Instructions for solo-agent/solo, covering project testing rules and project service lifecycle rules.
research-os AGENTS.md
Instructions for lxinfei5/research-os, covering researchos — constitution, §0 what this is, §1 directory discipline, §2 half-life (innovation 1) — memory design and §3 behavior pillars (innovations 2–5).
Polaris AGENTS.md
Instructions for sponge-b0b/Polaris, covering agents.md, purpose and authority, domain vocabulary, coding conduct and secrets.
agent-skills AGENTS.md
Instructions for simota/agent-skills, covering agents.md — claude-skills, repository purpose, language policy, repository structure and skill authoring conventions.
prism-insight CLAUDE.md
Claude Code instructions for dragon1086/prism-insight, covering claude.md - ai assistant guide for prism-insight, quick overview, project structure, analysis pipeline and ai agents.
AI-System-Design-Consultant CLAUDE.md
Instructions for deepanshu2711/AI-System-Design-Consultant, covering claude.md, what this is, running it, load-bearing typos — do not "fix" these paths and agent node pattern.