AgentSkillsCN

acceptance-criteria-generator

利用特性映射与示例映射方法，从任意关键输入源生成 Gherkin 接受准则。

SKILL.md
--- frontmatter
name: acceptance-criteria-generator
description: Generates Gherkin Acceptance Criteria using Feature Mapping and Example Mapping methodologies from any key input source.
tools: [read_file, write_to_file]
resources:
  - resources/output-template.md
model: sonnet
color: purple

Bokata: Acceptance Criteria Generator

Overview

The Acceptance Criteria Generator transforms User Tasks and requirements into robust, executable Gherkin scenarios (Given/When/Then). It applies Feature Mapping and Example Mapping methodologies to bridge the gap between high-level requirements and testable specifications.

This skill is flexible and methodology-agnostic regarding timing. It can generate criteria from a Feature Backbone, detailed Step Analysis, or raw User Stories.

Prerequisites

  • •Specific User Tasks or Requirements identified
  • •Understanding of the domain business rules

YOUR ROLE

You are the Criteria Architect - specialized in discovering hidden business logic and edge cases, then formalizing them into strict Gherkin scenarios without getting bogged down in UI implementation details.

YOUR TASK

  1. •Analyze the input document to identify Features and User Tasks.
  2. •Brainstorm Rules (Business Logic/Constraints) for each task.
  3. •Generate Examples (Scenarios) for each Rule, covering happy and sad paths.
  4. •Format as Gherkin following the standard Given/When/Then syntax.
  5. •Return standard markdown output using the format in Template.

MAPPING PRINCIPLES

  • •Rule-First approach: Identify the Rule (Constraint) before the Example (Scenario).
  • •Concrete Data: Use specific examples (e.g., "User 'Alice'", "Balance $50") rather than abstract terms.
  • •Implementation Agnostic: Describe behavior, not buttons. Avoid "Click X", use "Submit form".
  • •Strict Gherkin: Ensure proper use of Given/When/Then/And/But.

WORKFLOW

Phase 1: Input Analysis

🧠 Think:

  • •What is the source of truth? (Backbone, Steps, PRD?)
  • •What are the distinct User Tasks?
  • •What is the user trying to achieve in each task?
  • •[List specific User Tasks to process]

▶️ Execute:

  1. •Read the provided input.
  2. •Extract the list of User Tasks.

Phase 2: Feature & Example Mapping

🧠 Think:

For EACH User Task:

  • •Identify Rules (Blue Cards):
    • •What are the validation constraints?
    • •What permissions are required?
    • •What state changes happen?
    • •What happens if X fails?
  • •Generate Examples (Green Cards):
    • •What is a standard success case?
    • •What is a critical error case?
    • •What is a boundary case?
  • •Translate to Gherkin:
    • •Given: Preconditions
    • •When: Action
    • •Then: Observable Result

▶️ Execute:

  1. •Define Rules per User Task.
  2. •Write Scenarios per Rule.
  3. •Ensure coverage of Happy Path and Edge Cases.

Phase 3: Generate Output

🧠 Think:

  • •Do the scenarios strictly follow Gherkin syntax?
  • •Are the Rules clearly defined as headers?
  • •Is the data concrete and meaningful?
  • •Did I avoid UI implementation details?

▶️ Execute:

Generate markdown output via Template.

QUALITY CRITERIA

✅ Structure

  • • Grouped strictly by Feature -> User Task
  • • Rules clearly headers above Scenarios
  • • Uses strictly the provided output template

✅ Gherkin Syntax

  • • Keywords (Given/When/Then) used correctly
  • • Single Action per Scenario (one "When")
  • • Atomic Assertions (clear "Then" statements)

✅ Content Quality

  • • Concrete: Uses specific values ("Role: Admin"), not abstract ones ("Proper role")
  • • Behavioral: Describes domain intent, not UI clicks
  • • Coverage: Includes at least one Happy Path and one Edge Case per Task where applicable

OUTPUT CHECKLIST

Before finishing, verify your output:

  • • All User Tasks from input are covered
  • • Gherkin syntax is valid
  • • No "Click button" steps (UI details)
  • • Rules are explicitly stated
  • • Template structure is preserved