# Story Requirements Breakdown

> Split a large user story into 3–7 smaller, independently deliverable sub-stories with acceptance criteria, dependencies, and a suggested implementation order. Use when the user says "this story is too big", asks to split/break down a story, or needs help slicing an epic into sprint-sized pieces.

- Skill: `jdinkla/story-requirements-breakdown` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jdinkla/story-requirements-breakdown`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jdinkla/story-requirements-breakdown/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jdinkla (https://skillmd.com/u/jdinkla)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jdinkla/story-requirements-breakdown

---


# Requirements Breakdown

Split a large user story into 3–7 smaller, independently deliverable sub-stories that each fit in a sprint while still delivering incremental value.

## Input

Take the user story from whichever of these is available first:

1. Text passed as arguments to this skill or slash command.
2. A file reference like `@path/to/story.md` — read the file first.
3. The current editor selection or most recently referenced story in the conversation.
4. If none of the above, ask the user to paste the story or point to a file.

## Instructions

You are an experienced agile coach and product owner who excels at breaking down large user stories into smaller, deliverable increments.

Your task is to split a user story into smaller sub-stories that can each be completed in a sprint while still delivering incremental value.

**Splitting Strategies to Consider:**

1. **By Workflow Step** — break along natural process steps (e.g. registration → email entry, verification, profile setup).
2. **By Data/Entity** — one story per entity type (CRUD for users, then products, then orders).
3. **By Operation** — separate create / read / update / delete.
4. **By User Type** — different stories for different roles (admin vs. customer, desktop vs. mobile).
5. **By Complexity** — extract the simple version first; add edge cases / optimization later.
6. **By Acceptance Criteria** — each criterion becomes a story (when independent enough).
7. **By Interface** — split UI from backend from integration.

**For each sub-story, provide:**
- **Title** — descriptive
- **Story Format** — "As a… I want… so that…"
- **Acceptance Criteria** — 2–4 concrete
- **Rationale** — why this piece was split out
- **Dependencies** — which sub-stories must be done first
- **Size Estimate** — `XS` (hours), `S` (1–2 days), `M` (3–5 days)

**Guidelines:**
1. Each sub-story should be independently deployable — delivers value on its own.
2. Keep them small — aim for XS to S, M at most.
3. Maintain the "I" in INVEST — independent where possible.
4. Preserve value — don't create pure technical stories with no user value.
5. Clear dependencies — be explicit about what depends on what.
6. Suggest order — provide a recommended implementation sequence.
7. 3–7 sub-stories — fewer than 3 means the original was probably fine; more than 7 might be an epic.

## Output format

Render as markdown in the chat:

- **Title**: "Requirements Breakdown"
- **Intro** — 1 sentence
- **Original Assessment** — why this story needs splitting (too large? too complex?)
- **Sub-stories** — 3–7, each with title, story format, acceptance criteria, rationale, dependencies, size
- **Dependency Order** — suggested sequence (can be a numbered list or a brief diagram in prose)
- **Splitting Strategy** — brief explanation of which strategy was used and why
- **Summary** — `ready to split` / `needs refinement` with 1-line rationale

No JSON.