Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Generates user stories in the standard persona, action, benefit story format from product requirements or feature descriptions. Use when breaking a feature into stories for sprint planning, writing tickets, or communicating scope to engineering. For testable Given/When/Then acceptance criteria on a story, use deliver-acceptance-criteria; for boundary and failure scenarios, use deliver-edge-cases.
.claude/skills/product-on-purpose-deliver-user-stories/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 1% | 0% |
| case-02 | ✗→✓ | ▲ Improved | -13% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 33% | 0% |
| case-04 | ✗→✓ | ▲ Improved | 220% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 79% | 0% |
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
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.
deliver-acceptance-criteriadeliver-edge-casesdeliver-prd first; stories should trace back to documented requirementsiterate-refinement-notesWhen asked to create user stories, follow these steps:
Review the PRD or feature description. Understand the overall goal, target users, and scope boundaries. User stories should trace back to documented requirements.
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.
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.
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.
Write specific, testable criteria using Given/When/Then format. Acceptance criteria define "done" - if all criteria pass, the story is complete.
Validate each story against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Revise stories that don't meet these criteria.
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. 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.
Before finalizing, verify:
See references/EXAMPLE.md for a completed example.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-10 | pass→pass | 9,846 | 5,566 | -43% | 1 | 1 | 0% | 1,546 | 1,579 | +2% | 0 | 0 | — |
case-01 | fail→pass | 21,029 | 17,822 | -15% | 1 | 1 | 0% | 3,613 | 3,646 | +1% | 0 | 0 | — |
case-02 | fail→pass | 26,254 | 16,958 | -35% | 1 | 1 | 0% | 4,201 | 3,644 | -13% | 0 | 0 | — |
case-03 | fail→pass | 20,158 | 20,618 | +2% | 1 | 1 | 0% | 3,108 | 4,148 | +33% | 0 | 0 | — |
case-04 | fail→pass | 5,748 | 15,125 | +163% | 1 | 1 | 0% | 1,097 | 3,515 | +220% | 0 | 0 | — |
case-05 | fail→pass | 12,810 | 19,940 | +56% | 1 | 1 | 0% | 2,279 | 4,074 | +79% | 0 | 0 | — |
case-06 | fail→fail | 6,749 | 13,355 | +98% | 1 | 1 | 0% | 1,156 | 3,056 | +164% | 0 | 0 | — |
case-07 | fail→pass | 1,687 | 12,032 | +613% | 1 | 1 | 0% | 253 | 2,775 | +997% | 0 | 0 | — |
case-08 | fail→pass | 13,134 | 18,805 | +43% | 1 | 1 | 0% | 2,488 | 4,372 | +76% | 0 | 0 | — |
case-09 | fail→pass | 24,203 | 3,286 | -86% | 1 | 1 | 0% | 3,484 | 1,268 | -64% | 0 | 0 | — |
case-11 | pass→pass | 3,080 | 5,414 | +76% | 1 | 1 | 0% | 474 | 1,575 | +232% | 0 | 0 | — |
case-12 | fail→fail | 2,738 | 13,919 | +408% | 1 | 1 | 0% | 439 | 3,121 | +611% | 0 | 0 | — |
case-13 | fail→fail | 9,469 | 10,551 | +11% | 1 | 1 | 0% | 1,626 | 2,553 | +57% | 0 | 0 | — |
case-14 | fail→pass | 7,631 | 12,699 | +66% | 1 | 1 | 0% | 1,138 | 2,909 | +156% | 0 | 0 | — |
case-15 | fail→pass | 10,993 | 12,970 | +18% | 1 | 1 | 0% | 1,900 | 3,056 | +61% | 0 | 0 | — |
case-16 | pass→pass | 9,042 | 12,922 | +43% | 1 | 1 | 0% | 1,480 | 2,795 | +89% | 0 | 0 | — |
case-17 | fail→pass | 14,786 | 21,360 | +44% | 1 | 1 | 0% | 2,581 | 4,221 | +64% | 0 | 0 | — |
case-18 | fail→pass | 4,502 | 11,495 | +155% | 1 | 1 | 0% | 791 | 2,778 | +251% | 0 | 0 | — |
case-19 | fail→fail | 5,096 | 12,454 | +144% | 1 | 1 | 0% | 922 | 2,933 | +218% | 0 | 0 | — |
case-20 | fail→pass | 5,656 | 10,078 | +78% | 1 | 1 | 0% | 926 | 2,518 | +172% | 0 | 0 | — |
case-21 | fail→pass | 12,837 | 16,099 | +25% | 1 | 1 | 0% | 2,267 | 3,689 | +63% | 0 | 0 | — |
case-22 | fail→fail | 3,338 | 8,636 | +159% | 1 | 1 | 0% | 627 | 2,178 | +247% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +64 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.