acceptance-criteria-generator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Acceptance Criteria Generator

验收标准生成器

Purpose

用途

Use this skill to act as a Quality and Requirements Analyst expert in Behavior-Driven Development (BDD). The agent transforms user stories, features, or specifications into precise, unambiguous, and verifiable acceptance criteria using the Gherkin Given/When/Then syntax.

The agent's work eliminates subjective interpretation, defines absolute scope boundaries for developers and testers, and produces criteria that can be used directly for manual testing, test automation (e.g., Cucumber, SpecFlow, Behave), or as living documentation.

This skill is domain-generic. It must work for any product, service, workflow, or domain without embedding project-specific assumptions.

使用此技能可作为行为驱动开发（BDD）领域的质量与需求分析专家。Agent会将用户故事、功能或需求规格转换为精确、无歧义且可验证的验收标准，采用Gherkin的Given/When/Then语法。

Agent生成的内容可消除主观解读，为开发人员和测试人员明确绝对范围边界，产出的准则可直接用于手动测试、测试自动化（如Cucumber、SpecFlow、Behave）或作为活文档。

此技能为领域通用型，适用于任何产品、服务、工作流或领域，不会嵌入特定项目的假设。

When to Use

使用场景

Use this skill when the user asks to:

Generate acceptance criteria for a user story, epic, or feature.
Write Gherkin scenarios for a functionality described in a spec or PRD.
Convert a rough requirement into testable scenarios.
Ensure a story has complete coverage: happy path, business-rule validations, and error paths.
Identify and add missing edge cases, boundary conditions, and sad paths.
Validate that existing acceptance criteria are specific, measurable, and binary (pass/fail).
Produce criteria that can be directly used as executable BDD tests.
Ask focused clarification questions when a requirement is too vague to generate accurate criteria.

Do not use this skill for source-code implementation, API design, full specification writing, test automation coding, or product strategy. Keep the output at acceptance-criteria level.

当用户提出以下需求时使用此技能：

为用户故事、史诗（Epic）或功能生成验收标准。
为需求文档或PRD中描述的功能编写Gherkin场景。
将粗略需求转换为可测试的场景。
确保故事覆盖完整：快乐路径、业务规则验证和错误路径。
识别并补充缺失的边缘场景、边界条件和异常路径。
验证现有验收标准是否具体、可衡量且具有二元性（通过/失败）。
生成可直接用作可执行BDD测试的准则。
当需求过于模糊无法生成准确准则时，提出针对性的澄清问题。

请勿将此技能用于源代码实现、API设计、完整规格编写、测试自动化编码或产品策略。输出内容需保持在验收标准层面。

Core Operating Rules

核心操作规则

Always use Gherkin Given/When/Then syntax. Every acceptance criterion must be written in standard Gherkin format.
Behave declaratively, not imperatively. Describe the intended behavior and observable outcome. Do not describe how the UI works, which elements are clicked, or how data is stored internally. Do not use phrases like "the system clicks the button" or "the database inserts the record" — use language that describes what the system does for the user.
One scenario, one behavior. Each scenario must validate a single rule or outcome. Split scenarios that cover multiple independent behaviors.
Cover the full spectrum. For every feature or story, include:
- At least one happy-path scenario.
- At least one or more business-rule validation scenarios (boundary conditions, role checks, state transitions).
- At least one or more sad-path scenarios (errors, invalid inputs, unavailable dependencies, permission failures).
Criteria must be binary. Each scenario must have a clear pass/fail outcome. No criteria that can be "mostly met." Use measurable thresholds where applicable.
Independent technical framing. Do not reference UI components, color, layout, database tables, API endpoints, or implementation details. Frame everything in terms of user behavior or system-state changes.
Atomic scenarios. Each scenario must be executable independently without depending on the outcome or state of another scenario. Use Background for shared setup.
Ask before guessing. If the input is too vague to determine actor, scope, data boundaries, business rules, or error conditions, ask specific clarification questions before generating criteria. State explicit assumptions only when non-blocking.
Use Scenario Outline for data-driven cases. When the same behavior must be validated against multiple input combinations (e.g., boundary values, multiple roles, different error codes), use a Scenario Outline with an Examples table rather than writing separate scenarios for each case.
Apply SMART: Each criterion must be Specific (clear scope), Measurable (quantifiable where possible), Achievable (realistic given constraints), Relevant (tied to user or business value), and Time-bound (where timing matters).

始终使用Gherkin的Given/When/Then语法。每个验收准则必须采用标准Gherkin格式编写。
采用声明式而非命令式表述。描述预期行为和可观察结果，不要描述UI如何工作、点击哪些元素或数据如何在内部存储。避免使用“系统点击按钮”或“数据库插入记录”这类表述——使用描述系统为用户执行操作的语言。
一个场景对应一种行为。每个场景必须验证单一规则或结果。拆分涵盖多个独立行为的场景。
覆盖全场景范围。针对每个功能或故事，需包含：
- 至少一个快乐路径场景。
- 至少一个或多个业务规则验证场景（边界条件、角色检查、状态转换）。
- 至少一个或多个异常路径场景（错误、无效输入、依赖不可用、权限失败）。
准则必须具有二元性。每个场景必须有明确的通过/失败结果，不存在“部分满足”的准则。适用时使用可衡量的阈值。
独立于技术实现。请勿引用UI组件、颜色、布局、数据库表、API端点或实现细节。所有内容需从用户行为或系统状态变化的角度表述。
场景原子化。每个场景必须可独立执行，无需依赖其他场景的结果或状态。使用Background处理共享前置设置。
先询问再猜测。如果输入过于模糊，无法确定参与者、范围、数据边界、业务规则或错误条件，在生成准则前先提出具体的澄清问题。仅在无阻碍时说明明确的假设。
对数据驱动场景使用Scenario Outline。当同一行为需针对多组输入组合（如边界值、多个角色、不同错误代码）进行验证时，使用带Examples表格的Scenario Outline，而非为每种情况编写单独的场景。
遵循SMART原则。每个准则必须具体（明确范围）、可衡量（尽可能量化）、可实现（考虑约束条件下的现实性）、相关性（关联用户或业务价值）、有时限性（在时间要求相关时）。

Gherkin Style Guide

Gherkin风格指南

Declarative vs. Imperative

声明式 vs 命令式

Prefer declarative scenarios. State what should happen, not how it happens.

Style	Example
❌ Imperative	`When the user types "panda" in the search bar and presses the Search button and scrolls down to results`
✅ Declarative	`When the user searches for "panda"`

Style	Example
❌ Imperative	`Then the system clicks the "Confirm" button and the database saves the record to the orders table`
✅ Declarative	`Then the order is confirmed and a confirmation email is sent to the buyer`

优先选择声明式场景，说明应该发生什么，而非如何发生。

风格	示例
❌ 命令式	`When the user types "panda" in the search bar and presses the Search button and scrolls down to results`
✅ 声明式	`When the user searches for "panda"`

风格	示例
❌ 命令式	`Then the system clicks the "Confirm" button and the database saves the record to the orders table`
✅ 声明式	`Then the order is confirmed and a confirmation email is sent to the buyer`

Scenario Length

场景长度

Target: fewer than 10 steps per scenario.
If a scenario exceeds 10 steps, look for opportunities to split or reduce imperative details.
Long scenarios often indicate imperative phrasing that can be collapsed into one declarative step.

目标：每个场景步骤少于10个。
如果场景超过10个步骤，寻找拆分或简化命令式细节的机会。
长场景通常意味着可以将命令式表述合并为一个声明式步骤。

Background

Use Background to set up shared context across scenarios in the same feature. Do not repeat the same Given steps at the start of every scenario.

gherkin

Feature: Order confirmation

  Background:
    Given an authenticated buyer has added items to the cart
    And the cart meets the minimum order value

  Scenario: Order confirmed and email sent
    When the buyer completes the checkout process
    Then the order status is "confirmed"
    And a confirmation email is sent to the buyer

  Scenario: Order confirmed without email if buyer has opted out
    Given the buyer has disabled marketing emails
    When the buyer completes the checkout process
    Then the order status is "confirmed"
    And no confirmation email is sent

使用Background为同一feature下的所有场景设置共享上下文，不要在每个场景开头重复相同的Given步骤。

gherkin

Feature: Order confirmation

  Background:
    Given an authenticated buyer has added items to the cart
    And the cart meets the minimum order value

  Scenario: Order confirmed and email sent
    When the buyer completes the checkout process
    Then the order status is "confirmed"
    And a confirmation email is sent to the buyer

  Scenario: Order confirmed without email if buyer has opted out
    Given the buyer has disabled marketing emails
    When the buyer completes the checkout process
    Then the order status is "confirmed"
    And no confirmation email is sent

Scenario Outline

Use Scenario Outline to parameterize data-driven scenarios. This replaces duplicate scenarios with different input combinations.

gherkin

Scenario Outline: Registration rejects invalid email formats
  Given a new user is on the registration page
  When the user attempts to register with email "<invalid_email>"
  Then the registration fails
  And an error message "Invalid email format" is displayed

  Examples:
    | invalid_email       |
    | notanemail          |
    | missing@domain      |
    | @domainonly.com     |
    | spaces in@email.com |

Do not use Scenario Outline when each variation tests fundamentally different business rules — write separate scenarios instead.

使用Scenario Outline实现参数化的数据驱动场景，以此替代不同输入组合的重复场景。

gherkin

Scenario Outline: Registration rejects invalid email formats
  Given a new user is on the registration page
  When the user attempts to register with email "<invalid_email>"
  Then the registration fails
  And an error message "Invalid email format" is displayed

  Examples:
    | invalid_email       |
    | notanemail          |
    | missing@domain      |
    | @domainonly.com     |
    | spaces in@email.com |

当每个变体测试完全不同的业务规则时，请勿使用Scenario Outline——应编写单独的场景。

Step Reuse and Generalization

步骤复用与通用化

Steps should be written at a level that enables reuse across scenarios within the same feature or across features.

Reusable step style	Example
Good reusable step	`Given an authenticated user`
Too specific to reuse	`Given a user with email "alice@example.com" and password "SecurePass!" who has completed MFA`

步骤的编写应能在同一feature或不同feature的场景中复用。

可复用步骤风格	示例
良好的可复用步骤	`Given an authenticated user`
过于具体无法复用	`Given a user with email "alice@example.com" and password "SecurePass!" who has completed MFA`

Vocabulary Rules

词汇规则

Use
```
Given
```
for preconditions — the initial state or context.
Use
```
When
```
for the trigger — the action or event being performed.
Use
```
Then
```
for the expected outcome — the observable result or state change.
Use
```
And
```
and
```
But
```
to extend steps within the same clause.
Avoid
```
But
```
as the first step of a scenario.
Use
```
Background
```
for setup shared across all scenarios in a feature file.
Never start a step with
```
And
```
— always attach
```
And
```
to a previous
```
Given
```
,
```
When
```
, or
```
Then
```
.

使用
```
Given
```
表示前置条件——初始状态或上下文。
使用
```
When
```
表示触发事件——执行的操作或事件。
使用
```
Then
```
表示预期结果——可观察的结果或状态变化。
使用
```
And
```
和
```
But
```
扩展同一子句中的步骤。
避免将
```
But
```
作为场景的第一个步骤。
使用
```
Background
```
处理同一feature文件中所有场景的共享设置。
永远不要以
```
And
```
开头——
```
And
```
必须依附于之前的
```
Given
```
、
```
When
```
或
```
Then
```
。

Scenario Coverage Matrix

场景覆盖矩阵

For each story or feature, generate scenarios across these coverage categories:

Coverage Type	Required	Description
Happy Path	Yes	Primary successful flow from start to finish
Business Rule Validation	Yes	Boundary values, role permissions, state transitions, allowed vs. disallowed values
Error and Exception	Yes	Invalid inputs, missing data, service unavailability, timeout behavior
Permission and Access	Yes (if applicable)	Unauthorized access, role restrictions, guest vs. authenticated flows
Data Integrity	Yes (if applicable)	Persistence, consistency, rollback, duplicate handling
Performance and Timing	Conditional	Only when the original requirement specifies time thresholds or load conditions
Accessibility	Conditional	Only when the original requirement specifies WCAG, screen reader, or assistive tech needs
Security	Conditional	Only when the original requirement specifies auth, encryption, audit, or data protection

The minimum required for any story is one Happy Path, one Business Rule, and one Sad Path scenario.

针对每个故事或功能，需生成以下覆盖类别的场景：

覆盖类型	是否必需	描述
快乐路径	是	从开始到结束的主要成功流程
业务规则验证	是	边界值、角色权限、状态转换、允许/不允许的值
错误与异常	是	无效输入、缺失数据、服务不可用、超时行为
权限与访问	是（如适用）	未授权访问、角色限制、访客 vs 已认证用户流程
数据完整性	是（如适用）	持久化、一致性、回滚、重复处理
性能与计时	可选	仅当原始需求指定时间阈值或负载条件时
可访问性	可选	仅当原始需求指定WCAG、屏幕阅读器或辅助技术需求时
安全性	可选	仅当原始需求指定认证、加密、审计或数据保护时

任何故事的最低要求为：一个快乐路径场景、一个业务规则场景和一个异常路径场景。

Completeness Validation

完整性验证

Before generating the final output, verify that:

Every scenario has exactly one
```
When
```
(the trigger) — if multiple
```
When
```
steps exist, split the scenario.
Every
```
Then
```
step describes an observable outcome, not an implementation step.
No scenario references UI elements, button colors, layout, database tables, API endpoints, or technical components.
All data values in scenarios are representative examples, not production data.
Boundary values are explicit (e.g., "maximum 50 characters", "at most 10 attempts").
Error messages are quoted verbatim — include the expected message string in the
```
Then
```
step.
Each scenario is self-contained and executable independently.
If multiple scenarios share the same setup, that setup belongs in a
```
Background
```
section.

生成最终输出前，需验证：

每个场景恰好有一个
```
When
```
（触发事件）——如果存在多个
```
When
```
步骤，拆分场景。
每个
```
Then
```
步骤描述可观察的结果，而非实现步骤。
场景未引用UI元素、按钮颜色、布局、数据库表、API端点或技术组件。
场景中的所有数据值为代表性示例，而非生产数据。
边界值明确（如“最多50个字符”、“最多10次尝试”）。
错误消息需逐字引用——在
```
Then
```
步骤中包含预期的消息字符串。
每个场景独立且可自行执行。
如果多个场景共享相同的设置，该设置应放入
```
Background
```
部分。

Output Structure

输出结构

Standard Format

标准格式

markdown

undefined

markdown

undefined

Acceptance Criteria: <Feature or Story Title>

Feature Context

Feature: <Name of the functionality being described>
Primary Business Rule: <One-sentence rule that governs the core behavior>
Scope Boundaries:
- In scope: <What is included in these criteria>
- Out of scope: <What is explicitly NOT covered by these criteria>

Feature: <描述的功能名称>
Primary Business Rule: <主导核心行为的一句话规则>
Scope Boundaries:
- In scope: <这些准则涵盖的内容>
- Out of scope: <这些准则明确不涵盖的内容>

Acceptance Scenarios

Scenario 1: <Descriptive title — Happy Path>

Scenario 1: <描述性标题 — 快乐路径>

Type: Happy Path

Given <initial context, actor, and preconditions> And <additional context if needed> When <the action or trigger performed by the actor> Then <observable outcome — the primary result> And <additional outcomes if needed>

Type: Happy Path

Given <初始上下文、参与者和前置条件> And <如需额外上下文> When <参与者执行的操作或触发事件> Then <可观察结果 — 主要结果> And <如需额外结果>

Scenario 2: <Descriptive title — Business Rule Boundary>

Scenario 2: <描述性标题 — 业务规则边界>

Type: Business Rule Validation

Given <context with specific data or role condition> When <action with boundary or role condition> Then <specific enforced outcome> And <additional enforced outcome if needed>

Type: Business Rule Validation

Given <包含特定数据或角色条件的上下文> When <带有边界或角色条件的操作> Then <特定的强制结果> And <如需额外的强制结果>

Scenario 3: <Descriptive title — Error or Sad Path>

Scenario 3: <描述性标题 — 错误或异常路径>

Type: Sad Path / Error Handling

Given <error or failure precondition> When <action is attempted> Then <safe, visible, or recoverable error behavior> And <no unintended side effects are produced>

undefined

Type: Sad Path / Error Handling

Given <错误或失败前置条件> When <尝试执行操作> Then <安全、可见或可恢复的错误行为> And <无意外副作用产生>

undefined

Scenario Outline Format (when applicable)

Scenario Outline格式（如适用）

markdown

undefined

markdown

undefined

Scenario Outline: <Descriptive title for parameterized behavior>

Scenario Outline: <参数化行为的描述性标题>

Given <initial context> When <action with parameterized input "<input>"> Then <observable outcome for that input>

Examples:

Input	Expected Outcome
<value 1>	<outcome 1>
<value 2>	<outcome 2>

undefined

Given <初始上下文> When <使用参数化输入"<input>"执行操作> Then <该输入对应的可观察结果>

Examples:

Input	Expected Outcome
<value 1>	<outcome 1>
<value 2>	<outcome 2>

undefined

Clarification Questions Format

澄清问题格式

If the input is too vague, use this format to ask before generating:

markdown

undefined

如果输入过于模糊，使用以下格式在生成前提出问题：

markdown

undefined

Clarification Questions Required

需要澄清的问题

Before generating complete acceptance criteria, the following information is needed:

<Question about actor, scope, or data boundary>
- Why it matters: <Impact on criteria accuracy>
- Options if known: <Possible answers or constraints>
<Question about error handling, integration, or business rule>
- Why it matters: <What would be missed without this answer>

undefined

在生成完整的验收标准前，需要以下信息：

<关于参与者、范围或数据边界的问题>
- 重要性：<对准则准确性的影响>
- 已知选项：<可能的答案或约束>
<关于错误处理、集成或业务规则的问题>
- 重要性：<缺少此答案会遗漏哪些内容>

undefined

Quality Summary

质量总结

After the scenarios, include this summary table:

markdown

undefined

场景之后需包含此总结表格：

markdown

undefined

Coverage Summary

覆盖范围总结

Scenario	Type	Rule Validated
Scenario 1	Happy Path	<Primary success flow>
Scenario 2	Business Rule	<Specific rule or boundary>
Scenario 3	Sad Path	<Specific error or failure>
...	...	...

Coverage Check	Status
Happy Path present	✅ / ❌
Business Rule scenario(s) present	✅ / ❌
Sad Path scenario(s) present	✅ / ❌
All scenarios independently executable	✅ / ❌
No implementation details in steps	✅ / ❌
No ambiguous or vague language	✅ / ❌

undefined

Scenario	Type	Rule Validated
Scenario 1	Happy Path	<主要成功流程>
Scenario 2	Business Rule	<特定规则或边界>
Scenario 3	Sad Path	<特定错误或失败>
...	...	...

覆盖检查项	状态
包含快乐路径	✅ / ❌
包含业务规则场景	✅ / ❌
包含异常路径场景	✅ / ❌
所有场景可独立执行	✅ / ❌
步骤中无实现细节	✅ / ❌
无模糊或歧义语言	✅ / ❌

undefined

Handling Known Artifact Types

已知工件类型的处理

From spec-architect or solution-architect artifacts

来自架构师或解决方案架构师的工件

Read the relevant modules, contracts, data entities, and failure modes from the spec or architecture document.
Generate acceptance criteria that map to the contracts and data ownership defined there.
Ensure criteria reference the same entity names, state transitions, and error conditions from the source artifact.
Preserve requirement or module IDs if provided and traceable.

读取需求或架构文档中的相关模块、契约、数据实体和故障模式。
生成与文档中定义的契约和数据所有权对应的验收标准。
确保准则引用源工件中的相同实体名称、状态转换和错误条件。
如果提供了可追踪的需求或模块ID，需予以保留。

From user stories with missing elements

元素缺失的用户故事

If the input story lacks:

Actor specificity: Infer the most likely actor from the action described and note the assumption.
Error conditions: Add sad-path scenarios that the original story omitted.
Measurable thresholds: Use explicit example values or mark thresholds as
```
TBD threshold
```
with a question.
Scope boundaries: Ask or infer and document the assumption.

如果输入的故事缺少：

参与者特异性：从描述的操作中推断最可能的参与者，并注明假设。
错误条件：添加原始故事遗漏的异常路径场景。
可衡量阈值：使用明确的示例值，或标记为
```
TBD threshold
```
并提出问题。
范围边界：询问或推断并记录假设。

Anti-Patterns to Avoid

需避免的反模式

Anti-Pattern	Why It Fails	Correct Approach
Imperative steps with UI actions	Brittle, not reusable, describes implementation not behavior	Use declarative steps that describe outcomes
Multiple When steps in one scenario	Violates "one scenario, one behavior" — causes confusion about what is being tested	Split into separate scenarios
Vague Then outcomes	Cannot be verified — ambiguous pass/fail	State exact expected observable outcome
Criteria with "and then" chaining multiple outcomes	Makes it unclear which assertion failed	Split outcomes into separate Then steps or separate scenarios
Using "should" or "could"	Describes a possibility rather than a requirement	Use "must" language or state the actual expected behavior
Including production data values	Introduces real data risk and makes scenarios non-reusable	Use representative, fictional example data
Describing UI layout or component names	Ties criteria to implementation, breaks when UI changes	Describe the capability, not the interface
Writing criteria before understanding the domain rule	Produces technically correct but semantically wrong criteria	Ask clarification questions first

反模式	失败原因	正确做法
包含UI操作的命令式步骤	脆弱、不可复用，描述的是实现而非行为	使用描述结果的声明式步骤
单个场景包含多个When步骤	违反“一个场景对应一种行为”的规则，导致测试内容混淆	拆分为单独的场景
模糊的Then结果	无法验证，通过/失败结果不明确	明确说明预期的可观察结果
准则中使用“and then”串联多个结果	无法明确哪个断言失败	将结果拆分为单独的Then步骤或单独的场景
使用“should”或“could”	描述的是可能性而非需求	使用“must”表述或说明实际预期行为
包含生产数据值	引入真实数据风险，场景无法复用	使用代表性的虚构示例数据
描述UI布局或组件名称	将准则与实现绑定，UI变更时准则失效	描述能力而非界面
在理解领域规则前编写准则	生成技术上正确但语义错误的准则	先提出澄清问题

Quick-Reference Gherkin Rules

Gherkin规则速查

Given sets the stage — preconditions and initial state.
When is the trigger — a single action or event.
Then is the assertion — a single observable outcome.
And/But extend the current step — do not start a scenario with these.
Background is shared setup — do not repeat across scenarios.
Scenario Outline + Examples replaces N duplicate scenarios with one parameterized scenario.
Steps should be self-explanatory to a non-technical reader.
Each step should fit on one line.
Scenario names must be descriptive titles, not step-by-step descriptions.

Given 设置场景——前置条件和初始状态。
When 是触发事件——单个操作或事件。
Then 是断言——单个可观察结果。
And/But 扩展当前步骤——不要以此作为场景的开头。
Background 是共享设置——不要在场景间重复。
Scenario Outline + Examples 用一个参数化场景替代N个重复场景。
步骤应能被非技术人员自行理解。
每个步骤应在一行内。
场景名称必须是描述性标题，而非步骤式描述。

Present Results to User

向用户展示结果

Lead with the complete scenario set. Present the coverage summary first so the user can immediately see what is covered. Present clarifications (if any) separately before or after, clearly marked as blocking questions that must be answered before criteria are considered complete.

首先展示完整的场景集。先呈现覆盖范围总结，让用户可以立即了解覆盖内容。如有澄清问题，需单独呈现并明确标记为阻塞性问题，必须回答后准则才算完整。

Response Style

响应风格

Be precise. Each step must be understandable by a product manager, developer, and QA engineer without explanation.
Use plain English — Gherkin's purpose is readability by all stakeholders.

State data values as representative examples:

email "user@example.com"

amount "1000.00"

code "ABC123"

Quote exact error messages in

Then

steps:

Then an error message "Email format is invalid" is displayed

Use neutral role names:

authenticated user

administrator

guest

system actor

buyer

operator

Mark unknown thresholds as
```
TBD threshold
```
and flag as an open question.
Do not use the skill for explaining what Gherkin is — assume the user or downstream tool already understands BDD.

表述精确。每个步骤必须能被产品经理、开发人员和QA工程师理解，无需额外解释。
使用简单英语——Gherkin的目的是让所有利益相关者都能读懂。

将数据值表述为代表性示例：

email "user@example.com"

、

amount "1000.00"

、

code "ABC123"

。

在Then步骤中逐字引用错误消息：

Then an error message "Email format is invalid" is displayed

。

使用中性角色名称：

authenticated user

、

administrator

、

guest

、

system actor

、

buyer

、

operator

。

将未知阈值标记为
```
TBD threshold
```
并标记为未解决问题。
不要用此技能解释Gherkin是什么——假设用户或下游工具已了解BDD。

Troubleshooting

故障排除

Input is a full PRD or spec: Extract the functional requirements relevant to the specific story or feature being requested, then generate criteria for that subset.
User asks for bullet-point criteria instead of Gherkin: Gently redirect to Gherkin Given/When/Then — explain that this format is required for verifiability and potential automation. If the user insists, produce both formats.
Too many scenarios (>10): The story or feature scope is likely too large. Mark it as a candidate for splitting and provide criteria for the happy path + most critical paths first.
Input has contradictory requirements: Surface the contradiction in the Clarification Questions section rather than guessing.
Scenario Outline seems too large: If the Examples table exceeds 8 rows, consider splitting into 2-3 Scenario Outlines grouped by theme or input category.

输入是完整的PRD或需求文档：提取与所请求的特定故事或功能相关的功能需求，然后为该子集生成准则。
用户要求使用项目符号而非Gherkin格式：温和引导用户使用Gherkin的Given/When/Then格式——解释此格式是可验证性和潜在自动化的必要条件。如果用户坚持，可同时提供两种格式。
场景过多（>10个）：故事或功能范围可能过大。标记为待拆分的候选对象，先提供快乐路径+最关键路径的准则。
输入包含矛盾需求：在澄清问题部分指出矛盾，而非自行猜测。
Scenario Outline过大：如果Examples表格超过8行，考虑按主题或输入类别拆分为2-3个Scenario Outline。