---
title: "Acceptance Criteria"
description: "Generates structured Given/When/Then acceptance criteria for a user story or feature slice. Use when translating product requirements into testable scenarios that cover the happy path, edge cases, error states, and non-functional expectations for engineering handoff and QA."
generated: true
source: scripts/generate-skill-pages.py
tags:
  - Deliver
  - specification
---

:::note[Quick facts]
**Phase:** Deliver | **Version:** 1.0.0 | **Category:** specification | **License:** Apache-2.0
:::

**Try it:** `/acceptance-criteria "Your context here"`

Acceptance criteria define the observable behavior that must be true for a story or feature to be considered done. This skill turns feature context into concise, testable Given/When/Then scenarios that engineers and QA can verify without guessing intent.

## When to Use

- After a user story, PRD section, or feature slice is defined
- When a team needs clear pass/fail conditions for implementation
- When writing QA-ready criteria for sprint planning or handoff
- When a story has edge cases, error paths, or non-functional expectations that should be explicit

## How to Use

Use the `/acceptance-criteria` slash command:

```
/acceptance-criteria "Your context here"
```

Or reference the skill file directly: `skills/deliver-acceptance-criteria/SKILL.md`

## Instructions

When asked to create acceptance criteria, follow these steps:

1. **Confirm the story or feature scope**
   Identify the exact slice of work. If the scope is unclear, ask for the user story, PRD section, or feature description before drafting criteria.

2. **Separate the happy path from exceptions**
   Start with the primary success flow, then add edge cases and error states that are likely or costly if missed.

3. **Write each criterion as an observable scenario**
   Use Given/When/Then language only. Keep each criterion independently testable and avoid implementation details.

4. **Cover recovery and failure behavior**
   Describe what the user sees or can do when validation fails, a dependency is unavailable, or a save action cannot complete.

5. **Include non-functional expectations**
   Add criteria for performance, accessibility, security, reliability, or auditability when they matter to the story.

6. **Avoid duplication and overlap**
   Each criterion should test one outcome. If two criteria describe the same behavior, merge or split them until the intent is clear.

7. **Review for testability**
   Ensure a reviewer can pass or fail each criterion without interpretation. If a statement is subjective, rewrite it into a measurable outcome.

## Output Template

# Acceptance Criteria: [Feature or Story Title]

## Story Context

<!-- Briefly restate the story, feature slice, or PRD section this criteria set supports. -->

[Describe the user need, scope boundary, and any assumptions that matter for testing.]

## Happy Path

<!-- Capture the primary success flow first. Each criterion should be independently testable. -->

### AC-1: [Happy Path Title]

**Given** [initial context or precondition]

**When** [user action or trigger]

**Then** [expected observable outcome]

### AC-2: [Happy Path Title]

**Given** [initial context or precondition]

**When** [user action or trigger]

**Then** [expected observable outcome]

## Edge Cases

<!-- Document boundary conditions and alternate inputs that should still behave correctly. -->

### AC-3: [Edge Case Title]

**Given** [boundary condition or alternate state]

**When** [user action or trigger]

**Then** [expected observable outcome]

## Error States

<!-- Describe failures, validation issues, and dependency problems with recovery behavior. -->

### AC-4: [Error State Title]

**Given** [failure condition]

**When** [user action or trigger]

**Then** [expected observable outcome and recovery path]

## Non-Functional Criteria

<!-- Capture performance, accessibility, security, reliability, or audit requirements. -->

### AC-5: [Non-Functional Title]

**Given** [relevant system or user context]

**When** [measurement or action]

**Then** [expected measurable constraint or guarantee]

## Notes

- [Assumption or dependency]
- [Open question if the source story is incomplete]

## Example Output

<details>
<summary>Acceptance Criteria: Guest Checkout</summary>

# Acceptance Criteria: Guest Checkout

This example describes the acceptance criteria for a guest checkout flow that lets shoppers buy items without creating an account.

## Story Context

The checkout experience must let a shopper complete an order as a guest, enter shipping and payment details, and receive a confirmation after payment succeeds. The criteria below focus on the behavior a reviewer can observe in the UI and system responses.

## Happy Path

### AC-1: Guest Checkout Form Loads

**Given** I have items in my cart and I am not signed in

**When** I open the checkout page

**Then** I can enter shipping information, delivery method, and payment details without being prompted to create an account

### AC-2: Order Completes Successfully

**Given** I have entered valid shipping and payment details

**When** I submit the order

**Then** I see an order confirmation page with an order number and estimated delivery date

## Edge Cases

### AC-3: Promo Code Can Be Applied

**Given** I am on checkout and my cart qualifies for a discount

**When** I enter a valid promo code and apply it

**Then** the order summary updates to show the discount before I submit payment

### AC-4: Shipping Address Validation Supports International Formats

**Given** I enter a shipping address for a supported non-US destination

**When** I continue to the next step

**Then** the form accepts the address if it matches the country-specific validation rules

## Error States

### AC-5: Invalid Card Is Rejected

**Given** I have entered shipping information but the payment card is invalid

**When** I attempt to place the order

**Then** I see a clear inline error message and the order is not created

### AC-6: Inventory Changes During Checkout

**Given** an item in my cart becomes out of stock before I submit payment

**When** I place the order

**Then** I am shown which item failed, my cart remains available, and I can remove the item or choose a different variant

## Non-Functional Criteria

### AC-7: Checkout Responds Within the Performance Budget

**Given** I submit a valid order during normal operating conditions

**When** the checkout request is processed

**Then** the confirmation response is returned within 3 seconds for at least 95 percent of requests

### AC-8: Checkout Errors Are Accessible

**Given** a validation or payment error occurs

**When** the error message is shown

**Then** the message is announced by screen readers and the field with the error receives focus when applicable

## Notes

- Payment processor and inventory service availability are external dependencies.
- Fraud review and manual review flows are out of scope for this example.

</details>

## Real-World Examples

See this skill applied to three different product contexts:

<details>
<summary>Storevine (B2B): Storevine B2B ecommerce platform . acceptance criteria for the Campaigns email template builder</summary>

**Prompt:**

```
/acceptance-criteria

Feature: Campaigns . email template builder
The template builder lets merchants drag-and-drop content blocks (text, image, button, divider, product card) onto a canvas, customize styling, preview on desktop and mobile, and save templates for reuse across campaigns. Templates are stored per-merchant and can be duplicated.
```

---

**Output:**

---
artifact: acceptance-criteria
version: "1.0"
created: 2026-04-11
status: draft
---

# Acceptance Criteria: Campaigns Email Template Builder

</details>

## Quality Checklist

Before finalizing, verify:

- [ ] The criteria map to a specific story or feature slice
- [ ] The happy path is covered first
- [ ] Edge cases are explicit, not implied
- [ ] Error states include user-visible recovery behavior
- [ ] Non-functional criteria are included when relevant
- [ ] Each criterion is testable and has one clear outcome
- [ ] No implementation details leak into the acceptance criteria

## Output Contract

Use `references/TEMPLATE.md` as the output format. A complete response should:

- Restate the feature or story context
- Group criteria into happy path, edge cases, error states, and non-functional criteria
- Use explicit Given/When/Then statements for each criterion
- Note assumptions or open questions when context is incomplete
