agentleFS
thejefflarsonthejefflarson/soundcheck/.claude/skills/threat-model/SKILL.md

threat-model

Skill20 starsChanged 4 months agoMITView on GitHub

Produces a threat model — purpose, deployment, trusted inputs, untrusted inputs — for a new feature or component before it's implemented. Use when writing an implementation plan for a new API endpoint, data pipeline, agent loop, or system component. Also invoke when a plan introduces new trust boundaries, handles user-supplied data, adds authentication flows, or integrates external services.

57 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use vuln-scan, supply-chain-review and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • AnthropicSkill

    vuln-scan

    Static source-code vulnerability scan. Reads a target directory (and THREAT_MODEL.md if present), spawns parallel review subagents per focus area, and writes VULN-FINDINGS.json + .md for /triage to consume. Read-only — no building, running, or network. For execution-verified crashes, use vuln-pipeline instead. Use when asked to "scan for vulns", "review this code for security issues", "find bugs in <dir>", or as the step between /threat-model and /triage.

    Also in 5 projects that use this

  • MesteriisSkill

    supply-chain-review

    Reviews lockfiles, installers, provenance, CI permissions, dependency confusion, artifacts, registries, and publishing.

    Also in 3 projects that use this

  • AnthropicSkill

    patch

    Generate candidate fixes for verified security findings. Consumes

    Also in 4 projects that use this

  • mbwsimsSkill

    orbit

    Run for repo-wide or diff-wide readiness sweeps: "/orbit", "/orbit pr", "/orbit deep", "/orbit quick", "audit this project", "project-wide review", "is this PR ready overall", or "combined security, tests, codebase, evolution, and instruction review". Use this for broad multi-system assessment, not for a single-file review or a one-domain question.

    Also in 3 projects that use this

  • mbwsimsSkill

    test-plan

    This skill should be used when the user asks to "plan tests", "what should I test", "what tests do I need", "test plan for", "testing strategy for", "test matrix for", "what cases should I cover", "help me plan tests", mentions "/test-plan", or wants to understand what tests are needed before writing any test code.

    Also in 3 projects that use this

  • Sagargupta16Skill

    dependency-audit

    Audit project dependencies for security vulnerabilities, licensing issues, maintenance health, and optimization opportunities. Use it during regular security audits (monthly or quarterly); before a major release when you want to ensure the dependency tree is clean; when evaluating whether to adopt or replace a dependency; after a security advisory affects one of your dependencies; when your install times or bundle sizes have grown noticeably.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 51 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use the Agent tool to dispatch one threat-modeling subagent.

    line 29
  2. Distinctive:

    Render that JSON as a Markdown report for the developer: Do not show the raw JSON. The report shape:

    line 34

“Common” is measured: kept by at least 6 in 10 of the 51 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Threat Model (A06:2025)

What this checks

This skill produces the threat-model context a developer needs before writing the code: what is this thing, where will it run, what inputs do we trust, what inputs do we not. It does not emit findings or apply a checklist of "missing controls" — that's the developer's job once they have the context.

Single source of truth: this skill delegates to the threat-modeling subagent in .claude/agents/threat-modeling.md. The subagent's JSON output is the canonical threat-model shape.

Vulnerable patterns

This is an orchestrator skill. The agent it dispatches has no vulnerable-pattern catalog of its own — it produces context, and later auditors (vulnerability-audit, design-review, contract-audit) use that context to find code-level issues.

Procedure

Use the Agent tool to dispatch one threat-modeling subagent. Pass it the plan, spec, or codebase under discussion. The subagent returns a JSON object describing purpose, deployment, trusted inputs, and untrusted inputs.

Render that JSON as a Markdown report for the developer. Do not show the raw JSON. The report shape:

## Threat Model — <one-line summary derived from purpose>

**Purpose.** <purpose>

**Deployment.** <deployment>

**Trusted inputs** (the maintainer controls these; auditors should
not flag content originating here):

- <category 1>
- <category 2>
- ...

**Untrusted inputs** (cross a trust boundary; every one needs an
explicit handling step in the plan — validation, rate limit,
authentication, etc.):

- <category 1>
- <category 2>
- ...

---

*Use this as the design checklist for what your plan must address.
The skill produced context; deciding which controls to add is
yours.*

The closing line is intentional — this skill does not enforce specific controls or emit findings. It surfaces the trust-boundary picture; the developer decides what to add (auth on new endpoints, rate limits on user-facing surface, validation on external-service responses, …).

Verification

  • Output is a Markdown report (not raw JSON) with a ## Threat Model heading
  • Purpose, Deployment, Trusted inputs, and Untrusted inputs are each present as labeled sections
  • Trusted-input and untrusted-input categories are listed explicitly (one bullet per category)
  • The report describes the system; it does NOT list "missing controls", recommend specific mitigations, or emit findings — that work belongs to design-review or to the developer's own follow-up

References

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.