# Open Horizons Ears Validate

> Use when validating requirements against EARS notation patterns. Triggers include "EARS", "requirement review", "requirement quality", "shall statement", and "REQ-ID".

- Skill: `paulasilvatech/open-horizons-ears-validate-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add paulasilvatech/open-horizons-ears-validate-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/paulasilvatech/open-horizons-ears-validate-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: paulasilvatech (https://skillmd.com/u/paulasilvatech)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/paulasilvatech/open-horizons-ears-validate-2

---

# EARS validation

## When to invoke

- "Review these requirements for EARS compliance."
- "Is this requirement testable?"
- "Classify this requirement by EARS pattern."

## EARS patterns

| Pattern | Template |
| --- | --- |
| Ubiquitous | `The <system> shall <response>.` |
| Event-driven | `When <trigger>, the <system> shall <response>.` |
| State-driven | `While <state>, the <system> shall <response>.` |
| Optional | `Where <feature is included>, the <system> shall <response>.` |
| Unwanted | `If <undesired condition>, then the <system> shall <mitigation>.` |
| Complex | `While <state>, when <trigger>, the <system> shall <response>.` |

## Validation checklist

- [ ] Exactly one pattern per requirement.
- [ ] Unambiguous subject ("the system", not "it").
- [ ] Observable and testable response.
- [ ] No hidden "and" that combines two requirements into one.
- [ ] Implementation constraints appear only when they are approved architecture or platform boundaries.
- [ ] Generated AEG-native FRD/NFRD requirements use a unique `FR-<DOMAIN>-NNN` or `NFR-<DOMAIN>-NNN` ID; a platform contract SDD may use stable domain IDs only when `DECISIONS.md` and `SOURCE_TRACEABILITY.md` define the scheme, compatibility, and supersession rules.
- [ ] Includes at least one acceptance criterion.
- [ ] Includes a source entry in `SOURCE_TRACEABILITY.md` that identifies evidence or records `[GREENFIELD]` with a justification.

## Common defects

| Defect | Example | Correction |
| --- | --- | --- |
| Ambiguous | "The system must be fast." | "When a user submits a form, the system shall respond within 500ms." |
| Compound | "Log in and send an email." | Split into two requirements. |
| Not testable | "The system shall be easy to use." | Replace with a measurable UX metric. |
| Passive | "Login shall be supported." | "The system shall accept username/password authentication." |

## Output template

```markdown
### FR-DOMAIN-NNN: <title> (<pattern>)
<EARS statement>

**Priority:** P0 / P1 / P2

**Acceptance criteria (EARS):**
- AC-FR-DOMAIN-NNN-01 (<pattern>): <criterion 1>
- AC-FR-DOMAIN-NNN-02 (<pattern>): <criterion 2>

**Source traceability:** `<evidence reference>` or `[GREENFIELD] <justification>` in `SOURCE_TRACEABILITY.md`
```

## Quality gate

- [ ] Every generated AEG-native FRD/NFRD requirement has a unique `FR-<DOMAIN>-NNN` or `NFR-<DOMAIN>-NNN` ID; platform-contract or preserved historical IDs have an explicit decision and compatibility record.
- [ ] Every requirement is classified under exactly one EARS pattern.
- [ ] Every requirement has at least one testable acceptance criterion.
- [ ] Every acceptance criterion has a unique `AC-<REQ-ID>-NN` ID and one EARS pattern.
- [ ] Every requirement is covered by `SOURCE_TRACEABILITY.md` with verifiable evidence or a justified `[GREENFIELD]` entry.
- [ ] Measurable targets come from observed evidence or an accountable-owner-approved objective; unresolved targets remain blockers instead of being invented.
- [ ] The repository's SDD and traceability validators pass for the change.