Assisted-by: Claude Fable 5 via Claude Code

diff --git a/ai/skills/threat-modeling/SKILL.md b/ai/skills/threat-modeling/SKILL.md
new file mode 100644
index 00000000..18635a8c
--- /dev/null
+++ b/ai/skills/threat-modeling/SKILL.md
@@ -0,0 +1,90 @@
+---
+name: threat-modeling
+description: Use when writing or reviewing a threat model, designing a system with security implications, or evaluating security claims and trade-offs — covers the seven questions, layered decomposition, risk status categories, and spotting weak security reasoning
+---
+
+# Threat modeling
+
+An informal, practical approach to threat models, from Soatok's guide.
+Threat modeling belongs at the design stage — architectural mistakes
+(wrong abstractions, unsolvable ordering requirements) are detectable
+there and expensive to discover post-implementation.
+
+## The seven questions
+
+A threat model answers these, in roughly this order:
+
+1. What are we protecting? (assets)
+2. Who or what wants to harm it? (threat actors — hackers, activists,
+   cyber-stalkers, disgruntled employees, hostile legislators,
+   nation-states)
+3. How might 2 attack 1? (attack vectors)
+4. What will we do to prevent 3? (controls)
+5. How are the assets related and connected? Think in graphs, not
+   lists — attacks travel along relationships.
+6. What assumptions are we making, especially in 4 and 5?
+7. What threats are we deliberately not addressing? (accepted risks)
+
+Questions 6 and 7 separate good threat models from bad ones. An
+incorrect assumption undermines the whole model — the Invisible
+Salamanders attack works because AEAD schemes like AES-GCM and
+ChaCha20-Poly1305 are assumed to bind a ciphertext to a single key,
+and they don't. Writing assumptions down is how unknown unknowns get
+found.
+
+## Method
+
+- Map the system's components graphically and draw the relationships
+  between components that interact or depend on each other.
+- Work in nested abstraction layers: start broad, then drill into
+  specifics. Different components have different security dependencies —
+  a database's needs aren't a load balancer's.
+- For each layer, document inputs, outputs, and answers to the seven
+  questions. For layers you're not examining deeply, document the
+  assumptions you're making about them instead.
+- Look for relationships that shouldn't exist and sever them.
+- Treat the result as a living document. A model unchanged for years
+  while vulnerabilities accumulate is a red flag, not a sign of
+  stability.
+
+## Structure of a good one
+
+Soatok's [Public Key Directory threat model][pkd] (key transparency for
+the Fediverse) is the worked example. Sections: assumptions stated
+upfront, then assets, then actors (attackers and protected parties,
+each given a role name), then risks. Each risk gets a status:
+
+| Status | Meaning |
+|---|---|
+| Prevented by design | The attack cannot happen |
+| Mitigated | The attack fails unless an assumption breaks |
+| Addressable | Mitigation is possible but takes effort |
+| Open | Accepted risk; the attack will succeed |
+
+The anti-pattern is a flat list of attack types with no assumptions, no
+asset inventory, no relationships, and stale coverage (Matrix's threat
+model earns a C- on these grounds). That said: a shitty threat model
+beats not having a threat model.
+
+## Using it to evaluate claims
+
+The same discipline detects weak security reasoning in debates and
+reviews: check the factual premises, check whether a proposed control
+actually mitigates the stated risk, and check for hedges that don't
+hold in the scenario they claim to address. Example from the
+post-quantum debate: hybrid PQ+ECDH hedges against a pre-Q-Day break of
+the PQ algorithm but adds zero security post-Q-Day, so "hybrid always"
+is not the safety argument it sounds like — pure ECDH is what Q-Day
+retroactively breaks.
+
+Controls trade against usability, and the trade cuts back: "security at
+the expense of usability comes at the expense of security" (Avi
+Douglen). Threat modeling sometimes surfaces controls that improve
+both — passkeys kill credential stuffing (asymmetric, domain-bound,
+nothing reusable to stuff) and are easier to use than passwords.
+
+[pkd]: https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#threat-model
+
+## Sources
+
+- [Soatok's Informal Guide to Threat Models](https://soatok.blog/2026/06/30/soatoks-informal-guide-to-threat-models/) (Soatok, 2026)