deliver-acceptance-criteria

Name: deliver-acceptance-criteria
Author: product-on-purpose

486stars64forks

How to install deliver-acceptance-criteria?

product-on-purpose/pm-skills/deliver-acceptance-criteria

$npx -y skills add product-on-purpose/pm-skills --skill deliver-acceptance-criteria

Installs into the current project.

Summary

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 sig

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Acceptance Criteria
3
4	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.
5
6	## When to Use
7
8	- After a user story, PRD section, or feature slice is defined
9	- When a team needs clear pass/fail conditions for implementation
10	- When writing QA-ready criteria for sprint planning or handoff
11	- When a story has edge cases, error paths, or non-functional expectations that should be explicit
12
13	## When NOT to Use
14
15	- You need the user stories themselves -> use `deliver-user-stories`; this skill deepens a story that already exists
16	- You need systematic failure coverage across a whole feature -> use `deliver-edge-cases`; this skill stays story-scoped
17	- There is no story or slice to bind criteria to yet -> use `deliver-prd` or `deliver-user-stories` first
18	- You are defining success metrics for an experiment, not done-ness for a story -> use `measure-experiment-design`
19
20	## Instructions
21
22	When asked to create acceptance criteria, follow these steps:
23
24	1. Confirm the story or feature scope
25	Identify the exact slice of work. If the scope is unclear, ask for the user story, PRD section, or feature description before drafting criteria.
26
27	2. Separate the happy path from exceptions
28	Start with the primary success flow, then add edge cases and error states that are likely or costly if missed.
29
30	3. Write each criterion as an observable scenario
31	Use Given/When/Then language only. Keep each criterion independently testable and avoid implementation details.
32
33	4. Cover recovery and failure behavior
34	Describe what the user sees or can do when validation fails, a dependency is unavailable, or a save action cannot complete.
35
36	5. Include non-functional expectations
37	Add criteria for performance, accessibility, security, reliability, or auditability when they matter to the story.
38
39	6. Avoid duplication and overlap
40	Each criterion should test one outcome. If two criteria describe the same behavior, merge or split them until the intent is clear.
41
42	7. Review for testability
43	Ensure a reviewer can pass or fail each criterion without interpretation. If a statement is subjective, rewrite it into a measurable outcome.
44
45	## Output Contract
46
47	Use `references/TEMPLATE.md` as the output format. A complete response should:
48
49	- Restate the feature or story context
50	- Group criteria into happy path, edge cases, error states, and non-functional criteria
51	- Use explicit Given/When/Then statements for each criterion
52	- Note assumptions or open questions when context is incomplete
53
54	## Quality Checklist
55
56	Before finalizing, verify:
57
58	- [ ] The criteria map to a specific story or feature slice
59	- [ ] The happy path is covered first
60	- [ ] Edge cases are explicit, not implied
61	- [ ] Error states include user-visible recovery behavior
62	- [ ] Non-functional criteria are included when relevant
63	- [ ] Each criterion is testable and has one clear outcome
64	- [ ] No implementation details leak into the acceptance criteria
65
66	## Examples
67
68	See `references/EXAMPLE.md` for a completed example based on a realistic e-commerce checkout flow.

People who liked this also viewed

6 picks

Type

deliver-acceptance-criteria

486stars64forks

View on GitHub

How to install deliver-acceptance-criteria?

product-on-purpose/pm-skills/deliver-acceptance-criteria

$npx -y skills add product-on-purpose/pm-skills --skill deliver-acceptance-criteria

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Acceptance Criteria
3
4	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.
5
6	## When to Use
7
8	- After a user story, PRD section, or feature slice is defined
9	- When a team needs clear pass/fail conditions for implementation
10	- When writing QA-ready criteria for sprint planning or handoff
11	- When a story has edge cases, error paths, or non-functional expectations that should be explicit
12
13	## When NOT to Use
14
15	- You need the user stories themselves -> use `deliver-user-stories`; this skill deepens a story that already exists
16	- You need systematic failure coverage across a whole feature -> use `deliver-edge-cases`; this skill stays story-scoped
17	- There is no story or slice to bind criteria to yet -> use `deliver-prd` or `deliver-user-stories` first
18	- You are defining success metrics for an experiment, not done-ness for a story -> use `measure-experiment-design`
19
20	## Instructions
21
22	When asked to create acceptance criteria, follow these steps:
23
24	1. Confirm the story or feature scope
25	Identify the exact slice of work. If the scope is unclear, ask for the user story, PRD section, or feature description before drafting criteria.
26
27	2. Separate the happy path from exceptions
28	Start with the primary success flow, then add edge cases and error states that are likely or costly if missed.
29
30	3. Write each criterion as an observable scenario
31	Use Given/When/Then language only. Keep each criterion independently testable and avoid implementation details.
32
33	4. Cover recovery and failure behavior
34	Describe what the user sees or can do when validation fails, a dependency is unavailable, or a save action cannot complete.
35
36	5. Include non-functional expectations
37	Add criteria for performance, accessibility, security, reliability, or auditability when they matter to the story.
38
39	6. Avoid duplication and overlap
40	Each criterion should test one outcome. If two criteria describe the same behavior, merge or split them until the intent is clear.
41
42	7. Review for testability
43	Ensure a reviewer can pass or fail each criterion without interpretation. If a statement is subjective, rewrite it into a measurable outcome.
44
45	## Output Contract
46
47	Use `references/TEMPLATE.md` as the output format. A complete response should:
48
49	- Restate the feature or story context
50	- Group criteria into happy path, edge cases, error states, and non-functional criteria
51	- Use explicit Given/When/Then statements for each criterion
52	- Note assumptions or open questions when context is incomplete
53
54	## Quality Checklist
55
56	Before finalizing, verify:
57
58	- [ ] The criteria map to a specific story or feature slice
59	- [ ] The happy path is covered first
60	- [ ] Edge cases are explicit, not implied
61	- [ ] Error states include user-visible recovery behavior
62	- [ ] Non-functional criteria are included when relevant
63	- [ ] Each criterion is testable and has one clear outcome
64	- [ ] No implementation details leak into the acceptance criteria
65
66	## Examples
67
68	See `references/EXAMPLE.md` for a completed example based on a realistic e-commerce checkout flow.

People who liked this also viewed

6 picks

Type