ears-validate

Validates software requirements against EARS notation patterns and legacy traceability rules.

Updated Sep 10, 2026
One-click install
npx skills add https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula --skill ears-validate-serpro-workshop-fortaleza
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ears-validate
Source: https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula/tree/main/.github/skills/ears-validate
Command: npx skills add https://github.com/serpro-workshop-fortaleza/sifap-modernization-paula --skill ears-validate-serpro-workshop-fortaleza

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing clear, testable requirements is hard: teams produce ambiguous, compound, or untestable statements that cause rework later. This Skill reviews requirement statements against the EARS (Easy Approach to Requirements Syntax) notation, classifies each one into exactly one pattern, and enforces traceability back to legacy source code. ## Core Features & Use Cases - EARS pattern classification: Classifies each requirement as Ubiquitous, Event-driven, State-driven, Optional, Unwanted, or Complex, with templates for each pattern. - Quality checklist: Detects common defects such as ambiguous wording, hidden compound requirements, untestable statements, passive voice, and implementation details leaking into behavior specs. - Legacy traceability enforcement: Requires every requirement to carry a REQ-ID, acceptance criteria, and a source_legacy pointer to a Natural/Adabas legacy file or a justified [GREENFIELD] token. - Use Case: During a legacy modernization sprint, paste a draft requirement like "the system should be fast" and receive a corrected EARS statement such as "WHEN a user submits a form, the system SHALL respond within 500 ms", complete with REQ-ID, acceptance criteria, and traceability metadata. ## Quick Start Ask the assistant to review your draft requirements for EARS compliance and rewrite any that are ambiguous, compound, or missing traceability.

Frequently Asked Questions about ears-validate

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate requirements against EARS notation?

Submit your requirement statements and each one is classified into exactly one EARS pattern: Ubiquitous, Event-driven, State-driven, Optional, Unwanted, or Complex. Defective statements are rewritten using the correct template with a clear subject and observable response.

What are the EARS requirement patterns?

EARS defines six patterns: Ubiquitous (The system SHALL...), Event-driven (WHEN trigger...), State-driven (WHILE state...), Optional (WHERE feature included...), Unwanted (IF undesired condition THEN...), and Complex (WHILE state, WHEN trigger...).

How do I make an untestable requirement testable?

Replace vague qualities like fast or user-friendly with measurable criteria, for example a response time under 500 ms. Every requirement must include at least one acceptance criterion that can be objectively verified.

What is the source_legacy field in a requirement?

The source_legacy field links each requirement to a real legacy file, such as a Natural program (.NSN) or Adabas DDM, with line ranges. If no legacy equivalent exists, use the [GREENFIELD] token with a justification for the new implementation.

Why does a requirement fail the legacy-traceability CI check?

The check fails when a requirement lacks a REQ-ID in REQ-NNN format, has no acceptance criteria, or has an empty or invalid source_legacy pointer. Fix these fields so the spec-quality workflow passes on the pull request.