ears-spec-authoring

Draft stable acceptance criteria using EARS-lite shapes with AC-NNN IDs.

50|7|Updated Apr 18, 2026
One-click install
npx skills add https://github.com/loiane/specs-driven-development-spring-angular --skill ears-spec-authoring
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ears-spec-authoring
Source: https://github.com/loiane/specs-driven-development-spring-angular/tree/main/.windsurf/skills/ears-spec-authoring
Command: npx skills add https://github.com/loiane/specs-driven-development-spring-angular --skill ears-spec-authoring

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Draft stable acceptance criteria using concise EARS-lite shapes, with stable AC-NNN IDs and explicit Q-NNN open questions to prevent vague requirements from slipping into tasks.

Core Features & Use Cases

  • Five shapes cover ubiquitous, event-driven, state-driven, optional, and unwanted behavior to structure acceptance criteria.
  • Enforces one AC per condition and outcome, with rigid ID discipline (AC-NNN) and a dedicated Open Questions section to capture decisions.
  • Ideal for drafting or editing 01-spec.md, converting tracker tickets into concrete ACs, or responding to user requests for a requirements document.

Quick Start

Draft your first AC by selecting one of the five EARS shapes and assigning a stable AC-NNN ID to every condition and outcome.

Frequently Asked Questions about ears-spec-authoring

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

FAQPage Schema
How do I write stable acceptance criteria for requirements documents?

The EARS-lite approach structures acceptance criteria into five shapes covering ubiquitous, event-driven, state-driven, optional, and unwanted behavior to prevent vague requirements from slipping into tasks.

How do I convert tracker tickets into concrete acceptance criteria?

Convert tracker tickets into concrete acceptance criteria by assigning a stable AC-NNN ID to each condition and outcome, ensuring one AC per condition, and capturing unresolved decisions in a dedicated Open Questions section with Q-NNN IDs.

What is the best way to handle open questions in a specification document?

Handle open questions in a specification document by assigning an explicit Q-NNN ID to each unresolved decision within a dedicated Open Questions section, preventing vague requirements from slipping into development tasks.

Can I use EARS-lite to structure acceptance criteria for an existing 01-spec.md file?

Yes, you can apply EARS-lite to draft or edit an existing 01-spec.md file by selecting one of the five EARS shapes and assigning a stable AC-NNN ID to every condition and outcome to stabilize requirements.

When should I not use EARS-lite for acceptance criteria?

You should avoid using EARS-lite when your acceptance criteria require detailed implementation instructions, as the format enforces single condition and outcome pairs with no implementation details to prevent scope creep.