gherkin-discoverylisted

# Discovering examples ## Overview Most bad specifications are not badly written. They are written too early, before anyone knew what the rules were. Discovery is the work of turning a request into a small set of rules, each illustrated by concrete examples, with the disagreements surfaced rather than buried. The output is not Gherkin. It is a list of rules, examples, and open questions. Phrasing comes afterwards, and is much easier once the content is settled. ## When to use this skill - A story or ticket says what someone wants but not what the system should do in each case. - Acceptance criteria exist but are abstract, such as "handles invalid input gracefully". - Two people describe the same feature differently. - Someone asks what the edge cases are. - An estimate is being requested for work nobody can describe precisely. If the examples are already agreed and the task is phrasing them, go straight to the scenario-writing skill. ## The core loop Work through four artefacts, in this order, and keep them visible: 1. **The story.** One sentence naming who wants what, and why. If it cannot be stated in one sentence, it is more than one story. 1. **Rules.** The business constraints that govern it. Each is a complete statement someone could agree or disagree with. 1. **Examples.** For each rule, concrete cases that illustrate it, including at least one where the rule bites. 1. **Questions.** Anything nobody in the room can answer. These are the most va