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/avifenesh/tools/agents-mdgit clone --depth 1 https://github.com/avifenesh/toolsWhat 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.01661 | $0.01661 |
| Opus 5 | $0.00830 | $0.00830 |
| Sonnet 5 | $0.00332 | $0.00332 |
| Haiku 4.5 | $0.00166 | $0.00166 |
Grade A, and why
tools 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- tools CLAUDE.md — 95% identical, 10 lines differ
How it starts
The opening of the file, as written. The whole thing — 120 lines — stays where its author put it; the contents beside it link to each section on GitHub.
AGENTS.md — @agent-sh/harness-* monorepo
Guidance for Codex working on this repo. The repo builds LLM-facing agent tools (Read, Write, Grep, Glob, ...) as a TypeScript-first npm library, with Rust ports coming later. The tools are consumed by real language models inside agent harnesses — not by deterministic callers.
The prime directive: treat LLM tools as a chaotic distributed system, not as kernel code
The user is a systems software engineer (Valkey, CRIU, ElastiCache). These tools look like regular functions — typed inputs, typed outputs, clean error enums — but that framing is a trap. The consumer is a probabilistic model, so the contract is not "given these args, produce this output." The contract is:
Given only the tool's textual surface (name, description, schema field names, error messages, output shape, pagination hints), does a real model, across many families (Qwen, Llama, GPT, Codex, DeepSeek), pick this tool, call it correctly, interpret the result, and make good next moves — without giving up and falling back to Bash?
That is the spec. Everything else is implementation detail.
Why this matters — the failure modes that unit tests never catch
- Description-driven misuse. An ambiguous parameter name (
pathvsfile_path,limitvsmax_lines) causes the model to pass the wrong thing. The code is fine. The tool is broken. - Unrecoverable errors.
ENOENTwith no context leaves the model stuck. A NOT_FOUND that lists sibling candidates lets it self-correct. - Ignored hints. The output says
next_offset: 2000but the model re-reads from 0 and loops. The pagination design is the failure. - Silent non-invocation. The model reads the description, decides the
tool doesn't fit, and shells out to
cat/grep/lsvia Bash instead. You will not see this in any unit test. You will only see it when you log real sessions and notice your tool is never called. - Hallucinated output. The tool returns JSON the model misparses, so the model confidently reports content that was never in the file.
- Tool-as-friction. A well-intentioned safety rail (sensitive-path deny, forced pagination, mandatory ledger confirmation) makes the tool annoying enough that the model routes around it. The user has shipped many tools and watched exactly this happen — "too many to count."
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 · 120 lines · 1,661 tokens per session scan A 63c9c8ab2e52
tools AGENTS.md is an instructions file published in the GitHub repository avifenesh/tools (5 stars, last pushed 3d ago), licensed MIT. It adds 1,661 tokens to every session, about $0.0083 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
rust-bash AGENTS.md
Instructions for shantanugoel/rust-bash, covering agents.md, canonical spec, steps to do for any task and agent execution rules.
langgraph AGENTS.md
AGENTS.md instructions for langchain-ai/langgraph, covering agents instructions, corridor security analysis, libraries and dependency map.
agentgateway copilot-instructions.md
Copilot instructions for agentgateway/agentgateway: Do not check for, speculate about, or report compilation errors during code review. Compilation diagnostics from review are frequently incorrect; rely on CI to detect and report compilation failures.
hatch3r CLAUDE.md
Instructions for hatch3r/hatch3r, covering hatch3r — development instructions, architecture, development commands, two-axis pillar framework (2.0.0) and orchestrator self-discipline (bypass protection).
aeon CLAUDE.md
Instructions for aeonfun/aeon, covering aeon, how aeon works, strategy, voice and soul file hierarchy (read in this order).
ken CLAUDE.md
Instructions for townsendmerino/ken, covering claude.md, what this is, repository ownership (read this first), commands and embedding parity & golden fixtures (now in aikit).