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/eigent-ai/eigent/agents-mdgit clone --depth 1 https://github.com/eigent-ai/eigentWhat 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.00608 | $0.00608 |
| Opus 5 | $0.00304 | $0.00304 |
| Sonnet 5 | $0.00122 | $0.00122 |
| Haiku 4.5 | $0.00061 | $0.00061 |
Grade A, and why
eigent 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 — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Eigent Agent Instructions
UI work
Before planning, generating, reviewing, or modifying any user-facing UI, read
docs/design-system/design.md completely. Treat it as the active product design
contract for all UI work in this repository.
Use docs/design-system/index.html as the visual reference. The Markdown
guideline remains authoritative when the two formats differ.
For UI implementation:
- Inspect the nearest existing product surface for behavior and layout context.
- Reuse primitives from
src/components/uibefore creating a new component. - Use the semantic tokens and supported component axes documented in the guideline.
- Treat
src/style/tokens,src/style/generated, and shared UI primitives as the executable source of truth. Never edit generated token files by hand. - Do not introduce raw colors, arbitrary standard-control geometry, stock shadows, new compatibility aliases, or local icon sizing when an approved semantic role or recipe exists.
- When the design guideline and implementation disagree, inspect both and report the discrepancy instead of silently inventing a new rule.
Before handing off UI work, report the reused primitives, selected semantic tokens or component axes, verified states and themes, any registered exception, and the validation commands that passed or were not run.
Product terminology
Before planning, generating, reviewing, or modifying user-facing terminology,
presentation component names, or presentation-oriented file and folder names,
read docs/product-terminology.md completely. Treat it as the authoritative
match between UI wording and the backend terms and identifiers that must remain
unchanged.
For terminology work:
- Use the document's UI wording for visible copy, accessibility labels, and presentation-oriented names.
- Preserve the matched backend/API/database terms, identifier values, routes, commands, event fields, translation keys, and persisted keys. Do not create new serialized aliases for a UI rename.
- Classify presentation files and components by the surface they own: Space, Session, or shared. A Space-owned container may contain Session-named child components.
- Inspect each occurrence at its presentation or compatibility boundary. Do not use an unrestricted search-and-replace across Product terms.
- When terminology documentation and implementation disagree, inspect both and report the discrepancy instead of silently changing a frozen contract.
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 · 67 lines · 608 tokens per session scan A 3d28142d6774
eigent AGENTS.md is an instructions file published in the GitHub repository eigent-ai/eigent (15,159 stars, last pushed 3d ago), licensed Apache-2.0. It adds 608 tokens to every session, about $0.0030 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
LeAgent AGENTS.md
Instructions for vixues/LeAgent, covering leagent development guidelines, project overview, architecture, execution topology (one kernel, many ingresses) and surface map (where things live).
rn-dev-agent AGENTS.md
Instructions for Lykhoyda/rn-dev-agent, covering repository guide for agents, repository map, editing rules, architecture rules and supported node runtimes.
caddis-plugin streamlit.instructions.md
Streamlit development standards for dashboards and applications.
caddis-plugin testing.instructions.md
Testing guidelines for applications using pytest.
caddis-plugin fastapi.instructions.md
FastAPI development standards for backend services.
caddis-plugin frontend.instructions.md
Frontend development standards for HTML, CSS, and styling.