ears-requirements_skill

This skill converts natural language requirements into precise EARS statements, identifying patterns and ensuring measurable, testable outcomes.

Python

0

GitHub Stars

2

Bundled Files

2 months ago

Catalog Refreshed

3 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill hexbee/hello-skills --skill ears-requirements

openai.yaml282 B
SKILL.md2.6 KB

Overview

This skill converts ambiguous or draft system requirements into EARS-compliant statements to improve clarity, testability, and traceability. It preserves original intent while enforcing EARS clause order, single-subject rules, and measurable responses. The result is a set of precise, testable requirements with pattern labels and short rationales when needed.

How this skill works

The skill extracts intent from user input, determines the correct EARS pattern (ubiquitous, state-driven, event-driven, optional-feature, unwanted-behavior, or complex), and rewrites each requirement using the mandated clause order and a single system subject. It runs a quality pass for measurability, testability, and missing conditions, returns rewritten statements, pattern labels, and brief rationales for disputed pattern choices.

When to use it

Converting informal or ambiguous requirements into structured EARS statements
Classifying existing requirements by EARS pattern for specification consistency
Reviewing requirements for missing triggers, states, or measurable responses
Preparing requirements for automated validation or test-case generation
Splitting combined behaviors into single-statement requirements

Best practices

Keep one requirement per statement with exactly one explicit system subject
Use shall for mandatory behavior and observable outcomes for responses
Follow the EARS clause order: While <state>, when <trigger>, the <system> shall <response>
Avoid vague qualifiers (e.g., as appropriate, if possible); insert numeric placeholders like <MAX_LATENCY_MS> when unknown
Run the quality gate: testability, clear actor/condition/response, consistent terminology

Example use cases

Take a product manager’s note and produce EARS-compliant requirements ready for review
Audit a requirement list and flag items missing triggers or measurable responses
Translate stakeholder conversations into single-statement, testable requirements
Classify a legacy requirements document into EARS patterns for modernization
Prepare requirements for use with scripts that validate syntax and produce machine-readable output

FAQ

I preserve the most likely intent and produce one or more alternative EARS statements with brief rationales; I mark ambiguous elements and suggest placeholder tokens for unknown numeric limits.

Can multiple behaviors be combined in one statement?

No. I split independent behaviors into separate EARS statements and note the minimal change required to maintain traceability.

Do you generate tests or only requirements?

I focus on clear, testable requirements; I will flag pass/fail criteria and measurable outputs, which can be directly used to create test cases.