ears-format

Write testable acceptance criteria using EARS event-driven, conditional, and continuous patterns.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/cooldaemon/dotfiles --skill ears-format
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ears-format
Source: https://github.com/cooldaemon/dotfiles/tree/main/.claude/skills/ears-format
Command: npx skills add https://github.com/cooldaemon/dotfiles --skill ears-format

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill provides a structured and standardized way to write acceptance criteria, ensuring clarity, testability, and reducing ambiguity in project requirements.

Core Features & Use Cases

  • Standardized Patterns: Offers distinct patterns (WHEN, IF, WHILE, WHERE) for different types of requirements.
  • Testability Focus: Designed to make acceptance criteria easily translatable into test cases.
  • Use Case: A product manager can use the EARS format to clearly define how a new feature should behave under various conditions, which then directly informs the QA team's test plan.

Quick Start

Use the ears-format skill to define acceptance criteria for a user login feature.

Frequently Asked Questions about ears-format

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

FAQPage Schema
What is the EARS format for writing acceptance criteria?

The EARS format is a standardized syntax for writing testable acceptance criteria using event-driven, conditional, and continuous patterns. It reduces ambiguity in project requirements to facilitate clear communication between product, development, and testing teams.

How do I write testable acceptance criteria for project requirements?

You can write testable acceptance criteria by applying standardized EARS patterns like WHEN, IF, WHILE, and WHERE. These event-driven and conditional structures ensure your requirements are unambiguous and easily translatable into QA test cases.

When should I use WHEN, IF, WHILE, and WHERE patterns in requirement documentation?

Use these EARS patterns in requirement documentation when defining how a feature behaves under specific conditions. WHEN handles event-driven triggers, IF manages conditional logic, WHILE addresses continuous states, and WHERE specifies configuration constraints.

How does the EARS syntax improve communication between product and testing teams?

The EARS syntax improves communication by providing an unambiguous specification for requirement definition. Its testability focus ensures product managers clearly define feature behaviors, which directly informs the QA team's validation and test plans.

Can I use EARS formatting for any type of project management requirement?

Yes, you can use EARS formatting for various project management requirements. Its flexible syntax accommodates event-driven, conditional, and continuous behavior patterns, making it suitable for defining diverse feature acceptance criteria across different contexts.