What problem does it solve? Vague acceptance criteria force engineering to re-derive intent during handoff and let edge cases slip into production. This Skill provides the EARS (Easy Approach to Requirements Syntax) clause patterns so every criterion is unambiguously testable and survives the PM-to-engineering owner flip without rewriting. ## Core Features & Use Cases - Five EARS Patterns: Ubiquitous (THE SYSTEM SHALL), Event-driven (WHEN), State-driven (WHILE), Unwanted-behavior (IF/THEN), and Optional-feature (WHERE) templates with concrete examples for each. - Freeform Fallback Rules: Guidance on when numerical targets, referenced standards, data-shape constraints, and static content checks should skip EARS. - Pre-Handoff Checklist: A blocking review gate covering explicit triggers, observable behavior, error-path IF clauses, feature-flag WHERE clauses, and weasel-word elimination. - Use Case: A PM authoring a story spec writes three WHEN clauses for the happy path, adds IF/THEN clauses for payment-provider 5xx retries and 10MB upload rejection, and a WHERE clause for the enterprise-plan SSO gate, producing AC that engineering delivers against directly. ## Quick Start Ask the AI to write EARS acceptance criteria for a story about CSV export, including error paths and feature-flagged behavior.
