AgentSkillsCN

aico-pm-acceptance-criteria

采用 Given/When/Then（Gherkin）格式，定义清晰且可测试的验收标准，这些标准可直接用于测试。 当满足以下条件时，可使用此技能： - 用户要求“验收标准”、“AC”、“测试标准”、“完成标准”； - 用户询问“我们如何知道已经完成？”、“什么才算完成？”； - 用户故事需要可测试的成功条件； - QA 需要测试场景或测试用例； - 执行 /pm.plan，需要为故事添加 AC； - 审查故事时发现 AC 不存在或表述模糊。 格式：始终采用 Given [情境]，When [动作]，Then [预期结果] 的结构。

SKILL.md
--- frontmatter
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

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

markdown
### 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

CategoryExamples
FunctionalFeature works as specified
ValidationInput validation rules
Error handlingError messages and recovery
PerformanceResponse time expectations
AccessibilityA11y 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