Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Epic and user story generator

Transforms a high-level feature description into a structured epic with a business objective, plus 8-15 user stories in standard Agile format, each with acceptance criteria, story point estimate, priority, and…

download .md

Purpose

Turn a high-level feature idea into a fully decomposed epic and a set of sprint-ready user stories — each in proper "As a / I want / So that" format with testable acceptance criteria, story points, priority, and dependencies — so a product owner walks out of refinement with a groomed backlog instead of a blank Jira board.

When to Use

Invoke this skill when the user asks to:

  • Break a new feature or initiative into an epic and user stories
  • Write user stories from a product brief, PRD, or feature request
  • Decompose an existing epic into smaller, estimable backlog items
  • Prepare a feature for backlog refinement or sprint planning
  • Generate acceptance criteria for stories that lack them
  • Convert stakeholder requirements into Agile-format tickets

Inputs Required

Before starting, collect:

  • Feature description: 2-5 sentences describing what's being built and why
  • Platform: iOS / Android / Web / Cross-platform / Backend API
  • Primary user personas: Who uses this (e.g., "new user," "returning subscriber," "admin")
  • Business objective: The outcome the feature should drive (retention, conversion, activation, etc.)
  • Known constraints: Technical, compliance, design-system, or timeline limits
  • Estimation scale: Fibonacci story points (1,2,3,5,8,13) / T-shirt sizes — default Fibonacci
  • Definition of Done reference: Any team DoD to fold into acceptance criteria (optional)

If personas or business objective are missing, infer reasonable ones from the feature description and label them as assumptions.

Instructions

Step 1: Write the Epic

Produce a single epic that frames the whole feature.

  • Epic title: Short, outcome-oriented (not a task name)
  • Epic description: 3-5 sentences — what the feature does, who it serves, the problem it solves
  • Business objective: The measurable outcome, tied to a metric where possible (e.g., "increase Day-7 retention by reducing onboarding friction")
  • Success metrics: 2-3 quantifiable indicators the epic will be judged on
  • In scope / Out of scope: 3-5 bullets each — draw the boundary explicitly to prevent scope creep
  • Assumptions & dependencies: Cross-team, platform, or third-party dependencies

Step 2: Decompose Into User Stories

Break the epic into 8-15 vertically-sliced user stories. Each story must deliver independent user or business value — not a technical layer.

Apply the INVEST test to every story:

  • Independent: Minimal coupling to other stories
  • Negotiable: Describes the need, not the implementation
  • Valuable: A user or stakeholder cares about the outcome
  • Estimable: Small and clear enough to point
  • Small: Fits comfortably in one sprint (split anything ≥13 points)
  • Testable: Acceptance criteria can be objectively verified

Slice work across these dimensions to ensure full coverage:

  • Happy path — the core successful flow
  • Edge cases — empty states, errors, timeouts, offline (critical on mobile)
  • Entry points — deep links, notifications, resumed sessions
  • Permissions & auth — logged-out vs. logged-in, role-based access
  • Instrumentation — analytics events and tracking as their own story when meaningful

Step 3: Format Each User Story

For every story, produce this exact structure:

  1. Story ID: US-01, US-02, … (sequential)
  2. Title: Concise, verb-led
  3. User story: "As a [persona], I want [capability], so that [benefit]."
  4. Acceptance criteria: 3-6 criteria in Given / When / Then format — each independently testable, no vague words like "works" or "properly"
  5. Story points: A value from the chosen scale, with a one-line rationale
  6. Priority: Must / Should / Could / Won't (MoSCoW)
  7. Dependencies: Other story IDs or external dependencies, or "None"

Step 4: Order and Sequence

  • Rank stories into a suggested build order that respects dependencies and front-loads the thinnest viable slice of user value
  • Flag which stories together constitute the MVP / first releasable increment
  • Note any story that should be split further before it enters a sprint

Output Format

  • Structure: Epic block first, then numbered user stories, then a build-order/MVP summary
  • Length: 1,000-1,600 words depending on story count
  • Format: Structured document — epic as labeled fields; each story as a consistent labeled block; acceptance criteria as Given/When/Then bullets
  • Sections: Epic → User Stories (8-15) → Suggested Build Order & MVP Scope
  • Tone: Product owner in refinement — precise, unambiguous, implementation-agnostic; written so a developer and a QA engineer read them the same way

Quality Checklist

Before delivering output, verify:

  • [ ] Exactly one epic with title, description, business objective, success metrics, and in/out-of-scope boundaries
  • [ ] Between 8 and 15 user stories, each with a sequential Story ID
  • [ ] Every story uses the "As a / I want / So that" format with a concrete persona and benefit
  • [ ] Every story has 3-6 acceptance criteria in Given/When/Then format — none using vague terms like "properly" or "works"
  • [ ] Every story has a story-point estimate, a MoSCoW priority, and a dependencies line
  • [ ] At least one story covers error/edge/offline states, and the MVP subset is explicitly identified

Notes

  • On mobile, offline behavior, deep links, and interrupted sessions are the most commonly missed slices — always check for them.
  • Any story estimated at 13+ points is a signal to split; recommend a split rather than shipping an oversized story.
  • Acceptance criteria are the contract between product, dev, and QA — bias toward more specificity, not less, and fold in the team's Definition of Done where provided.
  • If the feature spans multiple personas with different flows, prefer separate stories over one story with branching acceptance criteria.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills