threat-modellisted

# Threat Model <!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions truncated or dropped, which strips the very keywords a match depends on. --> Trigger phrases: "threat model", "attack surface", "scope the audit", "trust boundary" Scope first, scan second. A security scan with no map produces noise; a threat model tells the scanner (and `security-scan`) **where to look and what matters** — the single biggest lever on false positives. The one idea to keep — the litmus test: **if patching one line of code makes an entry disappear, it was a vulnerability, not a threat.** Threats survive patching (they name *what an attacker wants and the surface they arrive through*); a vulnerability is only **evidence** that raises a threat's likelihood. > **Kit adaptation (local, .claude/):** `security-expert-csk` runs this to scope before `security-scan`. Output > `docs/THREAT_MODEL.md` is internal (§4.3). Stack-agnostic. §4 Prohibitions apply. ## When - Before a first `security-scan` of a system, or when scan output is noisy / unscoped. - After a significant new surface — a new API, a new integration, a new trust boundary. ## Two modes - **interview** — the owner is available: ask the four questions below, one at a time. - **bootstrap** — no owner: derive the model from code + past advisories, then flag what only the owner can confirm. ##