home / skills / masanao-ohba / claude-manifests / 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-criteriaReview the files below or copy the command above to add this skill to your agents.
---
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"
```
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.
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.
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.