Translation Comparison - deliver-acceptance-criteria

Acceptance criteria define the observable behavior that must be true for a story or feature to be considered done. This skill turns feature context into concise, testable Given/When/Then scenarios that engineers and QA can verify without guessing intent.

Acceptance Criteria定义了用户故事或功能被视为完成时必须满足的可观测行为。本技能可将功能上下文转换为简洁、可测试的Given/When/Then场景，让工程师和QA无需猜测意图即可进行验证。

When to Use

适用场景

After a user story, PRD section, or feature slice is defined
When a team needs clear pass/fail conditions for implementation
When writing QA-ready criteria for sprint planning or handoff
When a story has edge cases, error paths, or non-functional expectations that should be explicit

在用户故事、PRD章节或功能切片定义完成后使用
当团队需要明确的通过/失败实施条件时
为 sprint 规划或交接编写适用于QA的标准时
当用户故事包含需要明确说明的边缘案例、错误路径或非功能性需求时

Instructions

使用步骤

When asked to create acceptance criteria, follow these steps:

Confirm the story or feature scope Identify the exact slice of work. If the scope is unclear, ask for the user story, PRD section, or feature description before drafting criteria.
Separate the happy path from exceptions Start with the primary success flow, then add edge cases and error states that are likely or costly if missed.
Write each criterion as an observable scenario Use Given/When/Then language only. Keep each criterion independently testable and avoid implementation details.
Cover recovery and failure behavior Describe what the user sees or can do when validation fails, a dependency is unavailable, or a save action cannot complete.
Include non-functional expectations Add criteria for performance, accessibility, security, reliability, or auditability when they matter to the story.
Avoid duplication and overlap Each criterion should test one outcome. If two criteria describe the same behavior, merge or split them until the intent is clear.
Review for testability Ensure a reviewer can pass or fail each criterion without interpretation. If a statement is subjective, rewrite it into a measurable outcome.

当被要求创建验收标准时，请遵循以下步骤：

确认用户故事或功能范围 明确具体的工作内容。如果范围不清晰，请先获取用户故事、PRD章节或功能描述，再起草标准。
区分正常流程与异常情况 先梳理主要成功流程，再添加可能出现或遗漏后代价较高的边缘案例和错误状态。
将每条标准写成可观测的场景 仅使用Given/When/Then表述方式。确保每条标准可独立测试，避免包含实现细节。
涵盖恢复与失败行为 描述当验证失败、依赖不可用或保存操作无法完成时，用户能看到的内容或可执行的操作。
包含非功能性需求 当性能、可访问性、安全性、可靠性或可审计性对用户故事至关重要时，添加相关标准。
避免重复与重叠 每条标准应测试一种结果。如果两条标准描述相同行为，请合并或拆分，直到意图清晰。
检查可测试性 确保审核者无需主观解读即可判定每条标准通过或失败。如果表述带有主观性，请重写为可衡量的结果。

Output Contract

输出规范

Use

references/TEMPLATE.md

as the output format. A complete response should:

Restate the feature or story context
Group criteria into happy path, edge cases, error states, and non-functional criteria
Use explicit Given/When/Then statements for each criterion
Note assumptions or open questions when context is incomplete

请使用

references/TEMPLATE.md

作为输出格式。完整的响应应包含：

重述功能或用户故事的上下文
将标准分为正常流程、边缘案例、错误状态和非功能性标准四类
每条标准使用明确的Given/When/Then语句
当上下文不完整时，注明假设或未解决的问题

Quality Checklist

质量检查清单

Before finalizing, verify:

The criteria map to a specific story or feature slice
The happy path is covered first
Edge cases are explicit, not implied
Error states include user-visible recovery behavior
Non-functional criteria are included when relevant
Each criterion is testable and has one clear outcome
No implementation details leak into the acceptance criteria

最终确定前，请验证：

标准对应特定的用户故事或功能切片
首先覆盖正常流程
边缘案例明确说明，而非隐含
错误状态包含用户可见的恢复行为
相关的非功能性标准已包含
每条标准可测试且结果明确
验收标准中未包含实现细节

See

references/EXAMPLE.md

for a completed example based on a realistic e-commerce checkout flow.

请查看

references/EXAMPLE.md

，其中包含基于真实电商结账流程的完整示例。

deliver-acceptance-criteria

Original

Translation

Acceptance Criteria

验收标准（Acceptance Criteria）