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/agentprism/agentprism-workflows/agents-mdgit clone --depth 1 https://github.com/agentprism/agentprism-workflowsWhat 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.01481 | $0.01481 |
| Opus 5 | $0.00740 | $0.00740 |
| Sonnet 5 | $0.00296 | $0.00296 |
| Haiku 4.5 | $0.00148 | $0.00148 |
Grade A, and why
agentprism-workflows 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 — 83 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Repository Agent Instructions
These instructions apply across this repository. A nested AGENTS.md may add package-specific guidance, but it does not override the root monorepo, delivery, or release rules.
Start with the authoritative sources
Before changing code, read the relevant parts of:
CONTRIBUTING.md— development, tests, generated artifacts, dependency gates, attribution, PRs, and releases.README.md— product surface and package map.docs/design-notes.md— protocol and package architecture.docs/api.md— supported integration APIs.docs/authoring/— canonical workflow and REPL authoring documentation shipped through MCP.docs/specs/— implemented contracts and design records; apply the planning distinction below.
Prefer executable guards and current source over stale prose. When they disagree, investigate and update the authoritative documentation rather than coding around the discrepancy.
Design first; do not fossilize implemented contracts
Documents under docs/specs/ are authoritative descriptions of implemented contracts, not an untouchable architectural constitution.
- During design and planning, treat existing specs as current-state evidence and migration surface, not as constraints on the quality of the target design. Question whether the current architecture should be improved. Design the best coherent solution for the user's request.
- If that design conflicts with an implemented or “frozen” contract, make the conflict explicit. Explain what should be preserved, revised, superseded, or migrated, including compatibility, rollout, test, and documentation consequences. Do not silently contort a new design around an older contract, and do not silently break one.
- During implementation, after the design and scope are agreed, preserve contracts outside the approved change. Deliberate contract changes belong in the same implementation train as their migrations, tests, and documentation updates.
- When a task is explicitly scoped to implement or verify an already-approved frozen contract, that contract is the implementation authority for that scoped task. If following it would create a material architectural problem, stop and surface the issue instead of improvising a different 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.
- 2d ago First seen · 83 lines · 1,481 tokens per session scan A b24a11442983
agentprism-workflows AGENTS.md is an instructions file published in the GitHub repository agentprism/agentprism-workflows (3 stars, last pushed 3d ago), licensed Apache-2.0. It adds 1,481 tokens to every session, about $0.0074 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
intelligent-terminal agent-skills.instructions.md
Guidelines for creating high-quality Agent Skills for GitHub Copilot.
intelligent-terminal rust-localization.instructions.md
Instructions for microsoft/intelligent-terminal, covering localization instructions for rust wta (yaml locale files), file structure, file format, the en-us.yml source file and non-translatable token rules.
intelligent-terminal localization.instructions.md
Instructions for microsoft/intelligent-terminal, covering localization instructions for .resw resource files, components with localized resources, locale categories, authoritative locale list (from terminalapp) and adding or updating localized strings.
intelligent-terminal copilot-instructions.md
Copilot instructions for microsoft/intelligent-terminal, covering copilot instructions for windows terminal, build, running, test and code formatting.
intelligent-terminal instructions.instructions.md
Guidelines for creating high-quality custom instruction files for GitHub Copilot.
intelligent-terminal AGENTS.md
AGENTS.md instructions for microsoft/intelligent-terminal, covering intelligent terminal, architecture, supported agents and settings, user-facing behavior and key files.