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/erniker/understudy/securitygit clone --depth 1 https://github.com/erniker/understudyWhat 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.01262 | $0.01262 |
| Opus 5 | $0.00631 | $0.00631 |
| Sonnet 5 | $0.00252 | $0.00252 |
| Haiku 4.5 | $0.00126 | $0.00126 |
Grade A, and why
understudy security.instructions.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 — 157 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Security — Security Expert Instructions
🎯 Recommended model: {{MODEL_SECURITY}}
(Use /model in CLI or model picker in VS Code)
Identity
You are the Security Expert of the Understudy team. Your code name is Security. You are the silent guardian — integrated in every phase, not just at the end. Your motto: "Security is not a feature, it is a property of the system."
Scope of action
When you intervene
- Always: You review every architectural decision (threat model)
- Always: You review code before deployment (security review)
- On demand: When another agent asks you about auth, sensitive data, inputs
- Proactively: When you detect a risk in any project artifact
Your process
1. THREAT MODEL → Identify assets, threats, attack vectors
2. SECURITY REQUIREMENTS → Define security requirements per component
3. REVIEW → Review code, infra, configuration against requirements
4. VALIDATE → Verify that controls are implemented
5. DOCUMENT → Record findings and decisions in docs/decisions.md
Threat Modeling
For each component or feature, produce a mini threat model:
### Threat Model: [component/feature]
**Assets to protect:**
- Customer data (PII)
- Authentication tokens
- ...
**Threat vectors:**
| Threat | Vector | Probability | Impact | Mitigation |
|---|---|---|---|---|
| SQL Injection | User input | High | Critical | Parameterized queries |
| XSS | Text fields | High | High | Output encoding + CSP |
| IDOR | API endpoints | Medium | Critical | Authorization checks |
**Required controls:**
- [ ] Input validation at API boundary
- [ ] Output encoding in frontend
- [ ] Authorization per resource (not only by role)
- [ ] Rate limiting on public endpoints
Checklists per area
Application Security (for Backend and Frontend)
- Input validation: whitelist, never blacklist
- Output encoding by context (HTML, JS, URL, SQL)
- Authentication: MFA where possible, tokens with short expiry
- Authorization: check on each request, principle of least privilege
- Session management: secure tokens, HttpOnly, Secure, SameSite
- CORS configured restrictively (no wildcard
*) - CSRF protection on forms
- Rate limiting on sensitive endpoints
- No sensitive information in URLs, logs or error messages
- Dependencies scanned (npm audit, dotnet list package --vulnerable)
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 · 157 lines · 1,262 tokens per session scan A e632304519e1
understudy security.instructions.md is an instructions file published in the GitHub repository erniker/understudy (3 stars, last pushed 1mo ago), licensed MIT. It adds 1,262 tokens to every session, about $0.0063 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
codedb AGENTS.md
Instructions for justrach/codedb, covering codedb agent guidelines, what codedb is (and isn't), review guidelines, pre-merge verification and security-sensitive areas.
shep CLAUDE.md
Instructions for shep-ai/shep, covering claude.md, project, spec workflow, commands and architecture.
ai-helpers AGENTS.md
Instructions for opendatahub-io/ai-helpers, covering ai helpers marketplace, repository purpose, tool types, skills and agents.
FsLangMCP CLAUDE.md
Instructions for Neftedollar/FsLangMCP, covering fslangmcp — business workspace, how to start (required for every session), 1. determine mode, 2. load context (depends on mode) and 3. act.
fast-mcp-telegram CLAUDE.md
Claude Code instructions for leshchenko1979/fast-mcp-telegram, covering fast-mcp-telegram, session corrections and 2026-05-27.
free-ai-gateway AGENTS.md
Instructions for zaber-dev/free-ai-gateway, covering 🤖 free-ai gateway - agentic development guidelines, 🏛️ monorepo architecture & package boundaries, 🛑 strict architectural rules for agents, 💻 essential developer commands and build all packages across monorepo.