agentleFS
patonkikhpatonkikh/APES/skills/product/user-story-generator/skill.md

user-story-generator

Skill3 starsChanged 4 months agoMITView on GitHub

Generate INVEST-compliant user stories from epics or requirements with clear value statements and story point guidance. Use when working on product discovery, PRDs, user stories, OKRs, or backlog planning.

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Leave acceptance criteria to acceptance-criteria-generator.

    line 110

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
skill.md

User Story Generator

Purpose

Generate INVEST-compliant user stories from epics or requirements with clear value statements and story point guidance.

Input: Epic description, story themes, or FR list; persona (optional)
Output: User story set with IDs, INVEST validation, and dependency notes Examples: See examples.md for worked input/output.


Workflow

Step 1: Identify story sources

Extract story candidates from:

  • Epic story themes
  • PRD functional requirements
  • User flows (one story per flow step if appropriate)

Step 2: Write stories in standard format

As a [persona] I want [action] so that [benefit]

Each story must:

  • Reference a specific persona (not "user")
  • Describe desired behavior, not implementation
  • State measurable benefit in "so that" clause

Step 3: Apply INVEST criteria

CriterionCheck
IndependentCan be developed without other stories
NegotiableDetails open for discussion
ValuableDelivers user or business value
EstimableTeam can estimate size
SmallCompletable in one sprint
TestableAcceptance criteria can be written

Flag stories failing any criterion with fix recommendation.

Step 4: Assign metadata

For each story:

  • ID: US-001, US-002...
  • Epic reference
  • Priority: Must / Should / Could
  • Size hint: S / M / L (not hours)
  • Dependencies: other story IDs

Step 5: Validate

Run Validation checklist.


Decision Rules

ConditionAction
Story describes implementationRewrite as user behavior
Story too large (fails Small)Split into multiple stories
Story has no personaUse persona from input or request one
"So that" is vagueRewrite with measurable outcome
Stories are not independentDocument dependency; consider merge or reorder

Validation

  • All stories follow As/Want/So format
  • INVEST check completed for each story
  • Each story has unique ID and epic reference
  • No implementation details in story text
  • Dependencies explicitly documented
  • Size hints provided (S/M/L)
  • Stories failing INVEST have fix notes

Anti-patterns

  • Technical stories as user stories — "As a developer I want to set up Redis."
  • Epic-sized stories — "As a user I want the entire dashboard."
  • No benefit clause — missing or generic "so that I can use the app."
  • Generic persona — "As a user" without specificity.
  • Untestable stories — no observable behavior to verify.

Best Practices

  • One story = one testable behavior change.
  • Split by workflow step, not by technical layer.
  • Align stories with epic goal; reject orphan stories.
  • Leave acceptance criteria to acceptance-criteria-generator.
  • Group related stories under epic headers in output.

Output Structure

# User Stories: [Epic Name]

## Epic Reference
[Epic goal and ID]

## Stories

### US-001: [Short title]
**As a** [persona] **I want** [action] **so that** [benefit]

| Attribute | Value |
|-----------|-------|
| Priority | Must |
| Size | M |
| Dependencies | none |
| INVEST | Pass / Fail (note) |

[Repeat for each story]

## Dependency Map
US-001 → US-003

## Stories Needing Split
| Story | Issue | Suggested split |
|-------|-------|-----------------|

Next Skills

OutcomeRecommended Skill
Add acceptance criteriaproduct/acceptance-criteria-generator
Visualize story sequenceproduct/story-mapping
Need epics firstproduct/epic-generator
Sprint planningproduct/acceptance-criteria-generator

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.