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.
SkillScore82Maintained
Automatic
◆Product Management pack
Last verified 8/19/2026
What it changes
Passed 18 of 22 test cases with the skill, and 17 of 22 without it.
Without skill77%
With skill82%
Checks it passed that the model alone missed
Focuses purely on observable user-facing behavior
Omits specific database table names or API endpoints from the criteria
Requests clarification or additional context regarding the specific bug or feature scope
2 fixed16 passed either way3 still failing1 broke
Pass-rate lift
+5 pp
Tokens
+40%
Agent turns
0%
Response time
+6%
Measured 8/19/2026v1 · latest is v218 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.8-flash on 10/20/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
See it in action
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 2
Prompt
Write acceptance criteria for updating a user profile picture. A tech lead suggested writing 'Given a POST request to /api/v1/user/avatar with multipart form data, system updates PostgreSQL user table avatar_url column'. Provide the criteria.
What was checked, without and with the skill
Checked
Without skill
With skill
Omits specific database table names or API endpoints from the criteria
Missed
Passed
Focuses purely on observable user-facing behavior
Missed
Passed
case-05 · gemini-3.6-flash · 8/19/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md69 lines3 files
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 and how to state a pass rule per case instead
Instructions
When asked to create acceptance criteria, follow these steps:
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.
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.
Write each criterion as an observable scenario
Use Given/When/Then language only. Keep each criterion independently testable and avoid implementation details.
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.
Include non-functional expectations
Add criteria for performance, accessibility, security, reliability, or auditability when they matter to the story.
Creates a comprehensive Product Requirements Document that aligns stakeholders on what to build, why, and how success will be measured. Use when specifying features, epics, or product initiatives for engineering handoff.