security-requirement-extraction

Overview of security-requirement-extraction skill

What the security-requirement-extraction skill does

The security-requirement-extraction skill helps turn threat analysis and business context into usable security requirements. Its core job is not generic “security advice,” but structured translation: from risks, abuse cases, and compliance drivers into requirements, user stories, acceptance criteria, and testable security expectations.

Who should use it

This skill is best for security engineers, architects, product security teams, business analysts, and delivery teams doing Requirements Planning. It is especially useful when you already know the threats or business goals, but need to express them in a form that product and engineering teams can build and verify.

Best-fit job to be done

Use security-requirement-extraction when you need to answer questions like:

• “Given these threats, what security requirements should the product have?”
• “How do we convert a threat model into acceptance criteria?”
• “What security user stories belong in the backlog?”
• “How do we map business protection goals to technical expectations?”

What makes it different from a generic prompt

The main value of the security-requirement-extraction skill is its framing. It centers requirement categories, requirement types, and requirement quality attributes such as traceability and testability. That matters because many ordinary prompts jump straight to controls, while this skill pushes the model to produce requirements that can be reviewed, prioritized, and validated before control selection.

What to know before installing

This skill is lightweight: the repository evidence shows only a SKILL.md file, with no helper scripts, references, or rule files. That makes adoption easy, but also means output quality depends heavily on the quality of your input context. If you provide vague threats, you will get vague requirements.

When this skill is a poor fit

Do not choose security-requirement-extraction if your real need is:

• a full threat modeling method from scratch
• detailed control implementation steps
• compliance legal interpretation
• automated scanning or policy enforcement

It is strongest in the middle of the workflow: after risks are identified, before controls are fully designed and implemented.

How to Use security-requirement-extraction skill

Install context for security-requirement-extraction

If you use the Skills ecosystem, install it from the repository that contains the skill:

npx skills add https://github.com/wshobson/agents --skill security-requirement-extraction

The repository signals show this skill lives at plugins/security-scanning/skills/security-requirement-extraction, and the practical source to read first is:

• SKILL.md

Read this file first

Start with SKILL.md before doing anything else. For this skill, that file contains the real operating guidance: when to use it, requirement categories, requirement types, and requirement attributes. Because there are no supporting resources or scripts, most of the usable logic is in that single file.

What input the skill needs

For strong security-requirement-extraction usage, provide at least:

• system or feature description
• business goal
• assets to protect
• known threats or misuse cases
• user roles and trust boundaries
• applicable compliance or policy constraints
• deployment context
• desired output format

Without that information, the skill can still generate requirements, but they will be generic and harder to trace back to actual risk.

Minimum viable prompt

A workable prompt usually includes:

1. the feature or system scope
2. the threats you want translated
3. the output artifact you need

Example:

“Use the security-requirement-extraction skill for Requirements Planning. We are building a customer billing portal. Threats include credential stuffing, privilege escalation, and PII exposure in logs. Derive security requirements grouped by functional, non-functional, and constraint types. Include traceability to each threat and draft acceptance criteria.”

Stronger prompt pattern

A stronger prompt gives the model enough structure to produce requirements that are reviewable:

• Business context: who uses the system and what matters commercially
• Threat source: STRIDE outputs, abuse cases, incidents, pentest findings, or architecture review notes
• System boundaries: services, data stores, integrations, admin paths
• Requirement style: user stories, shall statements, backlog items, or test cases
• Quality bar: testable, traceable, prioritized, and non-duplicative

Example:

“Use security-requirement-extraction to convert the following threat model into backlog-ready requirements. System: multi-tenant SaaS admin console. Assets: tenant configs, audit logs, API tokens. Threats: broken access control on admin APIs, token leakage in frontend logs, insecure session handling, missing auditability for privileged changes. Constraints: must align with SOC 2 controls and existing SSO platform. Output:

1. security requirements by type,
2. linked threat IDs,
3. rationale,
4. measurable acceptance criteria,
5. suggested security test cases.”

How to turn rough goals into better prompts

A weak request says, “Give me security requirements for this app.”

A better request says:

• what app
• what risks
• what data
• what constraints
• what output shape

Good transformation example:

Weak:
“Generate security requirements for a healthcare app.”

Better:
“Use the security-requirement-extraction skill for a patient portal handling PHI. Threats include unauthorized record access, weak session expiration, insecure file upload, and audit log tampering. Produce functional, non-functional, and constraint requirements with traceability, testability, and acceptance criteria.”

Suggested workflow in practice

A practical workflow for security-requirement-extraction guide use is:

1. Collect business context and feature scope.
2. Gather threats from a model, incident review, or architecture notes.
3. Ask the skill for requirement candidates by type.
4. Review for duplicates, missing assumptions, and non-testable wording.
5. Convert approved items into backlog stories, architecture requirements, or test cases.
6. Add trace links back to threat IDs and compliance sources.

This workflow is where the skill adds the most value: it reduces the gap between security analysis and delivery-ready artifacts.

What output formats work best

This skill is especially good at generating:

• requirement lists
• security user stories
• security acceptance criteria
• security test cases
• requirement-to-threat mappings
• architecture documentation inputs

If your team uses a specific format, ask for it directly. The skill’s structure supports multiple requirement styles, but the default output will be more useful if you specify your preferred artifact.

Practical tips that improve output quality

For better security-requirement-extraction usage:

• Provide threat IDs or labels so traceability is explicit.
• Ask for measurable language instead of broad goals.
• Separate business requirements from technical controls.
• Request assumptions and open questions when context is incomplete.
• Ask the model to flag requirements that are not testable.

These tips matter because the skill emphasizes requirement quality, not just idea generation.

Common repository limitation to account for

Because the repository has no helper assets beyond SKILL.md, there is less built-in enforcement than in richer skills. You should expect to do one review pass for:

• control-level overreach
• duplicated requirements
• vague wording like “secure,” “appropriate,” or “robust”
• requirements that mix policy, design, and implementation in one line

security-requirement-extraction skill FAQ

Is security-requirement-extraction good for Requirements Planning?

Yes. security-requirement-extraction for Requirements Planning is a strong fit because it helps convert security concerns into backlog-ready requirements, stories, and acceptance criteria. It is more useful at planning time than after implementation has already started.

Do I need a formal threat model first?

No, but you need some risk input. A formal threat model is ideal, but incident patterns, abuse cases, security review notes, or architecture risks can also work. The better the threat input, the better the requirement output.

How is this different from asking an LLM for security requirements?

A generic prompt often produces a loose checklist. The security-requirement-extraction skill is more disciplined around requirement categories, requirement types, and requirement attributes like traceability and testability. That structure usually leads to artifacts teams can review and implement more easily.

Is the skill beginner-friendly?

Moderately. Installation is simple, but good results require you to supply useful context. Beginners can still use it, but should expect to iterate and may need help distinguishing requirements from controls.

Can it produce technical controls directly?

It can suggest them, but that is not the main point of the skill. The skill is designed to move from business needs and threats into security requirements first. That separation is useful when you want solution flexibility or need stakeholder review before implementation choices.

When should I not use security-requirement-extraction?

Skip it if your immediate need is:

• code remediation guidance
• scanner setup
• control validation tooling
• legal-grade compliance interpretation
• a full secure architecture design package

In those cases, this skill can contribute inputs, but should not be your primary method.

How to Improve security-requirement-extraction skill

Give better threat inputs, not just more text

The fastest way to improve security-requirement-extraction output is to provide clearer threats. “Data breach risk” is weak. “Unauthorized tenant-to-tenant data access via missing authorization checks in reporting endpoints” is strong. Specific threats produce requirements that are more testable and less generic.

Separate requirements from controls

A common failure mode is asking for requirements and getting implementation decisions too early. Improve results by asking for:

• requirement statement
• rationale
• acceptance criteria
• possible controls as a separate optional field

That keeps the requirement portable even if your tech stack changes.

Ask for traceability explicitly

If traceability matters, say so in the prompt. For example:

• map each requirement to threat ID
• map to business objective
• map to compliance source where relevant

This makes the security-requirement-extraction skill more useful in audits, architecture reviews, and backlog grooming.

Force testable language

Many first-pass outputs use soft wording. Ask the model to rewrite every requirement so it can be validated. Good additions include:

• measurable thresholds
• event coverage expectations
• actor and data scope
• pass/fail acceptance criteria

Testable wording sharply improves downstream engineering usefulness.

Request prioritization when backlog pressure is real

If you need decision support, ask the skill to classify requirements by:

• must-have vs should-have
• pre-launch vs post-launch
• threat severity
• compliance criticality

That helps teams avoid generating a large but unusable list.

Use one iteration to remove ambiguity

After the first draft, ask:

• which requirements are duplicates?
• which are too vague to test?
• which depend on unresolved architecture decisions?
• which are actually controls, not requirements?

This review prompt often improves output more than asking for a completely new draft.

Add system boundaries and assumptions

The skill performs better when you specify boundaries such as:

• internal-only vs internet-facing
• single-tenant vs multi-tenant
• managed identity vs local auth
• sensitive data classes
• admin capabilities

These details materially change the resulting requirements, especially around access control, logging, and data handling.

Improve outputs with artifact-specific requests

If your deliverable is known, name it. For example:

• “write security user stories”
• “produce acceptance criteria”
• “derive security test cases”
• “draft architecture security requirements”

The skill can cover all of these, but the output gets stronger when the target artifact is explicit.

Validate the final set before adoption

Before treating the result as finished, check that each requirement is:

• linked to a real risk or business need
• understandable by non-security stakeholders
• testable without guessing intent
• not merely a copied control statement
• scoped to the actual system boundary

That final validation step is where security-requirement-extraction install becomes worthwhile in practice: it turns a simple skill into a repeatable planning aid instead of a one-off prompt.