home / skills / masanao-ohba / claude-manifests / acceptance-criteria

acceptance-criteria skill

/skills/generic/acceptance-criteria

This skill defines clear, measurable acceptance criteria using SMART and Given-When-Then formats to guide verification and validation.

npx playbooks add skill masanao-ohba/claude-manifests --skill acceptance-criteria

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.2 KB
---
name: acceptance-criteria
description: Defines measurable acceptance criteria using SMART principles and Given-When-Then format
---

# Acceptance Criteria

A technology-agnostic skill for defining clear, measurable acceptance criteria.

## Core Purpose

Transform requirements into verifiable acceptance criteria that:
- Are specific and unambiguous
- Can be objectively measured
- Guide implementation
- Enable evaluation

## Acceptance Criteria Format

### Given-When-Then (GWT)

```yaml
format: given_when_then
structure:
  given: "Initial context or precondition"
  when: "Action or trigger"
  then: "Expected outcome or result"

example:
  given: "User is logged in with valid credentials"
  when: "User clicks the 'Export' button"
  then: "System generates a CSV file with all user data"
```

### SMART Criteria

```yaml
specific:
  definition: "Clear and unambiguous"
  bad: "System should be fast"
  good: "API response time under 200ms for 95% of requests"

measurable:
  definition: "Quantifiable outcome"
  bad: "Good test coverage"
  good: "Test coverage >= 80%"

achievable:
  definition: "Technically feasible"
  check: "Can this be implemented with current resources?"

relevant:
  definition: "Aligned with business goals"
  check: "Does this contribute to user value?"

time_bound:
  definition: "Has clear completion point"
  check: "When is this considered done?"
```

## Criteria Categories

### Functional Criteria

```yaml
type: functional
focus: "What the system must do"

templates:
  - "User can [action] to [achieve outcome]"
  - "System [processes/calculates/displays] [data] when [trigger]"
  - "Given [state], when [action], then [result]"

examples:
  - criteria: "User can reset password via email"
    given: "User has registered email"
    when: "User requests password reset"
    then: "Reset link sent within 5 minutes"
```

### Non-Functional Criteria

```yaml
type: non_functional
focus: "How the system should perform"

categories:
  performance:
    - "Response time < 200ms"
    - "Supports 1000 concurrent users"

  security:
    - "All passwords hashed with bcrypt"
    - "No SQL injection vulnerabilities"

  reliability:
    - "99.9% uptime"
    - "Automatic failover within 30s"

  usability:
    - "Form can be completed in < 2 minutes"
    - "Error messages are descriptive"
```

### Quality Criteria

```yaml
type: quality
focus: "Code and implementation standards"

categories:
  code_standards:
    - "No linting errors"
    - "All functions documented"

  test_coverage:
    - "Unit test coverage >= 80%"
    - "All edge cases tested"

  maintainability:
    - "Cyclomatic complexity < 10"
    - "No duplicate code blocks"
```

## Criteria Generation Process

### Step 1: Extract Requirements

```yaml
from_user_request:
  - Identify explicit requirements
  - Infer implicit requirements
  - Note constraints

from_goals:
  - Map achievement indicators to criteria
  - Define verification methods
```

### Step 2: Transform to Criteria

```yaml
for_each_requirement:
  - Define specific outcome
  - Add measurable threshold
  - Specify verification method
  - Assign priority
```

### Step 3: Validate Criteria

```yaml
validation_checklist:
  - [ ] Is it specific enough to implement?
  - [ ] Can it be objectively measured?
  - [ ] Is it achievable with current resources?
  - [ ] Does it align with user value?
  - [ ] Is the scope bounded?
```

## Output Format

```yaml
acceptance_criteria:
  functional:
    - id: "AC-FUNC-001"
      description: "User login functionality"
      given: "User has valid credentials"
      when: "User submits login form"
      then: "User is authenticated and redirected to dashboard"
      priority: must
      verification: "Integration test"

  non_functional:
    - id: "AC-PERF-001"
      description: "Login response time"
      criterion: "Login completes within 2 seconds"
      threshold: "< 2000ms"
      priority: should
      verification: "Load test"

  quality:
    - id: "AC-QUAL-001"
      description: "Code coverage"
      criterion: "Test coverage for auth module"
      threshold: ">= 80%"
      priority: must
      verification: "Coverage report"
```

## Integration

### Used By Agents

```yaml
primary_users:
  - goal-clarifier: "Criteria generation"

secondary_users:
  - deliverable-evaluator: "Evaluation reference"
```

Overview

This skill defines clear, measurable acceptance criteria using SMART principles and Given-When-Then structure. It converts requirements into testable, technology-agnostic criteria that guide implementation and verification. The output includes functional, non-functional, and quality criteria with priorities and verification methods.

How this skill works

It extracts explicit and implicit requirements, maps goals to measurable indicators, and transforms each requirement into a specific outcome with thresholds and verification steps. Criteria are expressed in Given-When-Then for behavioral cases and annotated with SMART attributes (Specific, Measurable, Achievable, Relevant, Time-bound). A validation checklist ensures each criterion is implementable and verifiable.

When to use it

  • Defining acceptance for user stories or features before development
  • Converting high-level goals into measurable delivery requirements
  • Creating testable criteria for QA and automation teams
  • Specifying non-functional requirements like performance or security
  • Establishing quality gates for code and test coverage

Best practices

  • Start by extracting explicit requirements and inferring implicit needs
  • Write each acceptance criterion in Given-When-Then for behavioral clarity
  • Apply SMART checks: add measurable thresholds and verification methods
  • Assign priority (must/should/could) and a concrete verification type (unit test, load test, manual test)
  • Validate criteria against a checklist: specific, measurable, achievable, relevant, bounded

Example use cases

  • Functional: 'Given user has registered email, when user requests password reset, then reset link sent within 5 minutes'
  • Performance: 'Login completes within 2 seconds under normal load; verify with load test'
  • Security: 'All passwords hashed with bcrypt; verify via security audit'
  • Quality: 'Unit test coverage >= 80% for auth module; verify with coverage report'
  • Release gating: criteria used by deliverable-evaluator agent to decide production readiness

FAQ

How do I make acceptance criteria measurable?

Attach numeric thresholds or pass/fail checks (e.g., response time < 200ms, test coverage >= 80%) and specify the verification method.

When should I use Given-When-Then vs SMART?

Use Given-When-Then for behavioral, scenario-driven criteria; use SMART to ensure each criterion is specific, measurable, achievable, relevant, and time-bound. Combine both for best results.