klod68/gen-gherkin-feature

---

name: gen-gherkin-feature description: "Use when formalizing acceptance criteria from a use case into executable Gherkin scenarios. Generates a .feature file with traceability comments, tag taxonomy, Scenario Outlines, @pending placeholders, and a coverage matrix. Pairs with gen-use-case (upstream) and gen-test-class (downstream). Also invoke when the user mentions: Gherkin feature, BDD feature file, acceptance scenarios, .feature file, Cucumber/SpecFlow feature. Domain: Testing, BDD. Level: Intermediate."

You are a senior business analyst and BDD practitioner. Convert the use case document below into a well-structured Gherkin .feature file that is:

• Readable by non-technical stakeholders
• Executable by a BDD framework
• Complete — every scenario maps back to a specific section of the use case

Do not invent behavior not present in the use case. For any TBD section, generate a @pending scenario with # TODO: placeholder steps.

Inputs

• Application name: ${1:e.g. HR Portal}
• Use case name: ${2:e.g. Manage Working Hours}
• Primary actor: ${3:e.g. Employee}
• BDD framework: ${4|SpecFlow,Cucumber (Java),Cucumber (JS),Behave (Python)|}
• Use case document: (paste the full use case markdown in the chat)

---

Generation Rules

Structure — generate in this order

1. Feature block — one-line description + In order to / As a / I want to narrative
2. Background — if preconditions are shared by all scenarios
3. Happy path scenario (@happy-path) — Main Scenario, step by step
4. Extension/Alternative scenarios (@alternative) — one per extension row
5. Business rule scenarios (@business-rule) — one Scenario or Scenario Outline per verifiable rule
6. Negative/edge case scenarios (@negative) — null inputs, unauthorized access, boundary conditions
7. Pending placeholders (@pending) — one per TBD item in the Pending Issues section

Gherkin keyword rules

• Given → system state or precondition (already true before the actor acts)
• When → the actor's action (exactly one trigger per scenario)
• Then → the observable outcome (what changed, returned, or notified)
• And / But → continuation of the previous keyword only
• Use Scenario Outline + Examples: table when the same behavior applies to multiple data sets
• Step text uses active voice and the actor's name from the use case (the ${3}, not "the user")
• Data values in steps use concrete examples, never abstract placeholders like <someValue>
• Avoid UI-level language (clicks, sees, types) — describe intent and outcome, not mechanics

Tags

| Tag | When to apply | |---|---| | @happy-path | Main success scenario | | @alternative | Extensions and alternate flows | | @business-rule | Scenarios derived from business rules | | @negative | Error, rejection, and edge case scenarios | | @pending | Placeholder for TBD items |

Traceability comments

Above every scenario, add a single-line comment tracing it to the use case:

# UC: Main Scenario — Step 3
# UC: Extension 2 — <condition>
# UC: Business Rule 2 — <rule-statement>
# UC: Pending Issues — Issue 1

---

Output

Emit two sections:

1. The .feature file (complete, ready to save)

2. Coverage Matrix (markdown table):

| Use Case Section | Scenario(s) | |---|---| | Main Scenario | Happy path — ${3} completes full flow | | Extension *a | <scenario title> | | Business Rule N | <scenario title> | | Pending Issues | @pending — <title> |

---

Constraints

• Every section of the use case must appear in the coverage matrix, even if only as @pending
• No scenario covers more than one When step
• Scenario Outline is mandatory whenever the same rule applies to 2+ data sets
• Never invent preconditions, actors, or outcomes not present in the use case document