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

Scenario: bulk-invite teammates to a workspace

This is the INPUT brief for an output-quality eval. The skill arm and the control arm each receive everything below (and nothing else about how to do the work) and produce an acceptance-criteria artifact for it. Judges never see this header.

Feature brief

Product: a B2B SaaS team workspace (project-management tool). Workspace admins manage membership.

User story: As a workspace admin, I want to invite several teammates at once by entering or pasting their email addresses, so that I can onboard my team without sending invites one at a time.

How it should work (intended behavior):

• The invite box accepts multiple email addresses separated by commas, spaces, or newlines, or pasted

as a single CSV column.

• Each successfully invited person receives an email with a join link valid for 7 days.
• Invites default to the "Member" role; the admin can set the whole batch to "Admin", "Member", or

"Viewer" before sending.

• After sending, the admin sees a per-address result summary (sent / skipped / failed and why).

Known constraints and concerns the team has raised:

• The workspace has a seat limit tied to its plan; a batch can exceed remaining seats.
• A pasted batch can contain duplicates, addresses that are already members, addresses with a

pending invite, malformed addresses, or addresses on a corporate blocklist.

• An admin may paste up to ~500 addresses at once; the email provider throttles large sends.
• Admins later need an audit trail of who invited whom and when.
• The feature is web-based and must be accessible and responsive for large batches.

Explicitly out of scope: SSO/SCIM auto-provisioning, customizing the invite email, and changing roles after the invite is sent.

deliver-acceptance-criteria - Version History

1.1.0 (2026-06-10)

Quality-convergence minor (F-12 Batch 1): added a "When NOT to Use" section with boundary pointers to neighboring skills (the Output Contract already enumerated its groupings). No template or example changes.

1.0.1 (2026-06-10)

Description-only patch (F-12 Batch 0, from the 2026-06-09 repo audit): the trigger-surface description was rewritten to disambiguate collision pairs with an explicit boundary pointer to the sibling skill. No body, template, or behavior changes.

1.0.0 (2026-03-22)

Baseline row for the prior published version; see git history for its changes.

Acceptance Criteria: Guest Checkout

This example describes the acceptance criteria for a guest checkout flow that lets shoppers buy items without creating an account.

Story Context

The checkout experience must let a shopper complete an order as a guest, enter shipping and payment details, and receive a confirmation after payment succeeds. The criteria below focus on the behavior a reviewer can observe in the UI and system responses.

Happy Path

AC-1: Guest Checkout Form Loads

Given I have items in my cart and I am not signed in

When I open the checkout page

Then I can enter shipping information, delivery method, and payment details without being prompted to create an account

AC-2: Order Completes Successfully

Given I have entered valid shipping and payment details

When I submit the order

Then I see an order confirmation page with an order number and estimated delivery date

Edge Cases

AC-3: Promo Code Can Be Applied

Given I am on checkout and my cart qualifies for a discount

When I enter a valid promo code and apply it

Then the order summary updates to show the discount before I submit payment

AC-4: Shipping Address Validation Supports International Formats

Given I enter a shipping address for a supported non-US destination

When I continue to the next step

Then the form accepts the address if it matches the country-specific validation rules

Error States

AC-5: Invalid Card Is Rejected

Given I have entered shipping information but the payment card is invalid

When I attempt to place the order

Then I see a clear inline error message and the order is not created

AC-6: Inventory Changes During Checkout

Given an item in my cart becomes out of stock before I submit payment

When I place the order

Then I am shown which item failed, my cart remains available, and I can remove the item or choose a different variant

Non-Functional Criteria

AC-7: Checkout Responds Within the Performance Budget

Given I submit a valid order during normal operating conditions

When the checkout request is processed

Then the confirmation response is returned within 3 seconds for at least 95 percent of requests

AC-8: Checkout Errors Are Accessible

Given a validation or payment error occurs

When the error message is shown

Then the message is announced by screen readers and the field with the error receives focus when applicable

Notes

• Payment processor and inventory service availability are external dependencies.
• Fraud review and manual review flows are out of scope for this example.

Acceptance Criteria: [Feature or Story Title]

Story Context

<!-- Briefly restate the story, feature slice, or PRD section this criteria set supports. -->

[Describe the user need, scope boundary, and any assumptions that matter for testing.]

Happy Path

<!-- Capture the primary success flow first. Each criterion should be independently testable. -->

AC-1: [Happy Path Title]

Given [initial context or precondition]

When [user action or trigger]

Then [expected observable outcome]

AC-2: [Happy Path Title]

Given [initial context or precondition]

When [user action or trigger]

Then [expected observable outcome]

Edge Cases

<!-- Document boundary conditions and alternate inputs that should still behave correctly. -->

AC-3: [Edge Case Title]

Given [boundary condition or alternate state]

When [user action or trigger]

Then [expected observable outcome]

Error States

<!-- Describe failures, validation issues, and dependency problems with recovery behavior. -->

AC-4: [Error State Title]

Given [failure condition]

When [user action or trigger]

Then [expected observable outcome and recovery path]

Non-Functional Criteria

<!-- Capture performance, accessibility, security, reliability, or audit requirements. -->

AC-5: [Non-Functional Title]

Given [relevant system or user context]

When [measurement or action]

Then [expected measurable constraint or guarantee]

Notes

• [Assumption or dependency]
• [Open question if the source story is incomplete]