User Story Generator

---
description: Generate user stories with acceptance criteria from a feature description
allowed-tools: Read, Glob, Grep
---

# User Story Generator

Analyze existing code patterns and generate a comprehensive set of user stories for a feature, complete with acceptance criteria, edge cases, and technical notes.

The feature to generate stories for: $ARGUMENTS

## Steps

1. **Understand the product context**:
   - Read `README.md` for the product overview.
   - Glob for existing user-facing routes, pages, or commands to understand the product surface.
   - Grep for existing user roles, permissions, or persona references (`admin`, `user`, `owner`, `member`, `guest`).

2. **Analyze existing patterns**:
   - Grep for existing test files to understand how the team describes behavior.
   - Glob for `**/stories/**`, `**/features/**`, `**/specs/**` to find existing user story formats.
   - Grep for validation patterns, error handling, and edge case handling in related code.
   - Identify the authentication/authorization model to understand access levels.

3. **Identify personas** relevant to the feature:
   - Extract roles from the codebase (code-defined roles, not assumed ones).
   - For each role, describe their goals and context.
   - If no roles are found, default to: End User, Admin, and API Consumer.

4. **Generate Epic**:
   Write an epic-level story that captures the overall feature:
   ```
   Epic: [Feature Name]
   As a [primary persona],
   I want [high-level capability],
   So that [business outcome].
   ```

5. **Break down into User Stories**:
   For each story, provide:

   ```
   Story [number]: [Title]
   As a [persona],
   I want [specific action],
   So that [specific benefit].

   Acceptance Criteria:
   - GIVEN [context] WHEN [action] THEN [outcome]
   - GIVEN [context] WHEN [action] THEN [outcome]
   - GIVEN [context] WHEN [action] THEN [outcome]

   Edge Cases:
   - What happens when [boundary condition]?
   - What happens when [error state]?
   - What happens when [concurrent access]?

   Technical Notes:
   - Relevant existing code: [file paths]
   - Dependencies: [other stories or systems]
   - Estimated complexity: S / M / L
   ```

   Generate stories for:
   - **Happy path**: The primary use case.
   - **Permissions**: Access control for each persona.
   - **Validation**: Input validation and error states.
   - **Notifications**: Any events that should trigger communication.
   - **Bulk/batch**: If applicable, handling multiple items.
   - **Mobile/responsive**: If the product has a UI.

6. **Generate a story map** showing the relationship between stories:
   - Which stories must be built first (dependencies).
   - Which can be parallelized.
   - Suggested sprint groupings (MVP, V1, V2).

7. **Add a definition of done** checklist based on the project's patterns:
   - Grep for CI configuration, test requirements, and review processes.
   - Include items like: unit tests, integration tests, documentation, accessibility, etc.

## Rules

- Base personas on roles actually found in the code, not assumptions.
- Acceptance criteria must be testable — use GIVEN/WHEN/THEN format.
- Edge cases should reference real constraints found in the code (e.g., actual field length limits, existing validation rules).
- Technical notes should reference actual file paths where related logic exists.
- If $ARGUMENTS is vague, ask clarifying questions before generating stories.
- Aim for 6-12 stories per feature — enough to be comprehensive, not so many as to be overwhelming.