User Story & Acceptance Criteria Guide

Convert this feature request into user stories.

FEATURE REQUEST:
[Paste the raw requirement, email, or stakeholder request here]

CONTEXT:
- Product: [Your product name and type]
- Target users: [Who will use this feature]
- Current state: [What exists today, if anything]
- Sprint capacity: [How many story points/days available]

OUTPUT REQUIREMENTS:
1. Break into multiple stories if the feature is too large
2. Each story must follow "As a... I want... So that..." format
3. Include acceptance criteria in Given/When/Then format
4. Validate each story against INVEST criteria
5. Flag any assumptions that need stakeholder clarification

CONSTRAINTS:
- Stories should be completable in 1-3 days
- Prioritize by user value, not technical dependency
- Mark any technical enablers separately (not as user stories)

Generate acceptance criteria for this user story.

USER STORY:
[Paste your user story here]

CONTEXT:
- Platform: [web, mobile, API, etc.]
- User type: [permissions, role, experience level]
- Integration points: [other systems this touches]

GENERATE:
1. Happy path scenarios (Given/When/Then)
2. Error handling scenarios
3. Edge cases and boundary conditions
4. Performance criteria (if applicable)
5. Accessibility requirements
6. Security considerations

FORMAT:
Use Gherkin syntax (Given/When/Then) for each scenario.
Group scenarios by: Happy Path, Error Handling, Edge Cases.

ALSO INCLUDE:
- Out of scope items (what this story does NOT include)
- Dependencies on other stories or systems
- Test data requirements

Identify edge cases for this user story.

USER STORY:
[Paste your user story here]

CONTEXT:
- User types: [different roles, permissions, experience levels]
- Data constraints: [limits, formats, required fields]
- Environment: [browsers, devices, network conditions]
- Integrations: [third-party services, APIs]

FIND EDGE CASES FOR:
1. Input boundaries (empty, max length, special characters)
2. Timing issues (slow network, timeouts, concurrent actions)
3. State transitions (interrupted flows, back button, refresh)
4. Permissions (unauthorized access, expired sessions)
5. Data edge cases (duplicates, null values, Unicode)
6. Error recovery (retry logic, partial failures)

OUTPUT FORMAT:
For each edge case:
- SCENARIO: [Brief description]
- TRIGGER: [How a user might encounter this]
- EXPECTED BEHAVIOR: [What should happen]
- RISK IF MISSED: [Impact of not handling this]

Prioritize by likelihood and impact.

Split this large user story into smaller, deliverable stories.

ORIGINAL STORY:
[Paste the large story here]

CONSTRAINTS:
- Each story must be completable in 1-3 days
- Each story must deliver user-visible value (no "backend only" stories)
- Stories should be independently deployable when possible
- Maintain a logical progression users can follow

SPLITTING STRATEGIES TO CONSIDER:
1. By user workflow steps
2. By data variations (CRUD operations)
3. By user roles or permissions
4. By platform (web first, then mobile)
5. By business rules (simple case first, then exceptions)
6. By acceptance criteria (each criterion becomes a story)

OUTPUT:
For each split story:
1. User story in standard format
2. Brief acceptance criteria
3. Dependencies on other stories (if any)
4. Value delivered independently

Also provide:
- Recommended implementation order
- Which stories could be parallel vs sequential
- MVP subset (minimum stories for usable feature)