| name | aico-pm-acceptance-criteria |
| description | Define clear, testable acceptance criteria using Given/When/Then (Gherkin) format that can be directly used for testing.
Use this skill when:
- User asks for "acceptance criteria", "AC", "test criteria", "done criteria"
- User asks "how do we know it's done?", "what counts as complete?"
- User story needs testable success conditions
- QA needs test scenarios or test cases
- Running /pm.plan and need to add AC to stories
- Reviewing story and AC is missing or vague
Format: Always use Given [context], When [action], Then [expected result] structure.
|
Acceptance Criteria
⚠️ CRITICAL RULES - READ FIRST
- READ STORY FIRST: Always read the story file from
docs/reference/pm/stories/ before writing criteria
- USE GIVEN/WHEN/THEN: All criteria must follow this format
- UPDATE STORY FILE: Add criteria to existing story file, don't create new files
Language Configuration
Before generating any content, check aico.json in project root for language field to determine the output language. If not set, default to English.
Process
- Review story/feature: Understand what needs to be done
- Identify success scenarios: Happy paths first
- Write Given/When/Then: For each scenario
- Add edge cases: Boundary conditions and errors
- Verify testability: Each criterion must be independently verifiable
Acceptance Criteria Template
### Acceptance Criteria for [Story/Feature]
#### Scenario 1: [Scenario Name]
- **Given** [precondition/context]
- **When** [action/trigger]
- **Then** [expected outcome]
#### Scenario 2: [Scenario Name]
- **Given** [precondition/context]
- **When** [action/trigger]
- **Then** [expected outcome]
#### Edge Cases
- **Given** [edge case condition]
- **When** [action]
- **Then** [expected behavior]
Criteria Categories
| Category | Examples |
|---|
| Functional | Feature works as specified |
| Validation | Input validation rules |
| Error handling | Error messages and recovery |
| Performance | Response time expectations |
| Accessibility | A11y requirements |
Quality Checklist
Key Rules
- ALWAYS use Given/When/Then structure
- MUST make each criterion independently testable
- ALWAYS include edge cases and error scenarios
- NEVER use vague language - be specific
Common Mistakes
- ❌ Vague criteria ("works correctly") → ✅ Specific conditions
- ❌ Missing edge cases → ✅ Include boundary conditions
- ❌ Implementation details → ✅ Focus on observable behavior
