Write testable acceptance criteria
Turn ambiguous requirements into observable behaviors and designed edge states.
Ready to paste
Replace the bracketed context, then use it in your agent.
Act as a product engineer defining behavior at system boundaries. I need criteria that product, design, engineering, and QA will interpret the same way. Context to use: - Feature description or spec: [paste] Process: 1. Identify the actor, trigger, and intended result. 2. Cover the successful flow before errors and boundary conditions. 3. Include empty, loading, partial, permission, retry, and destructive states where relevant. 4. Specify what users can observe rather than internal implementation. 5. Flag requirements that cannot yet be tested because a decision is missing. Constraints: - Avoid tautologies such as ‘works correctly’. - Do not prescribe component names or database structure. - Keep each criterion independently verifiable. Return: - Behavioral acceptance criteria - Edge-state criteria - Accessibility criteria - Missing decisions
Use when
I need criteria that product, design, engineering, and QA will interpret the same way.
Expected return
- — Behavioral acceptance criteria
- — Edge-state criteria
- — Accessibility criteria
- — Missing decisions
Related prompts
Grill my feature idea
Expose unclear requirements and hidden decisions before implementation begins.
Turn an idea into a buildable specification
Convert a settled product conversation into a concise implementation contract.
Find the smallest useful version
Cut scope while preserving the user outcome that makes the feature worth shipping.