bmad-parallel-plan

BMAD 並列化計画

直線的なバックログを、互いに競合することなく同時に開発できるウェーブに変換し、最後にそれらをどのように統合するかを正確に記述します。このスキルが生成するのは計画です。実際の作業は、外部の開発ツールが実行します。

ペルソナの特徴： Winston（アーキテクト）は分離について検討し、ワークフローが計算を行います。

対象範囲（最初にお読みください）

• このスキルは並行作業を計画します。ワークツリーの作成、開発エージェントの実行、アプリケーションコードの作成、テスト、リント、git の実行は一切行いません。
• 入力は計画用アーティファクトです。出力は parallelization-plan.md のみです（トレーサビリティ確保のため、任意で dependency-graph.json／waves.json も出力できます）。
• ブランチ名とマージ順序は、開発ツールまたは人間が実行するための推奨事項です。

入力

アーティファクト	パス（出力フォルダー内）	用途
スプリントステータス	sprint-status.yaml	ストーリー ID、エピック、ステータス、依存関係リスト
準備済みストーリー	stories/{epic}.{story}.{slug}.story.md	所有対象ファイル／モジュールの範囲 + 依存関係マップ
アーキテクチャ	architecture.md	意味的な競合の防止（境界、共有モジュール）
設定	userConfig.maxParallel（デフォルト 3）	ウェーブの最大幅

ステータスが ready-for-dev 以降のストーリーのみ、ウェーブの対象になります。

4 つのステップ

1. 意味的な安全性の確保には、アーキテクチャを活用します。 architecture.md を読みます。並列化を安全にするのはアーキテクチャです。モジュールの境界が明確であれば、異なるコンポーネントに触れる 2 つのストーリーは、ファイルが異なっていても、隠れた意味上の競合を引き起こしません。共有モジュールや横断的なモジュール（認証、設定、DB スキーマ、共有型）を特定します。これらに触れるストーリーは競合の可能性が高く、並行して実施できることはほとんどありません。

2. 各ストーリーの「所有対象ファイル／モジュールの範囲」を読みます。 各準備済みストーリーには、変更可能なパスの明示的なリストが記載されています。{story_id -> [paths]} を収集します。範囲が記載されていない、または空の場合は、計画の阻害要因として指摘し、推測で補わないでください。

3. 依存関係 DAG を作成し、トポロジカルソートしてウェーブに分けます。 エッジは 3 つの競合クラスから生じます（REFERENCE.md を参照）。

   • 順序エッジ — エピックの順序（エピック内のストーリーは通常、順番に進めます）と、各ストーリーの明示的な依存関係マップ（depends_on）。
   • ファイル範囲エッジ — 所有対象ファイル／モジュールの範囲が交差する 2 つのストーリーは、同じウェーブに含めてはいけません（無向の競合。ストーリー ID の小さい順に解決します）。
   • 意味的エッジ — どちらもステップ 1 で特定した共有モジュールや横断的なモジュールに触れる場合です。

   トポロジカルソートを行います。ウェーブ N には、依存関係がすでにウェーブ < N で解決済みで、かつ相互にファイルが重複せず、意味的にも安全なストーリーをすべて含めます。各ウェーブの上限は maxParallel です。上限を超えた分は、次のウェーブに繰り越します（ID の小さい順）。

4. parallelization-plan.md を出力します。 各ウェーブに、ready-for-dev のストーリーを列挙します。それぞれに、分離された git-worktree ブランチ名と、重複しないファイル範囲を割り当てます。続けて、マージ順序を示します。ストーリー ID の小さい順に integration ブランチへマージし、統合レビューのチェックポイントを設けてから、単一の PR integration -> main を作成します。

3 つの意図

• 作成 — 現在のバックログから、最初のウェーブ計画を作成します。
• 更新 — ストーリーの追加、完了、または範囲変更後に再計画します（DAG を再計算し、done を除外して、残りを再ソートします）。
• 検証 — 既存の計画を再確認します。各ウェーブでファイル範囲に重複がなく、依存関係が満たされ、maxParallel 以下であることを確認し、差異を報告します。

意図を明示してから、処理を進めます。

ヘルパースクリプトを実行する

両方のスクリプトは決定論的で、読み取り専用です。${CLAUDE_PLUGIN_ROOT} を使用してパスを解決します。

# 1) Build the dependency DAG (edges + conflict class) from status + story scopes
python3 "${CLAUDE_PLUGIN_ROOT}/skills/bmad-parallel-plan/scripts/build-dependency-graph.py" \
  --status   "<output>/sprint-status.yaml" \
  --stories  "<output>/stories" \
  --out      "<output>/dependency-graph.json"

# 2) Topologically sort into capped waves
python3 "${CLAUDE_PLUGIN_ROOT}/skills/bmad-parallel-plan/scripts/plan-parallel-waves.py" \
  --graph        "<output>/dependency-graph.json" \
  --max-parallel 3 \
  --out          "<output>/waves.json"

# 3) (Optional) cross-check two scope lists for overlap — shared orchestrator helper
bash "${CLAUDE_PLUGIN_ROOT}/scripts/scope-conflict-check.sh" \
  "<output>/stories/2.1.foo.story.md" "<output>/stories/2.2.bar.story.md"

次に、templates/parallelization-plan.template.md を使用して waves.json を人間向けの計画に整形し、<output>/parallelization-plan.md に書き込みます。

ブランチとマージの規約

• ストーリーごとにブランチを作成します：story/{epic}.{story}-{slug}（作業ツリーごとに完全に分離します）。
• ウェーブごとに統合ブランチを作成します：integration/wave-{N}。
• ウェーブ内のマージ順序：ストーリー ID の昇順で integration/wave-{N} にマージします。
• ウェーブ内のすべてのストーリーのマージ後に、統合レビューのチェックポイントを実施し、その後 PR を作成します。 integration/wave-{N} から main へマージします。ウェーブ N+1 のブランチは、マージ済みの main から作成します。

出力

• <output>/parallelization-plan.md — 成果物。
• <output>/dependency-graph.json、<output>/waves.json — トレーサビリティ（任意）。
• <output>/decision-log.md に、maxParallel、ウェーブ数、スコープ不足により延期したストーリーを記した 1 行のエントリーを追記します。

ガードレール

• Owned File/Module Scope が重複する 2 つのストーリーを、同じウェーブに配置しないでください。
• depends_on で指定されたストーリーより前に、そのストーリーをスケジュールしないでください。
• スコープが宣言されていないストーリーは、ウェーブの対象にできません。スクラムマスターが修正できるように提示し、パスを推測しないでください。
• maxParallel を遵守してください。実際の並列実行数は開発ツールによって制御され、計画でその上限を超えてはなりません。
• ストーリー内の Acceptance Criteria、Dev Notes、Testing は変更しないでください。これらは LOCKED です。

ウェーブのアルゴリズム、競合クラス、マージ順序の根拠については、REFERENCE.md を参照してください。

---

BMAD Planning & Orchestrator プラグインの一部です。BMAD Code Organization による BMAD Method のための Claude Code ハーネスです（https://github.com/bmad-code-org/BMAD-METHOD）。`bmad-parallel-plan` の理念を実装しています。手法に関するすべてのクレジットは BMAD Code Organization に帰属します。