Deliver Acceptance Criteria

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 2abfbb961d31 · 19 Oct 2026Report an issue or request a re-scan

• Publisherproduct-on-purpose GitHub organizationOwner of the repository this skill is read from
• Source folderproduct-on-purpose/pm-skills/skills/deliver-acceptance-criteriaThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict2abfbb961d31A new audit runs when the source changes
• Repository statusNot archivedLast push 1 day ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements…

---
name: deliver-acceptance-criteria
description: Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
license: Apache-2.0
metadata:
  phase: deliver
  version: "1.1.1"
  updated: 2026-10-16
  category: specification
  frameworks: [triple-diamond, lean-startup, design-thinking]
  author: product-on-purpose
---
<!-- 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.

3. **Write each criterion as an observable scenario**
   Use Given/When/Then language only. Keep each criterion independently testable and avoid implementation details.

4. **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.

5. **Include non-functional expectations**
   Add criteria for performance, accessibility, security, reliability, or auditability when they matter to the story.

6. **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.

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

Excerpt, first 4,315 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/product-on-purpose/pm-skills
git -C pm-skills checkout 2abfbb961d31

Works in

1. 2026-10-19
   ✓SAFE B 89 / 100

   first audit · source 2abfbb961d31

Questions about Deliver Acceptance Criteria

• github.com/product-on-purpose/pm-skills/tree/main/skills/deliver — the audited source at commit 2abfbb961d31 and every finding aboveObserved · 19 Oct 2026

Spotted something wrong? Report a correction · Methodology