Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From pm-skills
Generates user stories with acceptance criteria from product requirements or feature descriptions. Use for sprint planning, writing tickets, or communicating requirements to engineering.
npx claudepluginhub product-on-purpose/pm-skills --plugin pm-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/pm-skills:deliver-user-storiesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Breaks PRDs or feature descriptions into implementable user stories with acceptance criteria, priorities, and notes. Use for sprint planning or engineering handoff.
Activate for: user stories, write user stories, story, as a user I want, user story map, story mapping, epic, story breakdown, story splitting, acceptance criteria for stories, BDD, given when then, story refinement, sprint stories, story writing, feature to stories, spec to stories, decompose requirements, break down PRD. NOT for: feature specifications (use official /write-spec), sprint planning (use official /sprint-planning), roadmap planning (use official /roadmap-update).
Generates prioritized user stories with Given/When/Then acceptance scenarios from feature descriptions. Ensures independent testability, clear value, and P1-P3 prioritization.
Share bugs, ideas, or general feedback.
User stories are concise descriptions of functionality from the user's perspective. They capture who needs something, what they need, and why . without prescribing how to build it. Good user stories enable teams to break large features into estimable, deliverable increments while maintaining focus on user value.
When asked to create user stories, follow these steps:
Understand the Feature Context Review the PRD or feature description. Understand the overall goal, target users, and scope boundaries. User stories should trace back to documented requirements.
Identify User Personas Determine which users interact with this feature. Each story should be written for a specific persona, not generic "users." Different personas may need different stories for the same feature.
Break Down by User Goal Decompose the feature into distinct user goals. Each story should deliver a complete, valuable capability . something the user can actually do when the story is done.
Write Story Statements Use the format: "As a [persona], I want [action] so that [benefit]." The benefit clause is critical . it explains why this matters and helps prioritize.
Define Acceptance Criteria Write specific, testable criteria using Given/When/Then format. Acceptance criteria define "done" . if all criteria pass, the story is complete.
Apply INVEST Criteria Validate each story against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Revise stories that don't meet these criteria.
Add Context and Notes Include relevant design references, technical considerations, and dependencies. These help implementers understand the full picture.
Use the template in references/TEMPLATE.md to structure the output.
Before finalizing, verify:
See references/EXAMPLE.md for a completed example.