threat-model

• SKILL.mdcore · 11,646 bytes
• references/checklist.mddoc · 5,961 bytes
• references/mapper-brief.mddoc · 2,340 bytes
• references/template.mddoc · 1,992 bytes

# threat-model

Produce `threat-model.md`: a ranked list of concrete ways an attacker can abuse the thing being built, each paired with a mitigation and the test or check that shows the mitigation works. A threat model that lists risks without proof steps gets read once and forgotten. Tying every mitigation to a check turns the model into work items the implementation can be held to.

Run it before implementation when a plan exists, so mitigations land in the plan instead of in a later patch. Run it on existing code when someone asks what an attacker could do with a system you are about to change or expose.

## When to skip

Skip it, with a one-line note in your reply saying why, when the change moves no trust boundary. Examples: a rename, extracting a function, reformatting, a dependency bump with no new capability, or a refactor where every input still arrives through the same validated path and reaches the same sinks with the same privileges. The test is concrete: if the data-flow map you would draw before and after the change is identical, there is nothing new to model.

Do not skip because the change is small. A one-line change that adds a tool to an agent's allowlist, a new outbound HTTP call, a new environment variable read by CI, or a new field passed to an LLM prompt moves a boundary. When in doubt, run step 1 and 2 only; if the map shows a new edge, continue.

For reviewing a finished diff for exploitable bugs, use the `security-review` skill (`../security-review/SKILL.md`) instead. This skill reasons about design; that one hunts defects in code that exists.