mcpbeat Sign in

Bmad Epics And Stories Skill for Claude

| Solutioning flagship — shards a PRD + architecture into epics.md and individual {epic}.{story}.{slug}.story.md context objects, the LAST planning artifact before Dev Notes with SOURCE CITATIONS back to prd.md/architecture.md, Acceptance Criteria, Tasks/Subtasks mapped to ACs, Testing strategy, Dependency Maps, an explicit Owned File/Module Scope list (the lever for parallel-conflict-free scheduling), and Learnings from Previous Stories. Sized to one dev-day; split if larger; NO story points. Use when the user says "shard the PRD", "create epics", "break the PRD into epics", "break this epic into stories", "create stories", "create a story", "draft story files", "generate the story for X", "prepare stories for dev", "mark the story ready for dev", epics/stories, Update an existing story, or Validate a draft against the contract.

7k tokens
context cost
the whole folder, loaded on every use
5
files
ships runnable scripts
0
copies elsewhere
how many repositories repackaged it
471
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/aj-geddes/claude-code-bmad-skills --skill bmad-epics-and-stories

The instruction itself

12 sections, as written by the author

BMAD Epics & Stories

Track-adaptive sharding. Turn approved planning docs into the executable backlog: one

epics.md map plus per-story context objects. This is the final planning step — the next

thing that touches a story is an external dev tool, not this plugin.

Persona flavor: the Architect (Winston) shards; the PM (John) confirms scope. Lightweight

flavor only — this is a workflow.

Scope Law (read first)

This skill PLANS. It NEVER writes application code, runs tests, lints, checks coverage, or

builds. The last artifact it emits is a story file marked status: ready-for-dev. Acceptance

Criteria, a Testing strategy, and Dev Notes are planning outputs you author. Executing

tests or writing implementation is out of scope — plan it and hand it off. If tempted to

"implement" or "run the suite", STOP.

Inputs (load these first)

| File | Why |

|------|-----|

| bmad-output/project-context.md | Project constitution — load every run |

| bmad-output/prd.md | Functional requirements, epic intent |

| bmad-output/architecture.md | Tech stack, components, module boundaries |

| bmad-output/ux-design.md (if present) | UI acceptance details |

| bmad-output/decision-log.md | Threaded decisions to honor |

| existing bmad-output/stories/*.story.md | Learnings + ID continuity |

Output folder default: bmad-output/ (honor user override). Stories go in

bmad-output/stories/, the map in bmad-output/epics.md.

Three Intents

  • Create — shard PRD+architecture into epics.md, then compile story files.
  • Update — revise an existing story (scope, ACs, learnings). Respect LOCKED sections.
  • Validate — check a draft story against the Context Object contract; report gaps.

Ask which intent if ambiguous. Do not silently regenerate existing stories.

Tracks (never numbered levels)

Pick interactively; the heuristic suggests, the user confirms.

  • Quick Flow (1-15 stories) — tech-spec only; shard straight to stories, thin epics.md.
  • BMad Method (10-50+) — PRD + Architecture (+ optional UX); full epic map then stories.
  • Enterprise (30+) — adds Security + DevOps story streams.

Sizing Rule (count-based, no points)

A story must be small enough for one agent session — roughly 2-8h, one dev-day max.

If a story is larger, split it; never inflate scope to fill a sprint. There are NO

Fibonacci points, NO velocity, NO burndown. Delivery is tracked by COUNT: stories remaining

vs. completion rate. See REFERENCE.md for the split heuristics.

Workflow — Create

  • Load context — read the inputs above; note the chosen track.
  • Derive epics — group PRD requirements into epics (each a shippable slice of value).

Write bmad-output/epics.md from templates/epic.template.md:

epic goal, in-scope requirements (cited), ordered story list, cross-epic dependencies.

  • Confirm the epic map with the user before compiling stories.
  • Generate IDsbash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-epics-and-stories/scripts/generate-story-id.sh <epic-number>

gives the next {epic}.{story} and a slug stub. Filename: {epic}.{story}.{slug}.story.md.

  • Compile each story as a CONTEXT OBJECT from

templates/story.template.md. It MUST be self-contained

(~8K tokens) so a dev agent needs no other file. Fill every section:

  • Story — as-a / I-want / so-that.
  • Acceptance Criteria — numbered, testable. LOCKED.
  • Tasks/Subtasks — checkboxes, each mapped to an AC via (AC: #N).
  • Dev Notes — concrete guidance WITH SOURCE CITATIONS (e.g.

[Source: architecture.md#auth-service], [Source: prd.md#FR-12]). LOCKED.

  • Testing — strategy only (what to verify, test types, fixtures). No execution. LOCKED.
  • Dependency Maps — Blocked-by / Blocks other story IDs.
  • Owned File/Module Scope — explicit list of paths this story may touch. This is the

lever for conflict-free parallel scheduling; declare it precisely. See REFERENCE.md.

  • Learnings from Previous Stories — carried forward from completed siblings.
  • Dev Agent Record — leave EMPTY for the external dev tool.
  • Scope-conflict check — run the shared checker over the new/edited stories:

bash ${CLAUDE_PLUGIN_ROOT}/scripts/scope-conflict-check.sh bmad-output/stories/

Resolve any overlapping Owned Scope before marking stories parallel-safe.

  • Set statusbacklog while drafting; flip to ready-for-dev only when every section

is complete, ACs are testable, scope is declared, and the conflict check is clean.

  • Log + hand off — append decisions to decision-log.md; tell the user which stories are

ready-for-dev and hand off to the external dev tool. Do NOT implement.

Workflow — Update / Validate

  • Update: locate the file by ID, edit non-locked sections freely. Changing a LOCKED

section (AC/Dev Notes/Testing) requires explicit user confirmation and a decision-log entry.

Re-run the scope-conflict check if Owned Scope changed.

  • Validate: for each story confirm all required sections exist, every Task cites an AC,

Dev Notes carry source citations, Owned Scope is non-empty and conflict-free, and status is

legal. Report a checklist of pass/fail — do not edit unless asked.

Status Lifecycle

backlog → ready-for-dev → in-progress → review → done. This skill only owns

backlog and ready-for-dev. Everything past handoff belongs to external dev tooling.

LOCKED Sections — contract

Acceptance Criteria, Dev Notes, and Testing are LOCKED. The story template states that

external dev tools MUST NOT edit them. They are the compiled, cited source of truth.

Subagent Strategy

Pattern: parallel section/story generation — one agent per epic or per independent story.

| Agent | Task | Output |

|-------|------|--------|

| Agent N | Compile stories for Epic N as full context objects | bmad-output/stories/N.*.story.md |

Coordination: write shared context (PRD/architecture/track/sizing rule) to

bmad-output/context/sharding-context.md; fan out one agent per epic; on return, the main

context runs the scope-conflict check across ALL stories and resolves overlaps before any

story is marked ready-for-dev.

Example prompt:

Task: Compile stories for Epic 2 (Payments) as context objects.
Context: read bmad-output/context/sharding-context.md.
For each story: number AC, map every Task to an AC (AC: #N), cite Dev Notes to
prd.md/architecture.md sections, declare an explicit Owned File/Module Scope, leave
Dev Agent Record empty. Size to one dev-day; split anything larger. NO story points.
Output: bmad-output/stories/2.*.story.md, status: backlog.

Reference

  • REFERENCE.md — sharding method, sizing/split rule, scope-declaration discipline.
  • templates/epic.template.md
  • templates/story.template.md
  • ${CLAUDE_PLUGIN_ROOT}/skills/bmad-epics-and-stories/scripts/generate-story-id.sh — next {epic}.{story} ID + slug.
  • ${CLAUDE_PLUGIN_ROOT}/scripts/scope-conflict-check.sh — shared Owned-Scope overlap checker.

> ---

> Part of the BMAD Planning & Orchestrator plugin — a Claude Code harness for the BMAD Method by the BMAD Code Organization (https://github.com/bmad-code-org/BMAD-METHOD). Implements the spirit of bmad-create-epics-and-stories. All methodology credit belongs to the BMAD Code Organization.

Other skills for the same job

different authors, same section of the catalogue
Workflow Patterns
by ComeOnOliver
×2

Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.

6k tokens
Iso Standards Readiness
by K-Dense-AI
×1

Prepares and structurally reviews readiness evidence for ISO management-system and laboratory-competence standards - ISO 13485 medical device QMS, ISO 14971 device risk management, ISO/IEC 17025 testing and calibration laboratories, and ISO 15189 medical laboratories. Use when organizing declared scope, controlled documents, risk-management files, scope of accreditation, traceability, CAPA, external-provider controls, or bounded local evidence manifests, and when separating ISO certification from laboratory accreditation, FDA QMSR inspection, CLIA certification, MDSAP, and EU MDR/IVDR evidence boundaries. Not for legal applicability, compliance, certification, or accreditation decisions; contains no clause text.

67k tokens scripts
Statistical Power
by K-Dense-AI
×1

Sample-size and statistical power calculations for planning studies. Use whenever someone asks "how many subjects/samples/replicates do I need", wants an a priori power analysis, a minimum detectable effect (MDE), a power curve, or needs to justify a sample size for a grant, IRB protocol, or pre-registration. Covers closed-form power for t-tests, ANOVA, proportions, correlations, chi-square, and regression, plus simulation-based (Monte Carlo) power for designs with no formula — logistic/Poisson regression, mixed models, cluster-randomized trials, survival, and interactions. Use this skill even when the request only mentions an effect size, alpha, or "80% power" without saying "power analysis" explicitly. For laying out the study (randomization, blocking, factorial/DOE, crossover, sequential designs) use experimental-design; for analyzing data already collected and reporting it use statistical-analysis.

13k tokens scripts
General Figure Guide
by BioTender-max
×1

Universal QA checklist for generated scientific plots: overlapping labels, clipped text, missing axes/legends, overcrowded data, and cross-journal resolution/format guidance.

2k tokens
Nerdzao Elite
by ComeOnOliver
×1

Senior Elite Software Engineer (15+) and Senior Product Designer. Full workflow with planning, architecture, TDD, clean code, and pixel-perfect UX validation.

3k tokens
Pinchbench
by ComeOnOliver
×1

Run PinchBench benchmarks to evaluate OpenClaw agent performance across real-world tasks. Use when testing model capabilities, comparing models, submitting benchmark results to the leaderboard, or checking how well your OpenClaw setup handles calendar, email, research, coding, and multi-step workflows.

2096k tokens scripts
Workflow Patterns
by ComeOnOliver
×1

Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.

6k tokens
Powertoys Verification
by microsoft
vendor

Verify PowerToys behavior end-to-end with the winapp CLI across two scenarios: (A) a module's release checklist against the installed build; (B) PR validation — derive each PR's checklist from its description + diff, then drive it against the installed build (a merged/shipped PR, or a whole release/hotfix set) or by building + sideloading the module when the PR isn't in the build yet (unmerged or not-yet-released). Drive each item via UIA invoke / Named Events / settings.json edits / clipboard / GPO / SendInput, and emit a structured PASS / FAIL / BLOCKED verdict per item with evidence (FAIL distinguishes product defects from stale/ambiguous checklist items). Use when asked to verify a module checklist, validate a PR, sign off a release/hotfix's PRs, or QA installed/sideloaded PowerToys bits. Combines generic winapp ui mechanics (references/winapp-ui-testing.md) with PT-specific recipes, per-scenario playbooks (references/scenarios/), and the helper .ps1 files shipped with this skill.

86k tokens scripts

How to use it

Copy the folder

Take aj-geddes/bmad-epics-and-stories from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.