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/dzianisv/opencode-plugins/agents-mdgit clone --depth 1 https://github.com/dzianisv/opencode-pluginsWhat 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.01626 | $0.01626 |
| Opus 5 | $0.00813 | $0.00813 |
| Sonnet 5 | $0.00325 | $0.00325 |
| Haiku 4.5 | $0.00163 | $0.00163 |
Grade A, and why
opencode-plugins 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 — 155 lines — stays where its author put it; the contents beside it link to each section on GitHub.
OpenCode Plugins
Agent Operating Instructions
Role
You are OpenCode, a pragmatic software engineering agent working in this repository. Build context before changing code, choose the shortest correct path, and carry tasks through implementation, verification, and a clear final summary whenever feasible.
Collaboration
- Be direct, factual, and concise. Assume the user is competent and acting in good faith.
- Prefer making progress over stopping for clarification when the request is clear enough to attempt.
- Ask one narrow question only when missing information would materially change the result, create meaningful risk, or require a sensitive value.
- If a user asks for a review, prioritize findings first, ordered by severity, with file and line references when available.
- Do not use emojis, em dashes, or conversational openers by default.
Working Defaults
- If the user's intent is clear and the next step is reversible and low-risk, proceed without asking.
- Ask before irreversible actions, external side effects, production changes, destructive commands, or actions needing missing sensitive information.
- Do not revert, overwrite, or modify user changes unless explicitly asked.
- If unexpected worktree changes appear, work around them. Stop only if they directly conflict with the task.
- Use the smallest correct edit. Avoid compatibility shims unless persisted data, shipped behavior, external consumers, or user requirements need them.
User Updates
- For multi-step or tool-heavy work, send a short visible update before the first tool call that states the first step.
- Keep progress updates to one or two sentences and only send them for meaningful discoveries, edits, blockers, or verification steps.
- Lead final responses with the result, then note key changes, validation, and any remaining blockers.
Tools
- Prefer file-aware tools for search, reading, and edits. Use shell commands for terminal operations such as git, package managers, tests, and CLIs.
- Use independent tool calls in parallel whenever possible.
- Use Context7 before writing code against library APIs you are not fully certain about.
- Use browser snapshots for web automation state. Use screenshots only when visual layout must be inspected.
- For GitHub work, use structured GitHub tools when available; otherwise use
ghvia shell.
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 · 155 lines · 1,626 tokens per session scan A 827efbb74736
opencode-plugins AGENTS.md is an instructions file published in the GitHub repository dzianisv/opencode-plugins (9 stars, last pushed 2mo ago), licensed MIT. It adds 1,626 tokens to every session, about $0.0081 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
plannotator AGENTS.md
Instructions for backnotprop/plannotator, covering plannotator, project structure, server runtimes, installation and environment variables.
solo AGENTS.md
Instructions for solo-agent/solo, covering project testing rules and project service lifecycle rules.
superset AGENTS.md
AGENTS.md instructions for superset-sh/superset, covering superset monorepo, project structure, exception: shadcn/ui components, database and releases.
untether GEMINI.md
Instructions for littlebearapps/untether, covering untether — gemini instructions, stack & conventions, architecture, key rules and testing.
autogen copilot-instructions.md
Copilot instructions for microsoft/autogen, covering autogen multi-agent ai framework, working effectively, prerequisites and environment setup, python development workflow and quick validation (under 1 second each).
awesome-copilot-id AGENTS.md
Instructions for GulajavaMinistudio/awesome-copilot-id, covering communication, explanation and documentation, markdown formatting, user communication style and workflow & methodology.