Skill: Acceptance Criteria Generation

Purpose

Generate clear, testable acceptance criteria for user stories that define done and enable quality validation.

TDD Context

Acceptance criteria are the foundation for TDD test creation:

Test Type	Written By	Uses AC For
Unit Tests	Senior Developer	Component behavior
Integration Tests	QA Engineer	Component interactions
E2E Tests	QA Engineer	User journey validation

Criteria must be specific enough for test creation - if QA can't write a test from it, it's not specific enough.

When to Use

• User story needs acceptance criteria
• Requirements need to be made testable for TDD
• Vague stories need clarification
• Senior Dev/QA need clear test scenarios

---

Acceptance Criteria Formats

Gherkin (Given-When-Then)

Best for behavior-driven scenarios:

GIVEN [precondition/context]
WHEN [action/trigger]
THEN [expected outcome]
AND [additional outcome]

Example:

GIVEN a registered user is on the login page
WHEN they enter valid credentials and click "Login"
THEN they are redirected to the dashboard
AND they see a "Welcome back" message

Checklist Format

Best for feature validation:

Acceptance Criteria:
- [ ] User can [action]
- [ ] System displays [element]
- [ ] [Constraint] is enforced
- [ ] Error message shown when [error condition]

Example:

Acceptance Criteria:
- [ ] User can enter email address
- [ ] User can enter password (min 8 characters)
- [ ] Password field masks input
- [ ] "Remember me" checkbox available
- [ ] Error shown for invalid credentials
- [ ] Account locks after 5 failed attempts

Rule-Based Format

Best for complex business logic:

**Rule:** [Business rule]
**Scenario:** [Specific case]
**Expected:** [Outcome]

Example:

**Rule:** Discount applies to orders over $100
**Scenario:** Cart total is $150
**Expected:** 10% discount ($15) applied, total shows $135

---

Generation Guidelines

INVEST Criteria for AC

Criterion	Meaning	Validation
Independent	Can be tested in isolation	No hidden dependencies
Negotiable	Open to discussion	Not over-specified
Valuable	Delivers user value	Maps to user need
Estimable	Can be sized	Clear scope
Small	Testable in sprint	Not too broad
Testable	Clear pass/fail	Objective verification

Coverage Areas

For each story, consider AC for:

Area	Questions to Ask
Happy Path	What happens when everything works?
Validation	What inputs need validation? What are the rules?
Errors	What errors can occur? How are they handled?
Edge Cases	What are the boundary conditions?
Security	What authorization is needed?
Performance	Are there response time requirements?
Accessibility	Can all users access this?

---

AC Generation Templates

Feature AC Template

## Story: {{storyTitle}}

### User Flow
**GIVEN** {{precondition}}
**WHEN** {{userAction}}
**THEN** {{expectedResult}}

### Validation Rules
- [ ] {{field1}}: {{validationRule}}
- [ ] {{field2}}: {{validationRule}}

### Error Handling
- [ ] When {{errorCondition1}}, show "{{errorMessage1}}"
- [ ] When {{errorCondition2}}, show "{{errorMessage2}}"

### Edge Cases
- [ ] When {{edgeCase1}}, {{expectedBehavior}}
- [ ] When {{edgeCase2}}, {{expectedBehavior}}

### Non-Functional
- [ ] Response time < {{threshold}}
- [ ] Accessible via keyboard
- [ ] Works on mobile viewports

Form Feature Template

## Story: {{formName}} Form

### Form Fields
| Field | Type | Required | Validation |
|-------|------|----------|------------|
| {{field}} | {{type}} | Yes/No | {{rules}} |

### Submission
**GIVEN** all required fields are valid
**WHEN** user clicks Submit
**THEN** {{expectedOutcome}}
**AND** {{secondaryOutcome}}

### Validation Errors
- [ ] Empty required field shows "{{fieldName}} is required"
- [ ] Invalid {{field}} shows "{{errorMessage}}"
- [ ] Form does not submit until all errors resolved

### Success State
- [ ] Success message displayed
- [ ] Form resets OR redirects to {{destination}}
- [ ] Data persists in {{storage}}

CRUD Feature Template

## Story: {{entityName}} Management

### Create
- [ ] User can create new {{entity}}
- [ ] Required fields: {{requiredFields}}
- [ ] On success: {{successBehavior}}
- [ ] On failure: {{errorBehavior}}

### Read
- [ ] User can view {{entity}} list
- [ ] List shows: {{displayFields}}
- [ ] Pagination: {{paginationRules}}
- [ ] Sorting: {{sortOptions}}

### Update
- [ ] User can edit existing {{entity}}
- [ ] Pre-populated with current values
- [ ] On success: {{successBehavior}}
- [ ] Validation same as Create

### Delete
- [ ] User can delete {{entity}}
- [ ] Confirmation prompt shown
- [ ] Soft delete / Hard delete
- [ ] Cascade behavior: {{cascadeRules}}

API Endpoint Template

## Story: {{endpointName}} API

### Request
- **Method:** {{method}}
- **Path:** {{path}}
- **Auth:** {{authRequirement}}

### Request Body
```json
{{requestSchema}}

Success Response ({{successCode}})

{{successResponse}}

Error Responses

Code	Condition	Response
400	{{condition}}	{{response}}
401	{{condition}}	{{response}}
404	{{condition}}	{{response}}

Validation

• {{field}}: {{validation}}

---

## Common AC Patterns

### Authentication

```markdown
### Login
- [ ] Valid credentials grant access
- [ ] Invalid credentials show error (generic message)
- [ ] Password not visible in URL or logs
- [ ] Session created with appropriate timeout
- [ ] "Remember me" extends session if checked

### Logout
- [ ] Session terminated
- [ ] Redirect to login page
- [ ] Cannot access protected routes after logout

Authorization

### Access Control
- [ ] Only {{role}} can access {{feature}}
- [ ] Unauthorized access shows 403 error
- [ ] No data leakage in error messages
- [ ] UI hides unavailable actions

Data Display

### List Display
- [ ] Empty state shown when no data
- [ ] Loading indicator during fetch
- [ ] Error state with retry option
- [ ] Pagination if > {{threshold}} items
- [ ] Sort by {{defaultSort}} by default

---

Quality Checks

Before finalizing AC:

### AC Quality Checklist

- [ ] **Testable:** Each criterion has clear pass/fail
- [ ] **Complete:** Happy path, errors, and edges covered
- [ ] **Consistent:** Terminology matches project standards
- [ ] **Independent:** No hidden dependencies
- [ ] **Specific:** No ambiguous terms ("fast", "user-friendly")
- [ ] **Measurable:** Numbers where applicable (< 200ms, max 50 chars)

---

Anti-Patterns to Avoid

Anti-Pattern	Problem	Better Approach
"User has good experience"	Subjective, untestable	Specific measurable criteria
"System is fast"	Vague	"Response time < 200ms"
"Handles errors gracefully"	Undefined	List specific error scenarios
"Works on all devices"	Too broad	List specific viewports/browsers
"Secure"	Vague	List specific security requirements

---

Used By Agents

Agent	AC Generation Use
Business Analyst	Primary - generates AC for new stories
Product Owner	Reviews and approves AC
QA Engineer	Validates AC testability, may add edge cases
Senior Developer	Provides technical feasibility input

Best Practices

1. Start with happy path - Then add validations and errors
2. Be specific - Avoid ambiguous language
3. Include numbers - Quantify where possible
4. Think like QA - How would you test this?
5. Collaborate - AC benefits from multiple perspectives
6. Keep it readable - Non-technical stakeholders should understand