Turn a request into Given/When/Then scenarios that pin behaviour before anyone writes production code. Use when a change needs a definition of done, when a ticket is vague, or before a TDD slice starts.
--- name: write-acceptance-scenarios category: coding description: >- Turn a request into Given/When/Then scenarios that pin behaviour before anyone writes production code. Use when a change needs a definition of done, when a ticket is vague, or before a TDD slice starts. --- # Write Acceptance Scenarios A request is not a spec. "Add an extra arrow" is a wish. A scenario is a contract: a starting world, one action, and a check that would fail if the work were wrong. Write those first. Implementation that starts without them is guessing with extra steps, and the review that follows is an argument about what was meant. ## The shape One scenario, one behaviour. Name it after the outcome, not the ticket. ``` Scenario: Extra arrow survives a same-setup replay Given a board with the extra arrow already placed When the same setup is replayed Then the extra arrow is still there ``` Three lines, and they are load-bearing: - **Given** is the world before the action. Everything the check depends on lives here. If a later step needs a flag, a user, or a file, it is in Given, not hidden in When. - **When** is one action. Not a sequence of setup disguised as the action. If you need two actions, you have two scenarios, or you have not finished Given. - **Then** is a check a stranger could run. "It works" is not a check. "The extra arrow is still there" is, if "there" has a precise meaning in this system.
You are reading the opening of this skill.
The rest is open to any signed-in account — free included. Reading the library costs nothing.
Shared publicly by the author and open for any use. See the Terms.