返回 Skill 列表
extension
分类: 开发与工程无需 API Key

aico-pm-acceptance-criteria

定义清晰、可测试的验收标准,使用Given/When/Then(Gherkin)格式,可以直接用于测试。在以下情况下使用此技能:- 用户询问“验收标准”、“AC”、“测试标准”、“完成标准”- 用户问“我们怎么知道它完成了?”、“什么算作完成?”- 用户故事需要可测试的成功条件- QA需要测试场景或测试用例- 运行/pm.plan并需要向故事中添加AC- 审查故事时发现AC缺失或模糊格式:始终使用Given [上下文],When [动作],Then [预期结果]的结构。

person作者: jakexiaohubgithub

Acceptance Criteria

⚠️ CRITICAL RULES - READ FIRST

  1. READ STORY FIRST: Always read the story file from docs/reference/pm/stories/ before writing criteria
  2. USE GIVEN/WHEN/THEN: All criteria must follow this format
  3. 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

  1. Review story/feature: Understand what needs to be done
  2. Identify success scenarios: Happy paths first
  3. Write Given/When/Then: For each scenario
  4. Add edge cases: Boundary conditions and errors
  5. 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

  • [ ] Each criterion is independently testable
  • [ ] No ambiguous language ("should", "might", "could")
  • [ ] Edge cases are covered
  • [ ] Error states are defined
  • [ ] Performance expectations stated (if relevant)

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