<!-- 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
• The criterion is a rate over model output, such as "90% of answers are faithful to their sources" -> use the AI Behavior and Evaluation section of deliver-prd, which says a rate needs a designed sample to verify it, and what to record until one exists

Instructions

When asked to create acceptance criteria, follow these steps:

1. 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.

2. 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.