Use threat-model

Produce a STRIDE threat model from a design doc, architecture description, or feature spec

Produce a STRIDE threat model from a design doc, architecture description, or feature spec — assets and trust boundaries first, threats anchored to boundary crossings with concrete attack scenarios, severity-ranked with verifiable mitigations.

Reach for it when the user asks to threat-model a design, run a security review of an architecture, ask "how could this be attacked", or needs security sign-off input before build.

Install it

npx skilldrop-cli install threat-model                 # Claude Code, your user folder
npx skilldrop-cli install threat-model --project       # Claude Code, this repo
npx skilldrop-cli install threat-model --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Solution architect pack: --pack solution-architect installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Threat model this design"
• "Run STRIDE on this architecture before we build it"
• "What could an attacker do to this system as designed?"
• "Security review of this design doc, with trust boundaries and attack scenarios"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Review this diff for exploitable security bugs"
• "Threat model my AI agent's tool and data access"
• "Audit this UI for accessibility barriers"

If another skill answers instead, ask for this one by name: "use threat-model".

Check what you get

A good result:

• Every threat is anchored to a named trust-boundary crossing or asset. An unanchored finding is checklist residue — cut it.
• Every threat narrates a scenario with actor, path, and result. "X is possible" is not a finding.
• Severity spread is honest. A model where everything is critical (or nothing is) hasn't ranked anything; the 🟥 set is what you'd halt the build for.
• Every recommended mitigation has a verification step a reviewer can run or check. Advice without verification is a wish.
• Existing mitigations are credited — and marked verified vs assumed. A model that ignores what the design already does right teaches the team to ignore the model.
• The insider and authz sweeps produced output — findings or an explicit reasoned all-clear, never silence.

See a worked example

• document upload

Use something else when

• Reviewing written code for vulnerabilities — that's devils-advocate (its security lens) or sonar-review
• Compliance attestation (SOC2, PCI evidence) — this models attacks, it doesn't certify controls
• Incident analysis after an exploit — that's postmortem-generator
• Pen-testing a live system — this is paper analysis; it tells the pen test where to aim

Where a loop runs it

• Stage threat of the design loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: design-doc, devils-advocate, postmortem-generator, reverse-architecture, sonar-review

Edit this page on GitHub · View source