Write Acceptance Criteria in Gherkin Format
Generates Given/When/Then acceptance criteria for any user story, including the happy path and at least 3 edge cases. Built for PMs and QA leads preparing stories for sprint commit.
When to use this prompt
Use this when a user story is approved and you need to add acceptance criteria before sprint commit. You will need the story text and ideally a sentence or two of context about the domain. The prompt assumes basic Gherkin syntax; if your team has a custom DSL, you will need to adapt the output. This is particularly useful when engineers push back on thin stories because it forces you to articulate the implicit edge cases you were handwaving. It also makes QA planning dramatically easier because each criterion becomes a test.
The Prompt
You are a BDD-savvy product manager writing acceptance criteria for a user story in Gherkin format. Your job is to cover the happy path, at least 3 edge cases, and explicit error states. User story: {{user_story}} Feature area: {{feature_area}} Known constraints: {{constraints}} Produce the criteria in this exact structure: Feature: {{feature_area}} As a [role] I want [outcome] So that [motivation] Scenario: [Happy path name] Given [initial state] When [user action] Then [expected result] And [any secondary result] Scenario: [Edge case 1] Given ... When ... Then ... Scenario: [Edge case 2] ... Scenario: [Edge case 3] ... Scenario: [Error state] Given ... When ... Then the user sees [specific error message] And [state does not change / partial state is rolled back] Rules: - Keep each line under 15 words. - Scenarios must be independent (no shared state). - Use concrete values where possible (e.g., "$100" not "a large amount"). - Error messages must be specific strings, not generic. - After the scenarios, add a section "EXPLICIT OUT OF SCOPE" listing 2-3 things this story does NOT cover, to prevent scope creep during implementation.
Example Output
Feature: Discount code application
As a shopper
I want to apply a discount code at checkout
So that I get the advertised price
Scenario: Valid single-use code applied successfully
Given the cart total is $100
And the discount code FIRST10 is valid and unused
When the shopper enters FIRST10 and clicks Apply
Then the cart total updates to $90
And a success message "Discount applied" appears
Scenario: Expired discount code rejected
Given the discount code OLD20 expired yesterday
When the shopper enters OLD20 and clicks Apply
Then the cart total remains $100
And the error message "This code has expired" appears
Scenario: Already-used single-use code rejected
Given the shopper used FIRST10 on a previous order
When the shopper enters FIRST10 again
Then the error "Code already used on this account" appears
Scenario: Network failure during validation
Given the discount service is unreachable
When the shopper enters any code
Then the error "Unable to verify code, please retry" appears
And the cart total is unchanged
EXPLICIT OUT OF SCOPE:
- Stacking multiple codes in one order
- Admin UI for creating new codes
- Reporting on code usage Recommended Tools
Jira has native BDD plugin support and the Gherkin output can be wired into Cucumber test runs via the Zephyr or Xray test management tools. Linear stores acceptance criteria in the issue description with markdown formatting that renders the Given/When/Then structure cleanly. ClickUp supports checklist-style acceptance criteria that QA can tick off as they test. All three preserve the explicit out-of-scope section as a reference.
Frequently Asked Questions
When should I use this prompt?
Use it after a user story has been drafted and before it enters sprint commit, ideally during backlog refinement. Running it earlier (during discovery) leads to over-specification of ideas that may never ship; running it later (after sprint starts) is too late to catch scope issues. If your team has a test-first culture and engineers write their own BDD scenarios, this prompt is redundant for them but still useful for QA handoff documentation.
What if my team does not use BDD?
You can still use the Given/When/Then structure without adopting full BDD tooling. The output becomes a manual test plan QA can execute. If you prefer checklist-style acceptance criteria, ask the model to reformat the scenarios as bulleted pass/fail items. The structural discipline (happy path plus 3 edge cases plus error states plus explicit out-of-scope) is the valuable part; the Gherkin syntax is optional decoration you can swap out freely.