bmad-correct-course

BMAD 軌道修正

役割： 計画の途中で変更が生じた際に、フェーズへ再合流するためのポイントです。

現実が計画から外れたとき――関係者の方針転換、制約の判明、機能の削除など――このスキルは計画フェーズに再合流し、必要最小限の計画変更を行い、適切な後続スキルへ引き継ぎます。変更するのは計画であり、コードではありません。

ペルソナの要素： Mary（アナリスト）が影響を明らかにし、John（PM）が変更範囲を定め、Winston（アーキテクト）が影響を受けるエピックを再分割します。
軽量な要素のみです――これはワークフローです。

---

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

このスキルは計画を立てます。アプリケーションコードの作成、テストの実行、Lint、カバレッジの確認、ビルド、差分のレビューは決して行いません。「コードを修正する」または「テスト一式を実行する」誘惑に駆られたら、そこで止めてください。変更を計画し、引き継いでください。

このスキルが生成できる最終成果物は、ready-for-dev とマークされたストーリーファイル、更新された sprint-status.yaml、または後続の計画スキルへのルーティング指示です。

---

このスキルを使うタイミング

次のいずれかに該当する場合に起動します。

• 要件、機能、または制約が、計画成果物（PRD、アーキテクチャ、epics.md、ストーリーのいずれか）の作成後に変更された。
• 既存の計画に反映されていない理由により、ストーリーの追加、削除、分割、統合、またはスコープ変更が必要になった。
• アーキテクチャの変更により、既存のストーリーに記載された Owned File/Module Scope の宣言が無効になった。
• ユーザーが、先に進む前に decision-log.md へ途中の決定を記録したい。

---

入力（最初に読み込む）

ファイル	理由
bmad-output/project-context.md	プロジェクトの基本方針――実行のたびに読み込む
bmad-output/decision-log.md	継続的な決定事項。ここに追記する
bmad-output/epics.md	差分確認の対象となる既存のエピック一覧
bmad-output/prd.md	要件の信頼できる情報源
bmad-output/architecture.md	技術上の境界（アーキテクチャが変更された場合）
bmad-output/sprint-status.yaml	現在の順序付けの状態
bmad-output/stories/*.story.md	進行中およびバックログのストーリー

出力フォルダーのデフォルトは bmad-output/ です。bmad-output/config.yaml でユーザーが設定した上書きがあれば、それに従ってください。

---

3 つの意図

意図	使用するタイミング
スコープ変更	機能が追加、削除、または再構成された場合――影響を受けるエピックを再分割し、順序を組み直します。
アーキテクチャ変更	モジュールの境界、技術スタック、または統合に変更があった場合――影響を受けるストーリーの Owned Scope 宣言を更新します。
記録のみ	変更がすでに計画成果物に反映されている場合――decision-log の記録を追加し、一貫性を確認します。

先に進む前に、意図を明確に伝えてください。どのケースか不明な場合は、決めつけずに該当するシナリオをユーザーに確認してください。

---

ワークフロー

TodoWrite を使って、各ステップの進捗を追跡します。

Step 1 — 読み込んで状況を把握する

1. 上記の入力をすべて読み込みます。
2. 変更内容を特定します。何が追加され、何が削除され、何が変更されたのか、またその理由は何かを確認します（不明な場合はユーザーに尋ねます）。
3. 編集する前に、理解した内容をユーザーに伝えます。

Step 2 — 影響範囲をトリアージする

影響範囲を必要最小限に特定します。

• どのエピックが影響を受けますか？（追加／削除／再構成）
• どのストーリーが影響を受けますか？（追加／削除／スコープ変更／Owned Scope が無効）
• どのストーリーのステータスを変更する必要がありますか？（変更の影響を受ける in-progress のストーリーには特別な注意が必要です。フラグを立て、黙って移動させないでください。）
• sprint-status.yaml の順序を組み直す必要がありますか？

トリアージの内容をユーザーに提示し、編集前に確認を取ります。

Step 3 — 計画成果物を更新する

必要最小限の変更のみ適用します。

3a. epics.md を更新する（影響を受けるエピックのみ）

• 新しいエピックを追加する場合は、# COURSE-CORRECTION 注釈と日付を付けます。
• 削除するエピックは status: cancelled とマークします。削除せず、履歴を保持してください。
• エピックの説明、スコープの境界、ストーリーの順序付き一覧を更新します。
• 影響を受けていないエピックは再生成しないでください。

3b. 影響を受けるストーリーを再分割する（bmad-epics-and-stories にルーティング）

スコープが変更されたエピックについては、ストーリー分割ワークフローを呼び出します。

bmad-epics-and-stories にルーティング（意図：更新または作成）
更新後のエピック定義と、追加、削除、または修正するストーリー ID の一覧を提供します。
ストーリーのコンテキストオブジェクト契約は分割スキルが管理します。ここで再現しないでください。

• 削除するストーリー：ストーリーファイルのヘッダーと sprint-status.yaml で status: cancelled に設定します。ファイルは削除しないでください。
• 追加するストーリー：status: backlog から開始します。
• スコープを変更するストーリー：変更を明記し、LOCKED セクションを再検証します。LOCKED セクション（Acceptance Criteria、Dev Notes、Testing）は、ユーザーの明示的な確認がある場合に限り変更できます。変更内容を decision-log.md に記録します。

3c. sprint-status.yaml の順序を再設定する（bmad-sprint-planning にルーティング）

すべてのストーリー変更が確定したら、bmad-sprint-planning にルーティングして、ウェーブの割り当てを再導出します。

bmad-sprint-planning にルーティング（意図：更新）
変更されたストーリー ID と新しいステータスの全リストを渡します。
依存関係グラフを再計算し、並列セットを再割り当てするよう依頼します。

または、変更が単一ストーリーの入れ替え（依存関係への波及がない、単純な1件追加／1件削除のみ）に限られる場合は、sprint-status.yaml を直接編集できます。

# Validate current sprint-status.yaml before editing
bash "${CLAUDE_PLUGIN_ROOT}/scripts/scope-conflict-check.sh" bmad-output/stories/

3d. 並列処理を再計画する（必要な場合は bmad-parallel-plan にルーティング）

Owned File/Module Scope の宣言が変更された場合、または新しいストーリーがバックログに追加された場合は、ウェーブの割り当てを再計画します。

bmad-parallel-plan にルーティング（意図：更新）
更新後のストーリー一覧を渡し、変更されたスコープを記載します。
依存関係 DAG を再構築し、改訂版の parallelization-plan.md を出力するよう依頼します。

これは、プロジェクトが以前から並列ウェーブを使用している場合に限り呼び出してください。プロジェクトが Quick Flow または逐次デリバリーを使用している場合は、この手順をスキップします。

ステップ 4 — decision-log.md に追記する

あらゆる軌道修正について、必ず decision-log エントリを作成します。次の形式を使用してください（新しいものから順に追記します）。

### YYYY-MM-DD — Course Correction: <short title>
- **Decision:** <what changed in the plan>
- **Rationale:** <why the change was necessary; alternatives considered>
- **Impact:** <epics added/dropped, stories added/dropped/re-scoped,
  status changes in sprint-status.yaml>
- **In-progress stories affected:** <list, or "none">
- **Made by:** bmad-correct-course
- **Supersedes:** <link to prior entry, if any>

bmad-output/decision-log.md に、templates/course-correction.template.md のテンプレートを使って追記します。

ステップ 5 — 要約して引き継ぐ

すべての更新を適用した後、次の内容を報告します。

Course correction applied.
  Decision log  : entry appended → bmad-output/decision-log.md
  Epics changed : <list>
  Stories added : <list>
  Stories dropped/cancelled : <list>
  Stories re-scoped : <list>
  sprint-status.yaml : re-sequenced (wave assignments updated)
  Next step     : <route taken — epics-and-stories / sprint-planning / parallel-plan>

実装はしないでください。計画は準備できており、外部の開発ツールが引き継ぎます。

---

ガードレール

• 計画アーティファクトは絶対に削除しないでください。ステータス注記と decision-log エントリを追加して、その場でキャンセルします。履歴は第一級の関心事です。
• 影響範囲を最小限に抑えます。 スコープ変更に必要なものだけを変更します。変更のないエピック、ストーリー、ウェーブの割り当ては再生成しないでください。
• 進行中のストーリーは慎重に扱います。 ストーリーのステータスが in-progress または review の場合はユーザーに伝え、スコープの変更やキャンセルの前に明示的な確認を待ちます。進行中の作業を黙って変更しないでください。
• LOCKED セクションの変更には確認が必要です。 既存ストーリーの Acceptance Criteria、Dev Notes、Testing は LOCKED です。変更にはユーザーによる明示的な承認が必要です。承認を decision-log.md に記録します。
• メトリクスは扱いません。 どのステップでも、ベロシティ、バーンダウン、ストーリーポイントを計算しないでください。デリバリーの追跡は件数に基づきます。残りのストーリー数と完了率を使用します。sprint-status.yaml にポイントのフィールドを追加しないでください。
• ルーティングし、再現しないでください。 ストーリーのコンテキストオブジェクトの作成は bmad-epics-and-stories が担当します。ウェーブの計算は bmad-sprint-planning と bmad-parallel-plan が担当します。それらのロジックを重複させず、ルーティングしてください。

---

ルーティングの概要

下流スキル	ルーティングするタイミング
bmad-epics-and-stories（更新または作成）	エピックのスコープが変更され、ストーリーの再分割または新規作成が必要な場合
bmad-sprint-planning（更新）	依存関係グラフまたはウェーブの割り当てを再計算する必要がある場合
bmad-parallel-plan（更新）	Owned File/Module Scope が変更され、並列ウェーブを再構築する必要がある場合

複数の下流スキルに順番にルーティングできます。ルーティングする前に、 必ず decision-log.md を更新してください。

---

ステータスのライフサイクルに関するリファレンス

backlog → ready-for-dev → in-progress → review → done
                                                     ↑
cancelled  (set here on drop; never deleted)     ──── 

cancelled は終端状態です。キャンセルされたストーリーは、履歴を保持するために sprint-status.yaml 内に status: cancelled として残します。

---

サブエージェント戦略

パターン： 影響分析は並行して行い、適用は順番に行います。

大規模なバックログ（ストーリーが 15 件以上、影響を受けるエピックが 3 件以上）の場合は、分析を分担します。

エージェント	タスク	出力
エージェント 1	epics.md と変更内容を比較し、影響を受けるエピック ID を一覧表示する	bmad-output/context/affected-epics.md
エージェント 2	すべてのストーリーファイルをスキャンし、Owned Scope または依存関係が無効になるストーリーを特定する	bmad-output/context/affected-stories.yaml
エージェント 3	sprint-status.yaml を読み、キャンセルまたは追加されたストーリーによる依存関係への波及を特定する	bmad-output/context/ripple-analysis.yaml

コーディネーター（メインコンテキスト）：出力を統合し、ユーザーとトリアージ内容を確認してから、 変更を適用し、下流スキルにルーティングします。

サブエージェントプロンプトの例：

Task: Identify stories affected by the scope change.
Context: Read all *.story.md files under bmad-output/stories/.
Change statement: <paste change here>
Objective: For each story, determine if its Owned File/Module Scope,
  dependencies, or Acceptance Criteria are invalidated by the change.
Output: Write YAML list to bmad-output/context/affected-stories.yaml

Format:
- id: "2.1.stripe-integration"
  affected: true
  reason: "owned scope includes src/payments/ which moves to new module"
  status: "ready-for-dev"

---

リファレンス

• templates/course-correction.template.md — decision-log エントリーのテンプレート。
• bmad-output/decision-log.md — ここに追記します。以前のエントリーを上書きしないでください。
• ${CLAUDE_PLUGIN_ROOT}/scripts/scope-conflict-check.sh — ストーリー変更後に Owned Scope を検証します。
• 下流スキル：bmad-epics-and-stories、bmad-sprint-planning、bmad-parallel-plan。

---

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