Claude Code Plugins

Community-maintained marketplace

Feedback

acceptance-criteria-authoring

@melodic-software/claude-code-plugins
3
0

Write clear, testable acceptance criteria in Given-When-Then format following INVEST principles and BDD best practices.

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name acceptance-criteria-authoring
description Write clear, testable acceptance criteria in Given-When-Then format following INVEST principles and BDD best practices.
allowed-tools Read, Write, Glob, Grep, Task

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
  • jtbd-analysis skill → Job steps
  • test-case-design skill → Test techniques

Outputs to:

  • SpecFlow/Cucumber automation
  • test-strategy-planning skill → Acceptance test scope
  • Definition of Done