Story splitter

Skill ramanbamba/10x-pm/skills/story-splitter

Prompts don't compound. Skills do. The open-source AI toolkit for product managers — 13 Claude Code skills + 3 red-team agents for the full PM workflow.

Install

npx -y skills add ramanbamba/10x-pm --skill story-splitter

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Split an epic, feature, or PRD into user stories with acceptance criteria, sized for iterative delivery. Use when the user says "split this epic", "break this down into stories", "write user stories", "acceptance criteria for", or shares a spec that needs to become a sprint-ready backlog.

SKILL.md

3.1 KB, as published. Nobody here has run it

Story Splitter

Split epics so every story ships a testable slice of user value — vertical slices through the stack, never horizontal layers.

Before splitting

Confirm the source (epic, PRD, or verbal description) and read it fully.
Ask which story the team should ship first to learn the most — splitting is sequencing, not just decomposition.
Ask about acceptance criteria format preference: Given/When/Then (Gherkin) or checklist. Default to Gherkin for behavior-heavy stories, checklist for content/config work.

Workflow

Identify the walking skeleton — the thinnest end-to-end path through the feature that a real user could use. That's story #1, always.
Split the rest using these patterns (in order of preference):
- By workflow step (browse → select → pay → confirm)
- By business-rule variation (domestic first, international later)
- By data variation (one file type first)
- By operations (CRUD: create first, edit/delete later)
- By quality dimension (works first, fast later — only when explicit) Never split by architectural layer ("build the API", "build the UI") — those aren't shippable.
INVEST-check each story: Independent, Negotiable, Valuable, Estimable, Small (≤ a few days), Testable. Rewrite violators.
Write acceptance criteria covering the happy path, the most likely failure, and the empty/edge state. 3–7 criteria per story; more means the story is too big.
Flag dependencies and unknowns — mark stories blocked by decisions or external teams, and propose a spike (time-boxed, question-shaped) where genuine unknowns exist.

Output format

# Story map — [epic name]
**Source:** [doc] · **First slice rationale:** [why story 1 is first]

## Sequence
[Ordered list: story titles with size guess (S/M/L) and dependency flags]

## Stories
### 1. [Title — verb phrase of user value]
**As a** [user], **I want** [action] **so that** [outcome].
**Acceptance criteria:**
- Given [context], when [action], then [result]
- Given [failure context], when [action], then [graceful behavior]
- Given [empty/edge state], then [behavior]
**Out of scope:** [what this story explicitly defers]
**Depends on:** [story #s or external, or "—"]

## Spikes
[Question · time-box · what decision it unblocks]

## Deferred
[Slices consciously pushed past v1, so they're a decision, not an accident]

Quality bar — self-check

Story 1 is end-to-end usable. If nothing ships value until story 5, the split failed.
No layer stories. "Build the database schema" is a task inside a story, not a story.
Every story's "so that" names a real outcome — if you can't fill it honestly, question the story.
Failure and empty states have criteria, not just happy paths.
Each story ≤ a few days of work. When in doubt, split again.