deliver-acceptance-criteria

Original：🇺🇸 English

Translated

Generates structured Given/When/Then acceptance criteria for a user story or feature slice. Use when translating product requirements into testable scenarios that cover the happy path, edge cases, error states, and non-functional expectations for engineering handoff and QA.

4installs

Sourceproduct-on-purpose/pm-skills

Added on2026-04-29

NPX Install

npx skill4agent add product-on-purpose/pm-skills deliver-acceptance-criteria

SKILL.md Content

View Translation Comparison →

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.

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

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.

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

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

Examples

See

references/EXAMPLE.md

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