bmad-epics-and-stories

BMAD エピックとストーリー

トラック適応型の分割。 承認済みの計画ドキュメントを実行可能なバックログに変換します。epics.md のマップと、ストーリーごとのコンテキストオブジェクトを作成します。これが計画の最終ステップです。次にストーリーに関わるのは、このプラグインではなく、外部の開発ツールです。

ペルソナの特徴： アーキテクト（Winston）が分割し、PM（John）がスコープを確認します。軽量なフレーバーのみです。これはワークフローです。

スコープの原則（最初に読む）

このスキルは計画を立てます。アプリケーションコードの作成、テストの実行、Lint、カバレッジの確認、ビルドは一切行いません。最後に出力する成果物は、status: ready-for-dev とマークされたストーリーファイルです。受け入れ条件、テスト戦略、開発メモは、作成する計画の出力です。テストの実行や実装の作成はスコープ外です。計画を立てて引き継いでください。「実装」や「テストスイートの実行」をしたくなったら、STOPしてください。

入力（最初に読み込む）

ファイル	理由
bmad-output/project-context.md	プロジェクトの基本原則。実行のたびに読み込みます
bmad-output/prd.md	機能要件、エピックの意図
bmad-output/architecture.md	技術スタック、コンポーネント、モジュールの境界
bmad-output/ux-design.md（存在する場合）	UI の受け入れに関する詳細
bmad-output/decision-log.md	順守すべき関連する意思決定
既存の bmad-output/stories/*.story.md	学びと ID の継続性

出力フォルダーのデフォルト：bmad-output/（ユーザーによる変更を尊重します）。ストーリーは bmad-output/stories/、マップは bmad-output/epics.md に保存します。

3 つのインテント

• 作成 — PRD とアーキテクチャを分割して epics.md を作成し、その後、ストーリーファイルを作成します。
• 更新 — 既存のストーリー（スコープ、受け入れ条件、学び）を改訂します。LOCKED セクションを尊重してください。
• 検証 — コンテキストオブジェクトの契約に照らしてストーリーのドラフトを確認し、不足項目を報告します。

曖昧な場合は、どのインテントかを尋ねてください。既存のストーリーを黙って再生成しないでください。

トラック（番号付きレベルではありません）

対話形式で選択します。ヒューリスティックが候補を提案し、ユーザーが確認します。

• Quick Flow（1～15 ストーリー）— tech-spec のみ。ストーリーに直接分割し、epics.md は簡潔にします。
• BMad Method（10～50 件以上）— PRD + アーキテクチャ（+ 任意の UX）。完全なエピックマップを作成してからストーリーを作成します。
• Enterprise（30 件以上）— Security と DevOps のストーリーストリームを追加します。

サイズ設定のルール（ポイントではなく件数）

ストーリーは1 回のエージェントセッションで完了できる程度に小さく、目安は 2～8 時間、最大でも 1 開発日にします。大きすぎる場合は、分割してください。スプリントを埋めるためにスコープを膨らませてはいけません。フィボナッチポイントも、ベロシティも、バーンダウンもありません。デリバリーは件数で追跡します。残りのストーリー数と完了率を比較します。分割のヒューリスティックについては、REFERENCE.md を参照してください。

ワークフロー — 作成

1. コンテキストを読み込む — 上記の入力を読み、選択されたトラックを確認します。
2. エピックを導き出す — PRD の要件をエピック（それぞれ価値を提供する出荷可能な単位）にまとめます。 templates/epic.template.md から bmad-output/epics.md を作成します： エピックの目標、対象範囲内の要件（出典を明記）、順序付けたストーリー一覧、エピック間の依存関係。
3. 確認する — ストーリーを作成する前に、エピックの構成をユーザーに確認します。
4. ID を生成する — bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-epics-and-stories/scripts/generate-story-id.sh <epic-number> を実行すると、次の {epic}.{story} とスラッグの仮文字列が得られます。ファイル名は {epic}.{story}.{slug}.story.md です。
5. 各ストーリーを templates/story.template.md からコンテキストオブジェクトとして作成します。 開発エージェントが他のファイルを必要としないよう、自己完結型（約 8K トークン）にする必要があります。すべてのセクションを埋めます：
   • Story — 「誰として／何をしたい／その理由」の形式。
   • Acceptance Criteria — 番号付きで、テスト可能なもの。変更禁止です。
   • Tasks/Subtasks — チェックボックス形式にし、それぞれを (AC: #N) で AC に対応付けます。
   • Dev Notes — 出典を明記した具体的なガイダンス（例： [Source: architecture.md#auth-service]、[Source: prd.md#FR-12]）。変更禁止です。
   • Testing — 戦略のみ（検証内容、テストの種類、フィクスチャ）。実行は含めません。変更禁止です。
   • Dependency Maps — Blocked-by / Blocks の対象となる他のストーリー ID。
   • Owned File/Module Scope — このストーリーで変更してよいパスの明示的な一覧。競合のない並列スケジューリングを可能にする要素なので、正確に定義します。REFERENCE.md を参照してください。
   • Learnings from Previous Stories — 完了した兄弟ストーリーから引き継いだ情報。
   • Dev Agent Record — 外部の開発ツール用に空欄のままにします。
6. スコープ競合を確認する — 新規または編集済みのストーリーに共有チェッカーを実行します： bash ${CLAUDE_PLUGIN_ROOT}/scripts/scope-conflict-check.sh bmad-output/stories/ ストーリーを並列実行可能とする前に、重複する Owned Scope を解消します。
7. ステータスを設定する — 作成中は backlog にします。すべてのセクションが完成し、AC がテスト可能で、スコープが定義され、競合チェックに問題がない場合にのみ ready-for-dev に変更します。
8. 記録して引き継ぐ — 決定事項を decision-log.md に追記します。どのストーリーが ready-for-dev かをユーザーに伝え、外部の開発ツールに引き継ぎます。実装はしないでください。

ワークフロー — 更新／検証

• 更新： ID でファイルを特定し、変更禁止ではないセクションは自由に編集します。変更禁止セクション（AC／Dev Notes／Testing）を変更するには、ユーザーの明示的な確認と decision-log への記録が必要です。Owned Scope を変更した場合は、スコープ競合チェックを再実行します。
• 検証： 各ストーリーについて、必須セクションがすべて存在すること、すべての Task に AC が記載されていること、Dev Notes に出典が記載されていること、Owned Scope が空でなく競合がないこと、ステータスが有効であることを確認します。合格／不合格のチェックリストを報告し、依頼がない限り編集はしません。

ステータスのライフサイクル

backlog → ready-for-dev → in-progress → review → done。このスキルが扱うのは backlog と ready-for-dev のみです。引き継ぎ後のすべての作業は外部の開発ツールが担当します。

変更禁止セクション — 契約

Acceptance Criteria、Dev Notes、Testing は変更禁止です。ストーリーテンプレートには、外部の開発ツールがこれらを編集してはならないと記載されています。これらは、出典が明記された作成済みの正式な情報源です。

サブエージェント戦略

パターン： セクション／ストーリーの並列作成 — エピックごと、または独立したストーリーごとに 1 エージェントを割り当てます。

エージェント	タスク	出力
Agent N	Epic N のストーリーを完全なコンテキストオブジェクトとして作成	bmad-output/stories/N.*.story.md

調整：共有コンテキスト（PRD／アーキテクチャ／トラック／サイジングルール）を bmad-output/context/sharding-context.md に記述し、エピックごとに 1 エージェントを割り当てます。作業が戻ったら、メインコンテキストで全ストーリーを対象にスコープ競合チェックを実行し、ストーリーを ready-for-dev にする前に重複を解消します。

プロンプトの例：

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.md — シャーディング方式、サイズ設定／分割ルール、スコープ宣言の規律。
• templates/epic.template.md
• templates/story.template.md
• ${CLAUDE_PLUGIN_ROOT}/skills/bmad-epics-and-stories/scripts/generate-story-id.sh — 次の {epic}.{story} ID とスラッグを生成します。
• ${CLAUDE_PLUGIN_ROOT}/scripts/scope-conflict-check.sh — 共通の Owned-Scope 重複チェッカー。

---

BMAD Planning & Orchestrator プラグインの一部です — BMAD Code Organization による BMAD Method 用の Claude Code ハーネスです（https://github.com/bmad-code-org/BMAD-METHOD）。`bmad-create-epics-and-stories` の理念を実装しています。手法に関する功績はすべて BMAD Code Organization に帰属します。