Acceptance criteria fall apart the moment a ticket says “user can log in” with no spec for what success, failure, slow network, or expired session look like. QA invents its own coverage, engineering ships half the edge cases, and the bug ledger grows. The 12 prompts below force testability per line, separate happy from negative from non-functional, and produce AC that survive a sprint-planning challenge. For the upstream user story this AC sits under, pair these with the MVP scope prompts so you don’t write criteria for features that shouldn’t ship yet.
TL;DR: Paste your story into prompt 1 for a Given/When/Then draft, run prompts 2-4 to widen edge, negative, and non-functional coverage, then run prompt 7 to pressure-test every line for “can QA write a test from this, yes or no.” Keep stories to 1-3 acceptance criteria; if you need four or more, the story is too big and should be split.
Best for
- PRDs and user stories
- Sprint planning and backlog grooming
- QA test plans and AC-to-test mapping
- Cross-team contracts
- Bug-fix tickets
Two formats, and when to use each
Before you prompt, decide on a format so the AI doesn’t mix them inside one story:
- Scenario-oriented (Given/When/Then): best when behavior depends on state and user action — login, checkout, multi-step flows. Each scenario is self-contained and maps one-to-one onto a test case.
- Rules-oriented (bullet list of rules): best for UI/UX constraints, validation rules, and config that don’t fit a behavioral scenario — “password must be 12+ chars,” “table sorts by date descending by default.”
A useful discipline from agile testing practice: write each criterion so a tester can mark it Pass or Fail with no interpretation, and avoid negation (“system does not allow X”) where you can — negative conditions are slow and ambiguous to verify, so restate them as a positive expected behavior.
How to run these prompts
These are model-agnostic. Any current frontier model handles AC well; for product work as of June 2026, GPT-5.5 (Thinking), Claude Sonnet 4.6, and Gemini 3.1 Pro all produce clean Given/When/Then output. Paste the real story and field list — vague input yields vague AC regardless of model. For deeper reasoning on a gnarly multi-team contract (prompt 11), GPT-5.5 Pro or Claude Opus 4.7 are worth the extra latency. Replace every [bracketed] placeholder with your actual content.
1. Given/When/Then AC writer
For user story [paste], write acceptance criteria in Given/When/Then format. Cover: 1 happy path, 2 edge cases, 1 negative case, 1 non-functional (performance / accessibility / security). Each AC must be independently testable. If the story needs more than 3 criteria, tell me it should be split and propose the split.2. Edge-case generator
Below is a feature description. List 10 edge cases that AC should cover: boundary inputs, empty states, very large inputs, concurrent users, slow network, denied permissions, expired sessions, race conditions.
[paste]3. Negative-case AC
For feature [paste], generate 8 negative AC: what happens when input is invalid, user is unauthorized, server fails, rate limit hit, validation fails, payment fails, dependent service down, user data missing.4. Non-functional AC
For feature [paste], write 5 non-functional AC: performance budget (state a number, e.g. p95 < 300ms), accessibility level (e.g. WCAG 2.2 AA), security/permission rules, error-logging, observability (what gets logged when it fails).5. AC for a complex form
For form [paste form fields], write AC covering: required-field validation, format validation, async validation, error states, success state, partial-save, autosave, accessibility submission via keyboard.6. AC for an integration
For integration with [3rd party API], write AC covering: happy path, rate-limit handling, auth failure, partial response, retry logic, idempotency, observable failures.7. AC vagueness pressure-test
Below are my draft AC. For each, ask: can QA write a test directly from this, yes or no? If no, rewrite to make it testable. Flag any "should" / "could" / "if needed" / "as appropriate", and flag any criterion phrased as a negation that could be restated positively.
[paste AC]8. AC for accessibility
For feature [paste], write 6 accessibility AC against WCAG 2.2 AA: keyboard nav, screen-reader announcement, focus management, color-contrast ratio, ARIA roles, error announcement.9. AC for a multi-step flow
For multi-step flow [paste steps], write AC covering: state per step, back-button behavior, partial-completion save, validation per step, abandonment recovery.10. AC to test-case mapping
Below are AC. Below are existing test cases. Map AC to test cases. Flag uncovered AC and tests not tied to any AC. Suggest new tests where gaps exist.
[paste both]11. Cross-team AC contract
My team and [other team] share a feature. Write AC as a contract: who owns each AC, what handoff signal closes each, what happens when one side's AC is not met.12. AC for a bug-fix ticket
For bug [paste], write AC the fix must satisfy: the original bug no longer reproduces, no regression in related flows, the fix has a test, the failure mode is logged.Common mistakes
- Vague AC (“user can log in”) that QA cannot translate into a single deterministic test.
- Only happy path — no negative, no boundary, no concurrency, no expired session.
- Skipping non-functional AC (performance budget, a11y level, error-logging) until it’s too late to fit them.
- Two AC that conflict (e.g., “submit disabled until valid” plus “show inline errors on submit”).
- AC written after the feature is built — they describe what shipped, not what should ship.
- Cramming 6+ criteria into one story instead of splitting it; the criteria stop being independently testable.
- Reusing one AC template across stories without tailoring to that flow’s actual failure modes.
FAQ
How many acceptance criteria should one user story have? Aim for 1 to 3. Most well-sized stories land in that range; if you find yourself writing four or more, that is usually a signal the story is too large and should be split into smaller, independently shippable stories.
Should acceptance criteria use Given/When/Then or a bullet list? Use Given/When/Then when behavior depends on state and a user action (login, checkout, a multi-step wizard). Use a rules-oriented bullet list for validation rules, UI constraints, and config that don’t map onto a behavioral scenario. Don’t mix both styles inside a single criterion.
Who should write acceptance criteria, and when? Write them collaboratively before development — product, engineering, and QA together during backlog grooming or sprint planning. AC written after the code is built describe what shipped, not what should ship, and that’s where rework comes from.
Can I trust an AI to write final acceptance criteria? Treat the model’s output as a fast first draft, not the contract. It is genuinely good at widening coverage you’d otherwise miss (concurrency, expired sessions, rate limits), but it will also invent plausible-sounding criteria that don’t match your system. Always run prompt 7 to pressure-test testability, then have a human owner sign off before the story enters the sprint.
What’s the difference between acceptance criteria and test cases? Acceptance criteria define the conditions a story must meet to be “done”; test cases are the concrete steps that verify each criterion. One criterion usually expands into several test cases. Prompt 10 maps the two and flags any AC with no test and any test with no AC.
Related
- PRD draft prompts
- User story prompts
- Feature prioritization prompts
- MVP scope prompts
- Test generation prompts
- Pricing Hypothesis Prompts for Freemium, Tiers and Anchors
- Help Center FAQ Prompts for Product Support
External references: altexsoft on acceptance criteria formats and best practices and TestRail on acceptance criteria in agile testing.
Tags: #Prompt #Product startup #PRD