Use user-story-splitter

Split an epic, feature request, or PRD chunk into independently shippable user stories with testable Gherkin acceptance criteria and a recommended build order

Split an epic, feature request, or PRD chunk into independently shippable user stories with testable Gherkin acceptance criteria and a recommended build order.

Reach for it when Use whenever the user wants to "break this down", turn an epic or PRD into a backlog, slice a feature for sprint planning, or write acceptance criteria for a story.

Install it

npx skilldrop-cli install user-story-splitter                 # Claude Code, your user folder
npx skilldrop-cli install user-story-splitter --project       # Claude Code, this repo
npx skilldrop-cli install user-story-splitter --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Split this epic into user stories"
• "Break this feature down into independently shippable slices"
• "Turn this PRD section into stories with Gherkin acceptance criteria"
• "What's the right build order for these stories?"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Write the product requirements document for this feature"
• "Write the test plan covering these acceptance criteria"
• "Plan the phased rollout of this schema change"

If another skill answers instead, ask for this one by name: "use user-story-splitter".

Check what you get

A good result:

• Every story is demoable to a non-engineer. If the demo is "look at this table in the database", it's a horizontal slice — re-cut it.
• Every acceptance criterion is pass/fail without interpretation. A tester who has never seen the epic can verdict it. ✅ "Then the order total shows the discounted price within 2s" — ❌ "Then the discount works correctly".
• Dependency graph is a chain or shallow tree, never a web. No story depends on more than one other story; if it needs two, the cut is wrong.
• Assumptions are tagged, not embedded. Every default the skill picked appears as a visible [assumption], so planning can challenge it.
• The epic is fully accounted for. Everything in the input is either inside a story or named in "Out of scope / not covered" — no silent drops.

See a worked example

• notifications epic

Use something else when

• The work has no user-visible behavior (pure refactor, dependency bump) — write a task list, not stories
• The story is already small and clear — go straight to feature-implement-loop
• Estimating effort in hours/points — this skill orders and sizes by slice, it does not estimate
• Writing the implementation — hand the story off instead

Where a loop runs it

• Stage shape of the build loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: feature-implement-loop

Edit this page on GitHub · View source