Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →cbrock84/threat-modeling
Identifies what could go wrong in a system before it is built or changed — the assets worth attacking, the entry points, the trust boundaries, and the controls that actually address the realistic threats. Use this when designing a feature or system, when a change touches authentication, data handling, payments, or external input, before a security review, or when deciding which security work is worth doing at all.
Passed 22 of 24 test cases with the skill, and 15 of 24 without it.
and 7 more in the full report
7 fixed15 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are establishing formal guidelines for resolving disputes during security assessments. Where in our project structure are external authoritative sources documented, and how must team members interact with those referenced authorities?
| Checked | Without skill | With skill |
|---|---|---|
| Direct references to references/sources.md for authoritative outside sources. | Missed | Passed |
| Require citing designated reference sources before settling covered questions. | Passed | Passed |
The instructions your model reads when the skill loads.
Done at design time this is cheap and changes the design. Done after launch it produces a list of things that are expensive to fix, so the timing is most of the value.
1. What are we building? A diagram of the actual data flow — not the org chart, not the marketing architecture. Components, the data moving between them, and where each store lives. If nobody can draw it, that is the first finding.
Mark the trust boundaries: every point where data crosses from something you control to something you do not, or from one privilege level to another. Almost every real vulnerability lives on a boundary.
2. What can go wrong? Walk each boundary and each asset. A usable prompt set:
Two that catch more real bugs than the classic list: what does the client enforce that the server does not, and what happens on the second attempt — replay, race, and double-submit.
3. What are we going to do about it? For each realistic threat: mitigate, transfer, avoid, or accept. Accepting is legitimate; accepting silently is not.
Prioritize by attacker effort against impact, not by how alarming it sounds. A trivially exploitable tenant-isolation bug outranks a theoretical timing attack every time.
4. Did we do a good job? Re-check the model when the design changes. A threat model that describes last quarter's architecture is worse than none, because it produces false confidence.
test cases passed, vs 15 / 24 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.