stride-analysis-patterns
by wshobsonstride-analysis-patterns helps agents run a structured STRIDE threat-modeling pass for architectures, APIs, and data flows. Install from the wshobson/agents repo, read the SKILL.md file, and use it to turn system descriptions into categorized threats and control-focused review output.
This skill scores 78/100, which makes it a solid listing candidate for directory users. The repository evidence shows substantial real content and a clearly named/useful purpose: applying STRIDE to threat modeling and security documentation. Users can reasonably expect better structure and prompting leverage than a generic security-analysis prompt, though they should also expect a documentation-heavy skill without supporting artifacts, executable helpers, or strong constraint/decision guidance.
- Clear triggerability: the frontmatter and "When to Use" section explicitly map it to threat modeling, architecture review, security design review, and audit/documentation work.
- Material workflow value: the long SKILL.md includes STRIDE categories, a threat analysis matrix, and multiple structured sections rather than placeholder or demo-only content.
- Good agent leverage for repeatable analysis: the methodology gives a reusable framework for systematically covering spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
- Adoption is documentation-only: there are no support files, references, rules, scripts, or install instructions to reduce execution guesswork.
- Operational guidance appears lighter than the document size suggests: structural signals show limited explicit workflow/constraint/practical cues, which may leave agents to infer output format and depth.
Overview of stride-analysis-patterns skill
What stride-analysis-patterns does
The stride-analysis-patterns skill helps an agent run a structured STRIDE threat-modeling pass instead of producing a loose security brainstorm. Its job is to turn a system description into categorized threats across Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
Best fit for this skill
This stride-analysis-patterns skill is best for security reviews of architectures, APIs, services, data flows, and design changes where you need systematic coverage more than deep exploit research. It fits engineers, security reviewers, architects, and teams preparing design reviews, audits, or threat-model documentation.
Real job-to-be-done
Most users are not looking for a textbook explanation of STRIDE. They need a repeatable way to ask, “What could go wrong in this design, by category, and what control family should we consider next?” The value of stride-analysis-patterns for Threat Modeling is consistency: it reduces skipped categories and gives a cleaner starting point for mitigation planning.
What makes it different from a generic prompt
A normal prompt often returns mixed-risk security advice with uneven coverage. stride-analysis-patterns pushes analysis through a known matrix of threat classes and guiding questions. That makes outputs easier to review, compare across systems, and turn into backlog items or security documentation.
What to know before installing
This skill is lightweight: the repository evidence shows the implementation is mainly in SKILL.md with no extra scripts or helper resources. That is good for quick adoption, but it also means output quality depends heavily on the quality of the architecture context you provide. If your system description is vague, the threat list will be generic too.
How to Use stride-analysis-patterns skill
Install stride-analysis-patterns skill
Install from the repository with:
npx skills add https://github.com/wshobson/agents --skill stride-analysis-patterns
Because the skill lives at plugins/security-scanning/skills/stride-analysis-patterns, installing from the repo is the practical path rather than copying the markdown manually.
Read this file first
Start with:
plugins/security-scanning/skills/stride-analysis-patterns/SKILL.md
There do not appear to be supporting README.md, rules/, or resources/ files for this skill, so most of the usable guidance is concentrated in that single file. This is good news for fast evaluation: you can judge the full method quickly.
What input the skill needs
For strong stride-analysis-patterns usage, provide:
- system purpose
- main components
- trust boundaries
- actors and roles
- authentication model
- sensitive data involved
- key entry points such as APIs, queues, admin panels, or webhooks
- important dependencies like IdP, cloud storage, databases, and third-party services
Without those details, the skill can still produce threats, but they will look like a generic STRIDE checklist rather than a model of your actual system.
Turn a rough goal into a strong prompt
Weak goal:
Analyze my app for threats.
Better prompt:
Use the
stride-analysis-patternsskill to threat model this system. It is a multi-tenant SaaS app with a React frontend, API gateway, Go services, PostgreSQL, Redis, S3 object storage, and an external OAuth provider. Identify threats by STRIDE category for each major component and trust boundary. For each threat, include the affected asset, likely attack path, impact, and the most relevant control family.
The second version gives the skill enough structure to produce reviewable output instead of broad security advice.
Recommended workflow in practice
A practical stride-analysis-patterns guide looks like this:
- Describe the architecture in plain English.
- List assets, actors, and trust boundaries.
- Ask the skill for threats by STRIDE category.
- Ask for the threats to be regrouped by component or data flow.
- Convert the final list into mitigations, design changes, or tickets.
This sequence matters because STRIDE works best after the system shape is clear. If you jump straight to mitigations, you may optimize for the wrong risks.
Ask for component-level analysis
The skill becomes more useful when you scope it to concrete surfaces such as:
- login and session handling
- admin functions
- file upload flows
- service-to-service authentication
- background jobs
- audit logging
- secrets handling
- tenant isolation
That usually produces better threat depth than asking for “the whole platform” in one pass.
Useful output format to request
Ask the agent to return a table with columns like:
- STRIDE category
- component or data flow
- threat statement
- attacker precondition
- impact
- suggested control family
- open questions
This keeps stride-analysis-patterns for Threat Modeling actionable. The “open questions” column is especially valuable when architecture details are incomplete.
How to use it for existing systems
For brownfield reviews, feed the skill whatever you already have:
- architecture diagrams
- API docs
- deployment descriptions
- ADRs
- incident history
- auth and permission docs
Then ask it to identify likely threats and point out missing architectural facts needed to complete the STRIDE pass. That is often more useful than pretending the documentation is complete.
Where this skill is strongest
The skill is strongest at threat enumeration and category coverage. It is less about exploit proof, scanner integration, or implementation-specific validation. Use it to discover and organize security concerns early, then hand the findings to code review, architecture review, or security testing workflows.
Common usage mistake
The main failure mode in stride-analysis-patterns usage is giving only a product summary and expecting system-specific results. “A fintech app for payments” is not enough. You need at least the key components, identities, data stores, and boundaries, or the analysis will stay generic.
stride-analysis-patterns skill FAQ
Is stride-analysis-patterns good for beginners?
Yes, if you already know your system better than you know STRIDE. The skill provides a usable structure for threat identification, so beginners can ask better security questions. It is less suitable if you want a full tutorial on threat modeling theory from zero.
When should I use stride-analysis-patterns instead of a normal security prompt?
Use stride-analysis-patterns skill when you need consistent category coverage and a documented reasoning structure. A normal prompt is fine for ad hoc security brainstorming, but it often misses categories like repudiation or elevation paths unless you ask very explicitly.
Is this only for formal threat-modeling sessions?
No. It also works for design reviews, pre-release architecture checks, audit prep, and security-focused backlog grooming. If the output will be reviewed by others, STRIDE structure makes the results easier to defend and refine.
What is this skill not good at?
stride-analysis-patterns is not a replacement for penetration testing, static analysis, dependency scanning, or secure code review. It identifies plausible threats; it does not prove exploitability or validate controls in a running environment.
Can I use stride-analysis-patterns for small systems?
Yes, but keep the scope tight. For a small internal tool, ask for threats around authentication, data access, logging, and availability. If you force a very small system through an overly broad enterprise-style model, the output may feel inflated.
Does it fit modern cloud and AI systems?
Yes, but only if you describe cloud identities, service boundaries, data movement, and external integrations clearly. For AI features, include prompt inputs, model providers, retrieval layers, secrets, and user-to-tool execution paths so the STRIDE categories map to real attack surfaces.
How to Improve stride-analysis-patterns skill
Give better architecture context
The fastest way to improve stride-analysis-patterns results is to provide a compact architecture brief before invoking it. Good briefs include:
- actors and privilege levels
- trust boundaries
- authentication and authorization approach
- sensitive assets
- data flows between components
- internet-exposed surfaces
This raises specificity more than asking for “more detail” after a weak first pass.
Separate assets from components
Users often mix “database,” “customer PII,” and “admin user” in one list. Better outputs come when you distinguish:
- components: API, worker, database, queue
- assets: credentials, audit logs, PII, tokens
- actors: customer, admin, support, attacker, third-party service
That separation helps the skill map threats more cleanly and avoid vague statements.
Force explicit trust boundaries
A strong stride-analysis-patterns guide prompt names boundaries such as:
- browser to frontend
- frontend to API
- API to internal services
- service to database
- production to third-party provider
- tenant to tenant
Many meaningful threats appear at boundaries, not inside isolated components.
Ask for evidence-oriented threat statements
Instead of accepting broad items like “tampering is possible,” ask for this pattern:
Threat, attacker action, affected asset, required precondition, likely impact, relevant control family.
This makes the output easier to triage and less like a checklist.
Iterate by category after the first pass
After the initial run, ask follow-ups like:
- “Expand only Spoofing threats for service-to-service auth.”
- “Re-run Information Disclosure for multi-tenant data access.”
- “Focus on Repudiation gaps in admin actions and audit logs.”
This is one of the best ways to improve stride-analysis-patterns skill output quality without rewriting everything from scratch.
Pair threat output with mitigation review
The skill naturally points toward control families such as authentication, integrity checks, logging, encryption, rate limiting, and authorization. After threat enumeration, ask the agent to map each finding to:
- existing controls
- missing controls
- compensating controls
- priority and implementation owner
That turns analysis into an adoption-ready review artifact.
Watch for overgenerated threats
A common problem is quantity over decision value. If the first pass returns too many repetitive threats, ask the agent to:
- merge duplicates
- rank by plausibility and impact
- remove generic items not supported by the described architecture
- highlight top risks per component
This is especially important when using stride-analysis-patterns for Threat Modeling in meetings or ticket creation.
Improve outputs with a system diagram summary
Even if you cannot share a full diagram, a text diagram helps. Example:
User -> CDN/WAF -> Web App -> API Gateway -> Auth Service
-> Orders Service -> PostgreSQL
-> File Service -> S3
Admin -> Admin Portal -> API Gateway
API -> External OAuth Provider
A summary like this gives the skill better anchors for category-by-category reasoning.
Know when to stop using this skill
If your main question becomes “Is this vulnerability exploitable in code?” or “Which exact control setting should I change in AWS right now?”, move beyond stride-analysis-patterns. At that point, use code review, cloud configuration review, runtime testing, or a more implementation-specific security skill.