User Story Generator Skill

Purpose

Transform PI planning notes, epic breakdowns, and architectural discussions into developer-ready user stories.

User Story Format

Every user story MUST follow this structure:

**Title:** [Action-oriented title]

**User Story:** As a [specific user/role], I want [clear goal/action] so that [measurable business value].

**Acceptance Criteria:**
- GIVEN [precondition] WHEN [action] THEN [expected result]
- [Additional criteria as needed]

**Technical Notes:**
- [Implementation hints from architecture discussions]
- [Dependencies or integrations]

**Definition of Done:**
- [ ] Code complete with unit tests
- [ ] Code reviewed
- [ ] Acceptance criteria verified
- [ ] Documentation updated

**Sizing Estimate:** [S/M/L or story points]
**Parent Epic:** [Link to epic]
**Dependencies:** [Other stories this blocks or is blocked by]

Quality Rules (INVEST Criteria)

1. •Independent - Can be developed without depending on other stories in same sprint
2. •Negotiable - Details can be discussed, not a contract
3. •Valuable - Delivers clear value to user or business
4. •Estimable - Team can estimate effort required
5. •Small - Completable within one sprint (break down if larger)
6. •Testable - Clear pass/fail acceptance criteria

Transformation Rules

From Epic Notes → User Stories

1. •Identify distinct user actions or capabilities in the epic
2. •Each capability = potential user story
3. •If capability spans multiple user types, split into separate stories
4. •Extract technical constraints mentioned in architect notes

From Architecture Notes → Technical Context

1. •Pull integration points into Dependencies
2. •Extract non-functional requirements into Acceptance Criteria
3. •Note technology choices in Technical Notes

Sizing Guidelines

• •S (1-2 pts): Single component, clear implementation path
• •M (3-5 pts): Multiple components or some unknowns
• •L (8+ pts): Consider breaking down further

Anti-Patterns to Avoid

• •❌ Vague acceptance criteria ("system should be fast")
• •❌ Multiple features in one story
• •❌ Technical tasks disguised as user stories
• •❌ Missing "so that" (business value)
• •❌ Implementation details in the user story statement