acceptance-criteria-authoring

# Acceptance Criteria Authoring

## When to Use This Skill

Use this skill when:

- **Acceptance Criteria Authoring tasks** - Working on write clear, testable acceptance criteria in given-when-then format following invest principles and bdd best practices
- **Planning or design** - Need guidance on Acceptance Criteria Authoring approaches
- **Best practices** - Want to follow established patterns and standards

## Overview

Acceptance criteria define the conditions that must be met for a user story to be considered complete. Well-written acceptance criteria enable clear communication between stakeholders and drive automated acceptance tests.

## Given-When-Then Format

```gherkin
Given [precondition/context]
When [action/event]
Then [expected outcome]
```

### Components

| Component | Purpose | Example |
|-----------|---------|---------|
| **Given** | Set up initial context | "Given a logged-in premium user" |
| **When** | Trigger action/event | "When they click 'Download Report'" |
| **Then** | Assert expected outcome | "Then a PDF report downloads" |
| **And** | Chain multiple conditions | "And the report includes all orders" |
| **But** | Negative assertion | "But archived orders are excluded" |

## INVEST Principles for User Stories

| Letter | Principle | Description |
|--------|-----------|-------------|
| **I** | Independent | Can be developed in any order |
| **N** | Negotiable | Details can be discussed |
| **V** | Valuable | Delivers user/business value |
| **E** | Estimable | Can be sized by team |
| **S** | Small | Fits in one sprint |
| **T** | Testable | Has clear acceptance criteria |

## Acceptance Criteria Best Practices

### Do ✅

- Use business language, not technical jargon
- Be specific and measurable
- Include happy path and edge cases
- Keep scenarios focused and atomic
- Write from user perspective
- Include error scenarios

### Don't ❌

- Include implementation details
- Make criteria too broad
- Use ambiguous terms ("fast", "user-friendly"