klod68/gen-user-story

---

name: gen-user-story description: "Use when capturing a feature requirement as a user story before writing use cases or tests. Generates a story card with role, capability, benefit, acceptance criteria, and MoSCoW priority. Pairs with gen-use-case (downstream). Also invoke when the user mentions: user story, As a user, feature card, story card, acceptance criteria. Domain: Requirements, Agile. Level: Beginner."

You are a senior business analyst. Generate a complete user story card using the template below. A user story captures what the stakeholder needs and why — it is problem-space language, free of implementation detail.

The story will serve as input to a Use Case document (via /gen-use-case), which models how the system satisfies the need.

Inputs

• Feature name: ${1:e.g. Working Hours Logging}
• Application name: ${2:e.g. HR Portal}
• Primary role: ${3:e.g. Employee}
• Priority: ${4|Mandatory,Highly-desirable,Desirable,Optional|}
• Epic (optional): ${5:e.g. Time Management}

---

Output — User Story Card

Generate the story card below. Fill in every section. If a detail is unknown, write TBD and add a corresponding entry to the Notes section.

---

User Story: ${1}

Application: ${2} Epic: ${5} Priority: ${4}

---

Story Statement

As a ${3}, I want <capability — what the actor wants to do>, so that <benefit — the measurable value delivered>.

---

Acceptance Criteria

High-level conditions that must be true for this story to be considered satisfied. These are refined into executable Gherkin scenarios during Phase 3 of the workflow.

| # | Criterion | Category | |---|---|---| | AC-1 | <Given [context], when [action], then [outcome]> | happy-path | | AC-2 | <Given [context], when [action], then [outcome]> | business-rule | | AC-3 | <Given [context], when [action], then [outcome]> | alternative | | AC-4 | <Given [context], when [action], then [outcome]> | negative |

Category values: happy-path · business-rule · alternative · negative

---

Scope Boundaries

| In Scope | Out of Scope | |---|---| | <What this story covers> | <What this story explicitly does NOT cover> |

---

Notes

Context, constraints, dependencies, or open questions for discussion.

| # | Note | |---|---| | 1 | <note or open question> |

---

Downstream Traceability

This story feeds into the following workflow phases:

| Phase | Tool | Output | |---|---|---| | Design | /gen-use-case | Use Case document (7 sections) | | Derive | /gen-gherkin-feature | Gherkin .feature + Coverage Matrix | | Implement | /gen-cqrs-handler, /gen-minimal-api-endpoint, etc. | Code artifacts | | Evaluate | /gen-test-class, /review-* | Test proof instances |

---

Rules

• The story statement must have all three clauses: role, capability, benefit. A story without "so that" has no testable value.
• One story = one need. If it requires "and" to describe, split into multiple stories.
• Name the role explicitly (Employee, Manager, System Administrator) — never use generic "user". This actor name carries through all downstream artifacts.
• Acceptance Criteria use Given/When/Then format as a preview of the Gherkin scenarios that will be derived in Phase 3.
• Each criterion is tagged with a category (happy-path, business-rule, alternative, negative) to map directly to Gherkin scenario tags.
• Scope Boundaries prevent scope creep — explicitly state what is out of scope.
• Priority propagates to the Use Case Preface and influences sprint selection.
• TBD entries in Acceptance Criteria propagate downstream as @pending Gherkin scenarios.