security-requirement-extraction — Claude skill: threats into
Turns a threat model and business context into testable security requirements: user stories, acceptance criteria, test cases.
/plugin marketplace add wshobson/agents
/plugin install security-scanning@claude-code-workflowsWhat security-requirement-extraction does
The skill takes threat analysis and sorts it across three layers: business requirement, security requirement, technical control. “Protect customer data” becomes “encrypt PII at rest”, which then becomes a concrete control with key rotation.
It works with requirement categories — functional, non-functional, constraint — and four attributes: traceability to threats, testability, priority, risk level. Templates and worked examples sit in references/details.md, loaded when you need them.
You need a threat model first. Without one there is nothing to trace requirements back to, and the output stays generic. Worth installing if you maintain security documentation and write acceptance criteria for a team; skip it for quick code fixes.
What it helps with
- turn threats from a model into concrete requirements
- write security user stories with acceptance criteria
- build test cases that verify security requirements
- map requirements to compliance framework clauses
- assign priority and risk level to each requirement
Example prompts for the agent
- Take my threat model and derive security requirements by category
- Write security user stories with acceptance criteria from this threat list
- Build test cases for the requirements in `references/details.md`
How to install security-requirement-extraction
1Plugin marketplace
/plugin marketplace add wshobson/agents/plugin install security-scanning@claude-code-workflowsThis installs the whole security-scanning plugin with all its skills
2Skills CLI (Vercel)
npx skills add wshobson/agents --skill security-requirement-extraction -a claude-code3Manually: put the files in place
~/.claude/skills/security-requirement-extraction/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/security-requirement-extraction/
1Skills CLI (Vercel)
npx skills add wshobson/agents --skill security-requirement-extraction -a codex2Manually: put the files in place
.agents/skills/security-requirement-extraction/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add wshobson/agents --skill security-requirement-extraction -a cursor2Manually: put the files in place
.cursor/skills/security-requirement-extraction/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install wshobson/agents security-requirement-extraction2Manually: put the files in place
.github/skills/security-requirement-extraction/SKILL.mdPlatform CLI
gemini skills install https://github.com/wshobson/agents --path plugins/security-scanning/skills/security-requirement-extractionManually: put the files in place
.devin/skills/security-requirement-extraction/SKILL.mdThe legacy .windsurf/skills/ path still works
Claude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set213
The whole set →Similar
Questions about security-requirement-extraction
How do I install security-requirement-extraction in Claude?
Through the plugin marketplace: /plugin marketplace add wshobson/agents, then /plugin install security-scanning@claude-code-workflows. Or run npx skills add wshobson/agents --skill security-requirement-extraction -a claude-code.
What does security-requirement-extraction do?
It converts a threat model and business context into security requirements: user stories, acceptance criteria, test cases. Each requirement traces back to a threat and carries a priority and risk level.
What do I need before using it?
A threat model, or at least a list of threats. Without one there is nothing to trace requirements to, and the result will be generic.
Source text
SKILL.md · MIT
---
name: security-requirement-extraction
description: Derive security requirements from threat models and business context. Use when translating threats into actionable requirements, creating security user stories, or building security test cases.
---
# Security Requirement Extraction
Transform threat analysis into actionable security requirements.
## When to Use This Skill
- Converting threat models to requirements
- Writing security user stories
- Creating security test cases
- Building security acceptance criteria
- Compliance requirement mapping
- Security architecture documentation
## Core Concepts
### 1. Requirement Categories
```
Business Requirements → Security Requirements → Technical Controls
↓ ↓ ↓
"Protect customer "Encrypt PII at rest" "AES-256 encryption
data" with KMS key rotation"
```
### 2. Security Requirement Types
| Type | Focus | Example |
| ------------------ | ----------------------- | ------------------------------------- |
| **Functional** | What system must do | "System must authenticate users" |
| **Non-functional** | How system must perform | "Authentication must complete in <2s" |
| **Constraint** | Limitations imposed | "Must use approved crypto libraries" |
### 3. Requirement Attributes
| Attribute | Description |
| ---------------- | --------------------------- |
| **Traceability** | Links to threats/compliance |
| **Testability** | Can be verified |
| **Priority** | Business importance |
| **Risk Level** | Impact if not met |
## Templates and detailed worked examples
Full template library lives in `references/details.md`. Read that file when you need concrete templates for this skill.
## Best Practices
### Do's
- **Trace to threats** - Every requirement should map to threats
- **Be specific** - Vague requirements can't be tested
- **Include acceptance criteria** - Define "done"
- **Consider compliance** - Map to frameworks early
- **Review regularly** - Requirements evolve with threats
### Don'ts
- **Don't be generic** - "Be secure" is not a requirement
- **Don't skip rationale** - Explain why it matters
- **Don't ignore priorities** - Not all requirements are equal
- **Don't forget testability** - If you can't test it, you can't verify it
- **Don't work in isolation** - Involve stakeholders
© Seth Hobson · MIT · wshobson/agents