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/vironnimo/vbot/agents-mdgit clone --depth 1 https://github.com/Vironnimo/vbotWhat 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.03883 | $0.03883 |
| Opus 5 | $0.01942 | $0.01942 |
| Sonnet 5 | $0.00777 | $0.00777 |
| Haiku 4.5 | $0.00388 | $0.00388 |
Grade A, and why
vbot 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 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 — 146 lines — stays where its author put it; the contents beside it link to each section on GitHub.
AGENTS.md
Read at session start (if not already in your context/system prompt)
Read these two core files completely before doing anything (even saying 'hi'), every session, no exceptions — there is no auto-import here, so loading them is on you:
.vorch/PROJECT.md— project context.vorch/GLOSSARY.md— project-specific terms
They hold the project's rules and conventions — follow them. Read more as the task needs it: a domain's map under .vorch/domain-maps/ (index in PROJECT.md) when you work that domain, plus any adjacent map your change touches; .vorch/DESIGN.md for UI work. Domain maps are first-pass orientation: use them to find the responsible domain, relevant contracts, likely source, and tests. They do not prove the current implementation and never replace source code, which remains the source of truth for implemented behavior.
Talking to the User
The user reads no code. All user-facing communication — discovery, plan review, decisions, escalations, summaries — is in product language: behavior, capabilities, consequences, domains. No file paths, function names, or code identifiers unless they are part of the product interface (a CLI command, an API endpoint, a config option).
Lead with the outcome. Every reply opens with the result or the bottom line — what changed, what works, what's blocked — before the reasoning, the steps, or the context. The user should know the outcome from the first sentence and be able to stop reading there.
Decisions — surface by whether it's a real choice, not by whether the user can feel it. A change built to be imperceptible still has sub-decisions worth seeing; "the user won't feel it" is never a reason to bury one.
- Ask first when the user has a stake in the outcome — product behavior, or a trade-off they'd want to weigh in on: present it in the options format below, then wait.
- Decide, then disclose in one line when it's a real choice among defensible options the user would likely leave to good practice (a 0.5s vs 0.8s debounce, a threshold, a library): make the call and show it — what you chose, the alternative, and why, in one overridable line.
- Settle silently only when no alternative exists that the user could hold a view on — naming, code structure below domain level, where code lives.
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 · 146 lines · 3,883 tokens per session scan A 27da74466591
vbot AGENTS.md is an instructions file published in the GitHub repository Vironnimo/vbot (1 stars, last pushed 2d ago), licensed Apache-2.0. It adds 3,883 tokens to every session, about $0.0194 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
dograh AGENTS.md
Instructions for dograh-hq/dograh, covering dograh - project overview, project structure, tech stack, local development and environment configuration.
MemMachine AGENTS.md
Instructions for MemMachine/MemMachine, covering memmachine agent guide, repository orientation, environment setup, build, lint, and test commands and python (repo root).
dify AGENTS.md
AGENTS.md instructions for langgenius/dify, covering agents.md and repository gotchas.
bub AGENTS.md
Instructions for bubbuild/bub, covering repository guidelines, project structure & module organization, build, test, and development commands, coding style & naming conventions and testing guidelines.
dify CLAUDE.md
Claude Code instructions for langgenius/dify, a project described as: Build Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.
minion CLAUDE.md
Instructions for femto/minion, covering 🧠 记忆存储, 系统架构记忆 and 开发流程记忆.