Claude-skill-registry acceptance-criteria-authoring
Write clear, testable acceptance criteria in Given-When-Then format following INVEST principles and BDD best practices.
install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/acceptance-criteria-authoring" ~/.claude/skills/majiayu000-claude-skill-registry-acceptance-criteria-authoring && rm -rf "$T"
manifest:
skills/data/acceptance-criteria-authoring/SKILL.mdsource content
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
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")
- Combine multiple behaviors in one scenario
- Skip error handling scenarios
Example: E-commerce Checkout
User Story
As a registered customer I want to checkout with a saved payment method So that I can complete purchases quickly
Acceptance Criteria
Feature: Checkout with Saved Payment Background: Given I am logged in as a registered customer And I have a saved Visa card ending in 4242 Scenario: Successful checkout with saved card Given I have items in my cart totaling $50.00 When I proceed to checkout And I select my saved Visa card And I click "Place Order" Then I see an order confirmation page And I receive a confirmation email And my card is charged $50.00 Scenario: Checkout with expired saved card Given my saved card has expired And I have items in my cart When I proceed to checkout And I select my expired card Then I see a message "This card has expired" And I am prompted to update the card or add a new one Scenario: Checkout when card is declined Given I have items in my cart When I proceed to checkout And I select my saved card And I click "Place Order" And the payment is declined Then I see a message "Payment declined. Please try another payment method." And the order is not created And my cart is preserved Scenario: Checkout with insufficient inventory Given I have 3 units of "Widget X" in my cart And only 2 units are in stock When I proceed to checkout Then I see a message "Widget X: Only 2 available" And I am prompted to update quantity
Scenario Patterns
Happy Path
Scenario: User successfully [action] Given [valid preconditions] When [correct action] Then [expected positive outcome]
Error Handling
Scenario: [Action] fails due to [reason] Given [preconditions that lead to failure] When [action that will fail] Then [appropriate error message] And [system state is preserved/recovered]
Edge Cases
Scenario: [Action] with boundary condition Given [boundary condition setup] When [action at boundary] Then [expected behavior at boundary]
Security
Scenario: Unauthorized user attempts [action] Given I am not logged in When I try to access [protected resource] Then I am redirected to login page And I see "Please log in to continue"
Scenario Outlines
Use for testing multiple data variations:
Scenario Outline: Discount applied based on order value Given I have items in my cart totaling <order_total> When I proceed to checkout Then I see a discount of <discount> And my final total is <final_total> Examples: | order_total | discount | final_total | | $50.00 | $0.00 | $50.00 | | $100.00 | $5.00 | $95.00 | | $200.00 | $20.00 | $180.00 |
.NET SpecFlow Example
[Binding] public class CheckoutSteps { private readonly CheckoutContext _context; public CheckoutSteps(CheckoutContext context) { _context = context; } [Given(@"I am logged in as a registered customer")] public void GivenIAmLoggedInAsARegisteredCustomer() { _context.Customer = TestCustomers.CreateRegistered(); _context.Session = _context.AuthService.Login(_context.Customer); } [Given(@"I have items in my cart totaling \$(.*)")] public void GivenIHaveItemsInMyCartTotaling(decimal total) { _context.Cart = TestCart.WithTotal(total); } [When(@"I click ""(.*)""")] public void WhenIClick(string button) { _context.Result = _context.CheckoutPage.Click(button); } [Then(@"I see an order confirmation page")] public void ThenISeeAnOrderConfirmationPage() { Assert.IsType<OrderConfirmationPage>(_context.Result); } [Then(@"I receive a confirmation email")] public void ThenIReceiveAConfirmationEmail() { var emails = _context.EmailService.GetEmailsFor(_context.Customer.Email); Assert.Contains(emails, e => e.Subject.Contains("Order Confirmation")); } }
Coverage Checklist
For each user story, ensure coverage of:
- Happy path: Main success scenario
- Validation errors: Invalid input handling
- Business rule violations: Domain constraint failures
- Authorization failures: Access control
- External service failures: Third-party integration errors
- Boundary conditions: Min/max values, empty states
- Concurrency: Multiple users, race conditions
- State transitions: Valid and invalid state changes
Acceptance Criteria Template
## User Story As a [role] I want to [action] So that [benefit] ## Acceptance Criteria ### Scenario 1: [Happy path description] Given [precondition] When [action] Then [expected outcome] ### Scenario 2: [Error case description] Given [error-inducing condition] When [action] Then [error handling behavior] ### Scenario 3: [Edge case description] Given [edge condition] When [action] Then [boundary behavior] ## Out of Scope - [Explicitly excluded scenarios] ## Notes - [Implementation hints or business context]
Integration Points
Inputs from:
- Requirements → Story context
skill → Job stepsjtbd-analysis
skill → Test techniquestest-case-design
Outputs to:
- SpecFlow/Cucumber automation
skill → Acceptance test scopetest-strategy-planning- Definition of Done