aico-pm-acceptance-criteria_skill

This skill defines clear, testable acceptance criteria using Given/When/Then to guide QA and ensure verifiable completion.
  • TypeScript

0

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill yellinzero/aico --skill aico-pm-acceptance-criteria

  • SKILL.md2.5 KB

Overview

This skill defines clear, testable acceptance criteria using Given/When/Then (Gherkin) format so stories can be validated directly by QA or automated tests. It produces happy-path scenarios, edge cases, and error conditions that are independently verifiable. The output is structured for immediate use in test plans and story descriptions.

How this skill works

It inspects the user story or feature description, extracts success conditions, and creates one or more Given/When/Then scenarios for each situation. The skill prioritizes happy paths, then adds validation, error handling, performance, and accessibility edge cases. Every criterion is phrased to be unambiguous and independently testable.

When to use it

  • When a user asks for "acceptance criteria", "AC", or "test criteria"
  • When someone asks "how do we know it's done?" or "what counts as complete?"
  • When a user story lacks testable success conditions
  • When QA needs test scenarios or test cases
  • When running /pm.plan and AC must be added to stories
  • When reviewing stories where acceptance criteria are missing or vague

Best practices

  • Start with a single clear user story and its primary success path
  • Write one Given/When/Then per distinct scenario to keep tests independent
  • Use concrete data and measurable expectations (counts, timestamps, response times)
  • Include validation, error, performance, and accessibility edge cases
  • Avoid implementation details; describe observable behavior only
  • Verify each criterion can be executed and results observed by QA or automation

Example use cases

  • Convert a user login story into Gherkin scenarios: successful login, invalid password, locked account
  • Produce AC for a file upload feature: valid file, oversized file, unsupported format, interrupted upload
  • Add acceptance criteria to an API endpoint: correct response, validation errors, timeouts, rate limiting
  • Create AC for an e-commerce checkout: successful purchase, payment failure, inventory shortage
  • Draft testable done criteria for a UI component including accessibility checks and performance thresholds

FAQ

Yes. Include explicit, measurable performance expectations (for example: "Then the page responds within 300ms under 95% of requests") using Given/When/Then format.

How many scenarios should I create per story?

Start with the happy path, then add 2–5 edge and error scenarios as needed so each important behavior is independently testable.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational