gherkin-scenario-writinglisted

# Writing Gherkin scenarios ## Overview A Gherkin scenario is a worked example of one rule, written so that the person who asked for the behaviour can confirm it is the behaviour they wanted. It happens to be executable. That order matters: readable first, automated second. A scenario nobody outside the delivery team can read has lost the only advantage it had over a plain unit test. Every rule below exists to protect that readability. ## When to use this skill Reach for it when the task is to produce or revise scenario text: - Turning a story, ticket, or acceptance criteria into a `.feature` file. - Adding scenarios to an existing feature. - Rewriting a scenario that reads like a click-by-click script. - Deciding between a `Scenario` and a `Scenario Outline`. - Choosing what belongs in `Background` and what does not. If the examples themselves are not agreed yet, the input is still a vague requirement. Find the examples first, then come back here to phrase them. If the task is judging feature files that already exist, use the review skill instead. This skill writes; that one critiques. ## The shape of a scenario Three moves, in order, and nothing else: - `Given` establishes the state the world is already in. It is a fact, not an action the actor performs. Prefer the past or a state of being. - `When` is the single action under test. One per scenario, always. - `Then` states an outcome the person who asked can observe and check. ```gherkin Scenario: Member with