threat-modelinglisted

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/threat-modeling/SKILL.md. --> # Threat Modeling Decide what a design must be true before code exists: naming assets and actors, locating trust boundaries, producing a written (asset, boundary, threat, control, owner) list, recording the assumptions the design rests on, and knowing when a change invalidates the model. Use when scaffolding a new feature, service, or endpoint, writing or reviewing a design doc, RFC, or ADR, or introducing a new trust boundary, integration, or data flow. ## ALWAYS - Produce a **written list**, not an impression. One row per finding, in the design doc, the RFC, or the PR description: `(asset, boundary, threat, control, owner)` — what is worth taking, where it crosses, what could go wrong there, what stops it, and which component enforces it. A model that exists only in the reasoning that produced the code cannot be reviewed, disagreed with, or checked later. - Name the **assets** and the **actors** first: data, funds, credentials, keys and compute on one side; users, tenants, services, admins and the attacker on the other. Every later row references one of each, which is what makes the list finite. - Locate the **trust boundaries** — internet to application, tenant to shared store, service to service, user input to an interpreter, model output to anything that acts on it. A bo