threat-modelerlisted

# threat-modeler — figure out what to defend before you defend it ## When to use this skill Trigger when the user wants a *planned* security view, not a generic scan. Strong signals: - "threat model this", "do a STRIDE analysis", "what's the attack surface" - "what could an attacker do here" - Before any new feature touching auth, payments, file uploads, PII, multi-tenancy, or webhooks - Before a SOC 2 / ISO 27001 / pen-test engagement - A new service is being designed and there's no security context yet Do *not* trigger for: a static code review (use `security-sentinel`), incident response (you need a responder), or generic "make this secure" requests where no specific surface has been picked. Pin a scope first. ## The output contract A `THREAT_MODEL.md` file with two layers: 1. **A machine-readable section** (front matter or JSON block) — downstream skills (`security-sentinel`, `code-auditor`) can parse it to scope what they look for. Lists assets, actors, entry points, trust boundaries, and threats with severity scores. 2. **A human-readable section** — the actual narrative. A new engineer should be able to read it in 15 minutes and understand what's worth attacking, what's worth defending, and where the team has *deliberately* accepted a risk. Plus three concrete deliverables alongside the doc: - An **assumption log** — every claim the model rests on, so the next reviewer can verify or invalidate - An **open-questions list** — the things the interview couldn't re