SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsacceptance-criteria

acceptance-criteria

Testing & quality

View repository

Updated 10-16 00:04

About this skill

Acceptance Criteria Skill

Scope: REQUIREMENTS

Version: 0.1.0 (placeholder) | Creation Date: 2025-11-27

Overview

Acceptance Criteria (AC) define the completion criteria for a User Story:

┌─────────────────────────────────────────────────────┐
│              ✓ Acceptance Criteria (GWT)           │
├─────────────────────────────────────────────────────┤
│  Given [precondition/context]                      │
│  When [action/trigger]                             │
│  Then [expected outcome]                           │
└─────────────────────────────────────────────────────┘

Quick Start

The fastest 3-step usage process:

  • Step 1: Confirm that an AC document already exists

    • File location:spec/requirements/acceptance_criteria.md(or other .md files)
    • Format requirement: each AC contains a Given-When-Then three-part structure
    • Quantity suggestion: at least 2-3 ACs (more can be checked)

  • Step 2: One-click invocation check

    • Command:>>ac_format_check or >>ac_coverage
    • AI will automatically scan all ACs and check format and coverage
    • Check content: completeness of the three GWT elements + coverage of normal/boundary/exception scenarios
    • ⚠️ Read-only check: will not modify your AC document

  • Step 3: View the check report

    • Result display: the complete report is displayed directly in the conversation window
    • Report content: format check for each AC + coverage score + improvement suggestions
    • Follow-up action: manually modify the ACs based on the report and supplement omitted scenarios

⏱️ Estimated time: 2-3 minutes / 10 ACs

🆘 Encountering problems? See the "GWT Format Check" section below for detailed guidance

GWT Format Check

Given (preconditions)

  • Does it clearly describe the initial state
  • Does it include the necessary context
  • Is it reproducible

When (trigger action)

  • Does it describe a specific operation
  • Is it single and clear
  • Is it a user or system behavior

Then (expected result)

  • Is it observable and verifiable
  • Does it have clear success criteria
  • Does it cover normal and exception scenarios

Coverage Check

  • Does it cover the normal flow (Happy Path)
  • Does it cover boundary conditions
  • Does it cover error scenarios
  • Is the number of ACs for each US reasonable (3-7)

Tiered Check Strategy

L1-STREAMLINED

  • Check whether the three GWT elements are complete
  • Quick format verification (< 5 minutes/AC)
  • Pass criteria: 2 of 3 items pass (≥67%)

L2-BALANCED

  • Check 2-3 key points for each element (6-9 items in total)
  • Includes coverage check (Happy Path + Error)
  • Pass criteria: 5 of 6 items pass (≥83%)

L3-RIGOROUS

  • Comprehensively check all sub-items (12+ items)
  • Includes full coverage of boundary conditions and exception scenarios
  • Generate a coverage matrix
  • Pass criteria: 11 of 12 items pass (≥91.7%)

Limitations

✅ Applicable scenarios

  • An AC document already exists and conforms to the basic Given-When-Then format
  • AC quality needs to be reviewed (format check, coverage assessment)
  • Before preparing test cases, ensure the AC is clear and testable
  • Need to discover missed scenarios (boundary conditions, exceptional cases)
  • When team members review AC with each other, use as a standardized checklist

❌ Not Applicable Scenarios

  • No AC document at all → First use ac_generate to generate an AC skeleton from the US
  • AC format is completely wrong (missing Given-When-Then structure) → First fix the basic format
  • Need to automatically fix the AC rather than only check it → This SKILL only generates a report, it does not fix; manual improvement is required
  • The AC is already very detailed with high coverage → No need to check, avoid wasting time
  • Expect 100% no false positives → Detection is rule-based and may have a small number of false positives

📋 Prerequisites

  • At least 2-3 Acceptance Criteria (including the Given-When-Then three-part structure)
  • The AC document is in .md format, located in thespec/requirements/directory
  • The AC has been linked to the corresponding User Story (source_us field filled in)
  • Willing to accept inspection suggestions and manually supplement missed scenarios
  • Understand that the scores in the report are auxiliary judgments, and the final decision is made by the user

Example

Scenario: 成功登录
  Given 用户已注册且账号正常
  And 用户在登录页面
  When 用户输入正确的用户名和密码
  And 点击登录按钮
  Then 用户跳转到首页
  And 显示欢迎信息

Scenario: 密码错误
  Given 用户已注册且账号正常
  When 用户输入错误的密码
  Then 显示"用户名或密码错误"提示
  And 用户停留在登录页面

>> Command

>>ac_format_check    # AC 格式检查
>>ac_coverage        # AC 覆盖度检查
>>ac_generate        # 从 US 生成 AC 骨架

Related Skills

  • Prerequisite: user-story-format (US already defined)
  • Parallel: principle-invest (INVEST validation)
  • Follow-up: bdd-scenario (convert to BDD)
  • Follow-up: vertical-slice (design phase)

TODO: AC coverage check rules to be refined