Deliver Acceptance Criteria

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

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

When NOT to Use

• You need the user stories themselves -> use deliver-user-stories; this skill deepens a story that already exists
• You need systematic failure coverage across a whole feature -> use deliver-edge-cases; this skill stays story-scoped
• There is no story or slice to bind criteria to yet -> use deliver-prd or deliver-user-stories first
• You are defining success metrics for an experiment, not done-ness for a story -> use measure-experiment-design

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.