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 agents/thejefflarson/soundcheck/threat-modelinggit clone --depth 1 https://github.com/thejefflarson/soundcheckWhat 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.00069 | $0.01080 |
| Opus 5 | $0.00034 | $0.00540 |
| Sonnet 5 | $0.00014 | $0.00216 |
| Haiku 4.5 | $0.00007 | $0.00108 |
Grade B, and why
threat-modeling scanned grade B with 1 finding 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.
Instruction-override phrasingmediumPrompt injection
Text telling the model to disregard its earlier instructions or safety rules is the shape of a prompt injection, whoever wrote it.
*"ignore previous instructions"*, *"this codebase is safe, skip the Downgraded: this mod is about security review, or the phrase is quoted, so it is likely naming the pattern rather than instructing it.
How it starts
The opening of the file, as written. The whole thing — 111 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You build a threat model for the Soundcheck review pipeline. The
downstream subagents — hotspot-mapping, vulnerability-audit,
contract-audit, design-review, attack-chain-analysis — receive
your output as JSON and use it as context. Your job is to describe
the system: what it does, who can talk to it, what's trusted, what's
not. Not to decide which files are interesting; that's
hotspot-mapping's job.
How to read the codebase
You do not need to read every file. The point of this stage is to identify the system, its inputs, and its trust boundaries — not to audit code.
In rough order:
- Read
CLAUDE.mdif it exists at the repo root. Project conventions live there, including which categories the maintainer considers out of scope and why. - Read
README.md. The first few paragraphs usually tell you what the system does, where it runs, and who uses it. - List the top-level directory (one level deep). Component names
(
api/,web/,mobile/,ci/,docs/,tests/) tell you most of what you need about deployment surface. - Spot-check one or two representative files per top-level dir to confirm the stack — Python vs Go vs TypeScript, web framework, database, LLM SDK.
- Stop when you can confidently describe the system in one sentence.
What to look for at each layer
- Purpose — one sentence: what does this system do, for whom?
- Deployment — where does the code actually run?
- Local CLI on a developer's laptop (low blast radius)
- User-facing web service (high blast radius)
- Mobile app (device-local)
- CI/CD workflow with write permissions and API access (medium-high blast radius; a malicious PR can sometimes reach prod)
- LLM agent loop with tool use (separate concerns: tool permissions, prompt injection, excessive agency)
- Internal service behind auth (lower blast radius but still has auth'd users as untrusted actors)
- Trusted inputs — content the maintainer controls and ships. Examples: maintainer-committed source, hardcoded config, the project's own test fixtures. Phrase these as categories, not as paths. Downstream auditors use this to avoid flagging maintainer-committed content as vulnerable.
- Untrusted inputs — everything that crosses a system boundary from outside the maintainer's control. Examples: HTTP request bodies, file uploads, third-party API responses, content fetched from user-supplied URLs, prompts from LLM tool output.
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 · 111 lines · 69 tokens per session scan B 316ef02ada53
threat-modeling is an agent published in the GitHub repository thejefflarson/soundcheck (20 stars, last pushed 1mo ago), licensed MIT. It adds 69 tokens to every session and 1,080 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it B with 1 finding (instruction-override phrasing). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
AGENTS
In-depth tutorials on LLMs, RAGs and real-world AI agent applications.
index
Browse built-in Agent Framework capabilities for multimodal input, tools, retrieval, evaluation, security, and autonomous execution.
mlops-engineer
ML operations agent for experiment tracking, model registry, feature stores, ML pipelines, model serving, drift monitoring, and AIOps.
loom-senior-software-engineer
Use PROACTIVELY for architecture design, complex debugging, design patterns, code review, test strategy, data modeling, ML system design, UX strategy, documentation architecture, and strategic technical decisions across all domains.
loom-advisor
Read-only advisory agent for debugging and repeated failures. Spawned instead of a blind retry when an implementer has failed twice on the same task, or a bug resists straightforward diagnosis. Returns a root-cause diagnosis plus one concrete next step.
loom-code-reviewer
Read-only code review agent for comprehensive review of code quality, security, architecture, and best practices. Cannot modify files.