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: 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 succes...