What is EARS?
EARS stands for Easy Approach to Requirements Syntax. It's a small set of templates that force you to be specific about when something should happen and what the system should do.
It looks like this:
WHEN [trigger], THE SYSTEM SHALL [behavior].
That's it. That's the whole idea.
Kiro generates requirements in EARS format by default. Lovable and Claude will follow EARS if you ask them to. Once you get used to writing acceptance criteria this way, you stop writing vague requirements anywhere — specs, tickets, bug reports, all of it.
Vague vs. EARS — side by side
"The system should handle login securely."
WHEN a user submits valid credentials, THE SYSTEM SHALL create a session and redirect to the dashboard within 2 seconds.
IF the credentials are invalid, THEN THE SYSTEM SHALL display an error message without revealing which field was incorrect.
WHEN a user fails to authenticate three times in five minutes, THE SYSTEM SHALL lock the account for 15 minutes.
Now the AI tool has something to build. And your tests write themselves.
The five EARS patterns
Ubiquitous
Use for: Invariants that are always true, regardless of state or events.
THE SYSTEM SHALL [behavior].THE SYSTEM SHALL encrypt all user data at rest.THE SYSTEM SHALL display the current date in the user's local timezone.THE SYSTEM SHALL log every write operation to the audit table.
Event-driven
Use for: Actions that fire in response to a specific user action or event.
WHEN [trigger], THE SYSTEM SHALL [behavior].WHEN a user clicks "Submit", THE SYSTEM SHALL validate the form and save the entry.WHEN a new comment is posted, THE SYSTEM SHALL notify the thread owner via email.WHEN the file upload completes, THE SYSTEM SHALL generate a thumbnail and display a success toast.
State-driven
Use for: Behavior that's active only while the system is in a particular mode or state.
WHILE [state], THE SYSTEM SHALL [behavior].WHILE the user is editing a draft, THE SYSTEM SHALL auto-save every 30 seconds.WHILE a video is playing, THE SYSTEM SHALL prevent screen dimming.WHILE the user is offline, THE SYSTEM SHALL queue changes locally and display a sync indicator.
Unwanted behavior
Use for: Error cases, edge cases, and graceful degradation.
IF [unwanted condition], THEN THE SYSTEM SHALL [behavior].IF the API returns a 500 error, THEN THE SYSTEM SHALL retry once with exponential backoff and show an error state if the retry fails.IF the user enters a password shorter than 12 characters, THEN THE SYSTEM SHALL prevent submission and show a specific inline error.IF the user session expires mid-action, THEN THE SYSTEM SHALL preserve their input and redirect to the login screen.
This is the pattern most people skip. It's also the one that separates real specs from fantasy specs. Every happy path has at least one unhappy variant. Name it.
Optional
Use for: Behavior that only applies under certain configurations, feature flags, or user tiers.
WHERE [condition or feature], THE SYSTEM SHALL [behavior].WHERE the user is on the Pro tier, THE SYSTEM SHALL allow exports to CSV and PDF.WHERE the feature flag "new_onboarding" is enabled, THE SYSTEM SHALL show the three-step tutorial on first login.WHERE the workspace is on the Enterprise plan, THE SYSTEM SHALL enforce SSO for all members.
How to prompt your AI tool to use EARS
When asking any AI coding tool to generate requirements, add this phrase:
"Write all acceptance criteria in EARS notation. Include at least one event-driven requirement (WHEN…), one unwanted-behavior requirement (IF…, THEN…), and any ubiquitous requirements (THE SYSTEM SHALL…) that matter. Do not use vague words like 'properly', 'appropriately', or 'as expected'."
Paste that at the end of your prompt. You'll get dramatically better output on the first try.
Red-flag words that mean your spec isn't a spec
If you see any of these words in a requirement, rewrite it:
| Word | Why it's a problem |
|---|---|
"properly" | Properly by whose definition? |
"appropriately" | Same. |
"as expected" | Expected by whom? You need to specify. |
"user-friendly" | Not a requirement. An opinion. |
"intuitive" | Untestable. |
"fast" / "quickly" | Specify the number. 1.5s? 200ms? |
"responsive" | Name the breakpoints. |
"secure" | Name the specific security properties. |
"robust" | Name the specific failure modes. |
"scalable" | Name the specific load targets. |
Translation table
| Bad | Good |
|---|---|
| "loads quickly" | "renders within 1.5 seconds on 4G" |
| "handles errors gracefully" | "IF the request fails, THEN THE SYSTEM SHALL show a retry button" |
| "user-friendly interface" | "all interactive elements are reachable within 2 tab stops from the page landing focus" |
| "secure authentication" | "IF a user fails auth 5 times in 10 minutes, THEN THE SYSTEM SHALL lock the account for 15 minutes" |
Use this cheat sheet freely. Print it. Tape it to your monitor. If it helps you ship something, tag @ajbubb on LinkedIn.