CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/stride-threat-modeling

Use when a design, story or architecture sketch touching login, user data, payments, file uploads or an external integration is about to be built with no threat model. Walks assets and trust boundaries through Microsoft's STRIDE categories, triages threats and writes the threat model into the repo.

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Quality

Content

78%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a well-structured, highly actionable instruction skill with an exemplary progressive-disclosure split and a clearly sequenced workflow with embedded checkpoints. Its main weakness is token efficiency: verbatim Microsoft quotes and a full STRIDE-definition table spend context on concepts Claude already knows.

Suggestions

Trim the six-STRIDE-category table to the letter, threat name, and violated property, dropping the verbatim Microsoft definition quotes — Claude already knows the category definitions, and the citation links can carry the sourcing.

Condense the 'What this owns, and what it does not' comparison table to a short bullet list of the two or three disambiguations that actually cause mis-triggering (e.g., scanners and penetration testing).

Move the MSDN/DREAD provenance quotes (the "an obvious malfunction" and "we're NOT using this internally" passages) into references/mitigations.md alongside the other citation detail, keeping only the operative rule in the body.

DimensionReasoningScore

Conciseness

The six-STRIDE-category table with verbatim Microsoft definitions (e.g., "illegally accessing and then using another user's authentication information, such as username and password") re-explains a classification Claude already knows, and the boundary/quote material could be tightened. It is mostly efficient — the steps, matrix, output template, and anti-patterns all earn their tokens — so it sits above the verbose 2-anchor but below the minor-trim 4-anchor.

3 / 5

Actionability

The guidance is fully concrete for an instruction-only skill: the element-by-STRIDE applicability matrix, the exact scoring formula ("score = likelihood x impact, each rated 1 (low) to 3 (high)"), the exact output path `docs/threat-models/<YYYY-MM-DD>-<feature-slug>.md`, a copy-paste-ready output template with populated example rows, and a worked example in the reference file. Per the rubric's code-vs-instruction note, the absence of code is not penalized.

5 / 5

Workflow Clarity

A clear five-step sequence plus a three-step from-spec workflow, with explicit checkpoints (inventory sanity rules "No magic sources or sinks", the Step 3 relevance filter, "Never fabricate threats") and an anti-patterns checklist. It falls short of the 5-anchor because there is no explicit post-write validation or re-check loop on the produced threat table (e.g., re-reviewing rows for generic mitigations before committing).

4 / 5

Progressive Disclosure

The ASVS anchor table and the end-to-end worked example are split into references/mitigations.md (verified to exist), referenced twice with clear context, exactly one level deep, and linking back to the SKILL.md spine. The body keeps the overview, process, and output format, matching the 5-anchor's clear overview with well-signaled one-level-deep references.

5 / 5

Total

17

/

20

Passed

Description

87%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is strong: it explicitly states both what the skill does and when to use it, with natural trigger terms (login, payments, file uploads, external integration) and a distinct pre-implementation threat-modeling niche. The only gap is slightly compressed action coverage and a few missing synonym variants.

DimensionReasoningScore

Specificity

"Walks assets and trust boundaries through Microsoft's STRIDE categories, triages threats and writes the threat model into the repo" lists several specific, third-person actions, but coverage is less granular than the comprehensive 5-anchor (only three actions, no mention of the filtering or output format steps). It exceeds the 3-anchor because more than 1-2 concrete actions are named.

4 / 5

Completeness

An explicit "Use when..." clause with concrete trigger conditions answers "when", and "Walks assets and trust boundaries... triages threats and writes the threat model into the repo" explicitly answers "what" including where the output lands. This matches the 5-anchor (both what and when explicit with concrete trigger phrases); the 4-anchor's weaker "when" does not apply.

5 / 5

Trigger Term Quality

"design, story or architecture sketch", "login, user data, payments, file uploads or an external integration", and "no threat model" are natural phrases a user would say, with synonyms for the spec artifact. A few natural variants are missing (e.g., "authentication", "PII", "API/webhook"), keeping it below the comprehensive 5-anchor.

4 / 5

Distinctiveness Conflict Risk

"Microsoft's STRIDE categories" combined with "about to be built with no threat model" carves a clear pre-implementation planning niche that is unlikely to fire for scanning, pentest, or code-review skills. Conflict risk is minimal, matching the 5-anchor.

5 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

On this page