From memstack
Generates prioritized user stories with Given/When/Then acceptance criteria, story point estimates, epic story mapping, and MoSCoW prioritization for sprint planning and backlogs.
npx claudepluginhub cwinvestments/memstack --plugin memstackThis skill uses the workspace's default tool permissions.
*Produces prioritized user stories with Given/When/Then acceptance criteria, story point estimates, story mapping across epics, and MoSCoW prioritization for sprint planning.*
Generates user stories with clear acceptance criteria from product requirements or feature descriptions. Use for sprint planning, writing tickets, or communicating requirements to engineering.
Writes user stories from user perspective with acceptance criteria. Use for Agile backlog creation, sprint planning, requirement breakdown, and defining done.
Provides user story templates using As-a/I-want/So-that format, Given-When-Then acceptance criteria, story splitting, and INVEST criteria for agile backlog refinement and requirements definition.
Share bugs, ideas, or general feedback.
Produces prioritized user stories with Given/When/Then acceptance criteria, story point estimates, story mapping across epics, and MoSCoW prioritization for sprint planning.
When this skill activates, output:
User Story Generator — Generating user stories...
Then execute the protocol below.
| Context | Status |
|---|---|
| User says "user stories", "write stories", "backlog" | ACTIVE |
| User says "sprint planning" or "acceptance criteria" | ACTIVE |
| User wants to break work into estimable, assignable stories | ACTIVE |
| User wants a full product requirements document | DORMANT — use PRD Writer |
| User wants a detailed spec for one feature | DORMANT — use Feature Spec |
| Mistake | Why It's Wrong |
|---|---|
| "As a user, I want the system to..." | Stories describe user needs, not system behavior. The "I want to" should be a user action. |
| "Write a story for every edge case" | Edge cases go in acceptance criteria, not separate stories. One story per user intent. |
| "Stories without acceptance criteria" | "Done" becomes subjective. Every story needs testable criteria before sprint planning. |
| "Estimate in hours" | Hours vary by person. Story points measure relative complexity, not calendar time. |
| "50-point stories in the sprint" | If it's bigger than 8 points, split it. Large stories hide unknowns and block the team. |
If the user hasn't provided details, ask:
- Feature/epic — what area are you writing stories for?
- Personas — who are the users? (roles, permissions, experience levels)
- Existing context — is there a PRD, feature spec, or design to reference?
- Sprint goal — what are you trying to ship this sprint?
- Team capacity — how many story points can the team handle? (helps scope)
Group stories under epics (large bodies of work):
## Story Map
### Epic 1: [Epic Name]
**Theme:** [What area of the product this covers]
**Goal:** [What completing this epic achieves]
Stories:
- [ ] US-001: [Story title]
- [ ] US-002: [Story title]
- [ ] US-003: [Story title]
### Epic 2: [Epic Name]
**Theme:** [Theme]
**Goal:** [Goal]
Stories:
- [ ] US-004: [Story title]
- [ ] US-005: [Story title]
Story mapping layout:
User Journey →
┌─────────────────────────────────────────────┐
│ Step 1 │ Step 2 │ Step 3 │
Epics ─────┼─────────────┼─────────────┼─────────────────┤
│ US-001 (M) │ US-003 (M) │ US-006 (M) │ ← Must
│ US-002 (S) │ US-004 (S) │ US-007 (C) │ ← Should/Could
│ │ US-005 (C) │ │
└─────────────┴─────────────┴─────────────────┘
The top row of each column is the minimum to deliver a working user journey. Everything below is enhancement.
Story template:
### US-[ID]: [Short descriptive title]
**As a** [persona/role],
**I want to** [action/capability],
**So that** [benefit/outcome].
**Priority:** [Must / Should / Could / Won't]
**Story points:** [1 / 2 / 3 / 5 / 8]
**Epic:** [Parent epic]
**Dependencies:** [US-XXX or None]
#### Acceptance Criteria
**AC-1: [Happy path]**
Given [precondition]
When [user action]
Then [expected result]
**AC-2: [Validation/error]**
Given [precondition]
When [invalid action or error condition]
Then [error handling behavior]
**AC-3: [Edge case or permission]**
Given [special condition]
When [action]
Then [expected behavior]
#### Notes
- [Design reference, API dependency, or technical consideration]
- [Out of scope for this story: X, Y]
Story writing rules:
Fibonacci scale reference:
| Points | Relative Size | Team Example | Typical Duration |
|---|---|---|---|
| 1 | Trivial | Copy change, config update | Hours |
| 2 | Small | Simple UI component, basic CRUD | 0.5-1 day |
| 3 | Medium | Feature with some logic, API integration | 1-2 days |
| 5 | Large | Complex feature, multiple components | 2-4 days |
| 8 | Very large | Multi-system integration, new architecture | 3-5 days |
| 13 | Epic-level | Should be split into smaller stories | Split it |
Estimation heuristic:
Spike story template:
### US-[ID]: [Spike] Investigate [unknown]
**As a** developer,
**I want to** research [technical question or unknown],
**So that** we can estimate and plan [dependent stories].
**Time box:** [X hours/days]
**Output:** Decision document with recommendation
#### Acceptance Criteria
- [ ] [Specific question 1] is answered
- [ ] [Specific question 2] is answered
- [ ] Recommendation documented for team review
MoSCoW assignment:
| Priority | Stories | Rationale |
|---|---|---|
| Must | US-001, US-003, US-006 | Product doesn't function without these |
| Should | US-002, US-004 | Important for good experience, not blocking |
| Could | US-005, US-007 | Nice to have, include if sprint has capacity |
| Won't | US-008 | Deferred to future sprint |
Value/Effort matrix:
High Value
│
Quick Wins │ Strategic
(Do first) │ (Plan carefully)
────────────────┼────────────────
Fill-ins │ Avoid (for now)
(If time) │ (High cost, low reward)
│
Low Value
Low Effort ──────── High Effort
Place each story on the matrix. Sprint should be loaded with Quick Wins and Strategic items.
Sprint planning output:
## Sprint [X] Backlog — [Sprint Goal]
**Capacity:** [X] story points
**Duration:** [2 weeks]
**Sprint goal:** [One sentence: what we're shipping]
### Committed Stories
| ID | Story | Points | Priority | Assignee | Dependencies |
|----|-------|--------|----------|----------|-------------|
| US-001 | [Title] | 3 | Must | [Name] | None |
| US-003 | [Title] | 5 | Must | [Name] | US-001 |
| US-002 | [Title] | 2 | Should | [Name] | None |
| US-004 | [Title] | 3 | Should | [Name] | US-003 |
| **Total** | | **13** | | | |
### Stretch Goals (if capacity)
| US-005 | [Title] | 2 | Could | — | None |
### Not This Sprint
| US-008 | [Title] | 8 | Won't | — | Needs design |
Sprint planning rules:
# User Stories — [Feature/Epic Name]
## Story Map
[Epic/theme overview from Step 2]
## Stories
### US-001: [Title]
[Full story from Step 3]
### US-002: [Title]
[Full story from Step 3]
[... all stories ...]
## Prioritization
[MoSCoW table from Step 5]
[Value/Effort matrix placement]
## Sprint Backlog
[Sprint planning table from Step 6]
## Definition of Done
- [ ] Code complete and reviewed
- [ ] Unit tests passing
- [ ] Acceptance criteria verified
- [ ] No regressions in existing tests
- [ ] Deployed to staging environment
User Story Generator — Complete!
Epics: [Count]
Total stories: [Count]
Must-have: [Count] ([X] points)
Should-have: [Count] ([X] points)
Could-have: [Count] ([X] points)
Total story points: [X]
Sprint capacity needed: [X sprints]
Next steps:
1. Review stories with the team (estimation poker)
2. Validate acceptance criteria with QA
3. Resolve any dependency blockers
4. Commit to Sprint [X] backlog
5. Create tasks/subtasks in project management tool