| 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.
npx skills add https://github.com/aj-geddes/claude-code-bmad-skills --skill bmad-epics-and-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.
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.
| 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.
epics.md, then compile story files.Ask which intent if ambiguous. Do not silently regenerate existing stories.
Pick interactively; the heuristic suggests, the user confirms.
epics.md.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.
Write bmad-output/epics.md from templates/epic.template.md:
epic goal, in-scope requirements (cited), ordered story list, cross-epic dependencies.
bash ${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.
templates/story.template.md. It MUST be self-contained
(~8K tokens) so a dev agent needs no other file. Fill every section:
(AC: #N).[Source: architecture.md#auth-service], [Source: prd.md#FR-12]). LOCKED.
lever for conflict-free parallel scheduling; declare it precisely. See REFERENCE.md.
bash ${CLAUDE_PLUGIN_ROOT}/scripts/scope-conflict-check.sh bmad-output/stories/
Resolve any overlapping Owned Scope before marking stories parallel-safe.
backlog while drafting; flip to ready-for-dev only when every sectionis complete, ACs are testable, scope is declared, and the conflict check is clean.
decision-log.md; tell the user which stories areready-for-dev and hand off to the external dev tool. Do NOT implement.
section (AC/Dev Notes/Testing) requires explicit user confirmation and a decision-log entry.
Re-run the scope-conflict check if Owned Scope changed.
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.
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.
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.
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.
${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.
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.
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.
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.
Universal QA checklist for generated scientific plots: overlapping labels, clipped text, missing axes/legends, overcrowded data, and cross-journal resolution/format guidance.
Senior Elite Software Engineer (15+) and Senior Product Designer. Full workflow with planning, architecture, TDD, clean code, and pixel-perfect UX validation.
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.
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.
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.
Take aj-geddes/bmad-epics-and-stories from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
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.