abd-acceptance-criteria
abd-acceptance-criteria
Purpose
Build acceptance criteria per story, that explain what must be true when users and systems interact: observable triggers (WHEN), expected outcomes (THEN), chained effects (AND), and explicit negatives (BUT). These act as informal first-draft BDD-style steps that guide downstream scenario work. Focus on interactions using domain terms, avoid implementation detail unless the story is technical, and even then keep it minimal.
This skill is the practice standard for that work: templates for deliverables, rules for what “good” means (atomic AC, actor alternation, domain emphasis, channel-specific detail, source evidence when AC come from documents), and scanners that can run predictable mechanical checks alongside human review.
When to use this skill
Load this skill when any of the following apply:
- You are writing or reviewing
acceptance_criteriaarrays on stories instory-graph.json(exploration phase — not scenario BDD steps). - A user or agent wants to turn interviews, requirements documentation, or informal notes into concrete behavioral AC (WHEN/THEN/AND/BUT).
- You need to document user and system interaction at a finer grain , but still pre-specification / test case level of detail.eg: linear WHEN {action user},THEN {system response}, AND {another system response}, BUT {systems reaction that won't happen}
- An agent is asked to “explore” a story, “write AC”, “harden acceptance criteria”, or “align with exploration rules.”