gen-gherkin-feature

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