deliver-user-stories
The deliver-user-stories Claude Code skill breaks down product features into user-focused stories in persona-action-benefit format, each with testable acceptance criteria in Given/When/Then structure. Use this during sprint planning, ticket creation, or stakeholder communication after PRD approval to create estimable, independently deliverable work items that maintain focus on user value.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/deliver-user-stories && cp -r /tmp/deliver-user-stories/skills/deliver-user-stories ~/.claude/skills/deliver-user-storiesSKILL.md
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> # User Stories 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 to Use - After PRD approval, when breaking down features for implementation - During sprint planning to create actionable work items - When writing tickets for engineering teams - When communicating requirements to stakeholders in accessible terms - When prioritizing a backlog based on user value ## When NOT to Use - You need deeper, QA-ready Given/When/Then coverage for a single story or slice -> use `deliver-acceptance-criteria` - You need the feature-wide catalog of boundary conditions and failure scenarios -> use `deliver-edge-cases` - The feature itself is not yet specified -> use `deliver-prd` first; stories should trace back to documented requirements - You want refinement-session outcomes (estimates, scope decisions, open questions) -> use `iterate-refinement-notes` ## Instructions When asked to create user stories, follow these steps: 1. **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. 2. **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. 3. **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. 4. **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. 5. **Define Acceptance Criteria** Write specific, testable criteria using Given/When/Then format. Acceptance criteria define "done" - if all criteria pass, the story is complete. 6. **Apply INVEST Criteria** Validate each story against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Revise stories that don't meet these criteria. 7. **Add Context and Notes** Include relevant design references, technical considerations, and dependencies. These help implementers understand the full picture. ## Output Format Use the template in `references/TEMPLATE.md` to structure the output. A complete output carries, per story: Story Header; User Story Statement; Context & Background; Acceptance Criteria; Design Notes; Technical Notes; Dependencies; Out of Scope; and Open Questions where any remain. Multi-story documents nest these sections under one heading per story, as the example shows. ## Quality Checklist Before finalizing, verify: - [ ] Each story follows "As a... I want... so that..." format - [ ] Stories are independent (can be built in any order) - [ ] Acceptance criteria use Given/When/Then format - [ ] Each criterion is testable (someone can verify pass/fail) - [ ] Stories are small enough to complete in one sprint - [ ] No implementation details in the story statement - [ ] Benefit clause explains why this matters to the user ## Examples See `references/EXAMPLE.md` for a completed example.
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.