threat-modelinglisted

# Threat Modeling Threat modeling is structured anticipation: you reason about how a system can be attacked **while it is still cheap to change** — at design time, on paper or in a diagram, before the code exists. The output is not a document; it is a set of mitigations wired to tests and a habit of asking "what could go wrong?" continuously. This skill runs on **Shostack's Four Question Framework** ([Adam Shostack, *Threat Modeling: Designing for Security*](https://shostack.org/resources/threat-modeling)): What are we working on? What can go wrong? What are we going to do about it? Did we do a good job? Everything else — STRIDE, DFDs, risk ranking — serves those four questions. ## Read first (always) List `learnings/` and read every file relevant to the current system (the domain, the trust boundaries, the third parties, the compliance regime). Project-specific assets, known attacker personas, accepted risks, and "in this system X is out of scope because Y" decisions live there and override the defaults in this SKILL.md. If a learning conflicts with this file, **the learning wins** — mention it to the user. If `learnings/` holds only its README, proceed with the defaults below. ## Why this matters Most vulnerabilities are design flaws, not coding bugs — a missing trust boundary, an unverified assumption, an authorization check that lives on the client. Code review and tests catch implementation defects; they rarely catch "we never decided who is allowed to do this." T