write-speclisted

# write-spec - write a Gherkin .feature file A Gherkin `.feature` file describes a feature's behaviour in a structured, human-readable format executable by a BDD test runner (Cucumber, SpecFlow, Behave, pytest-bdd, godog, etc.). It captures: - **What** the feature does, from the user's perspective. - **Who** uses it and **why**. - **Concrete scenarios** with `Given` / `When` / `Then` steps. - **Edge cases and error paths**, not just the happy path. A good spec doubles as documentation and test plan. A bad spec reads like documentation and tests nothing - usually because scenarios are vague ("user does the thing" rather than "user enters '12345' and clicks 'Submit'"). This skill discovers the repo's conventions, discusses the feature with the user to draw out scenarios, then writes the `.feature` file in proper Gherkin. ## Phase 0 - Find existing specs Hunt for the specs folder. Don't assume a path; the repo will tell you. ```bash # Common spec folder locations. for d in specs features test/features tests/features spec/features; do if [ -d "$d" ]; then echo "$d"; fi done # Fallback: search for .feature files directly. fd --type f --extension feature . | head -20 ``` If you find existing `.feature` files, **read 2-3 of them** to extract the convention: - Where do they live? (Use the same directory.) - What's the naming pattern? (`order-cancellation.feature`, `OrderCancellation.feature`, `cancel_order.feature`?) - Do they have a `Feature:` narrative ("As a … I want