deliver-acceptance-criteria

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