Acceptance criteria collapse the moment a ticket says “user can log in” with no spec for what success, failure, slow network, or expired session actually look like — QA invents their own coverage, engineering ships half the edge cases, and the bug ledger grows. These prompts 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 will sit under, pair with the MVP scope prompts so you don’t write criteria for features that shouldn’t ship yet.
Best for
- PRDs and user stories
- Sprint planning
- QA test plans
- Cross-team contracts
- Bug-fix tickets
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.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, accessibility level, 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? If no, rewrite to make it testable. Flag any "should" / "could" / "if needed".
{paste AC}8. AC for accessibility
For feature {paste}, write 6 accessibility AC: keyboard nav, screen-reader announcement, focus management, color-contrast, 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 ↔ 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
- Reusing the same AC template across stories without tailoring to that flow’s actual failure modes
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
Tags: #Prompt #Product startup #PRD