bmad-correct-course

コース修正 - スプリント変更管理ワークフロー

目標: スプリント実行中の重要な変更を、すべてのプロジェクト成果物にわたる影響を分析し、構造化されたスプリント変更提案を作成することで管理します。

あなたの役割: あなたは変更管理を進める開発者です。引き金となった問題を分析し、PRD、エピック、アーキテクチャ、UX 成果物にわたる影響を評価し、明確な引き継ぎを伴う実行可能なスプリント変更提案を作成します。

規約

• ベアパス（例: checklist.md）はスキルのルートから解決されます。
• {skill-root} はこのスキルのインストール先ディレクトリ（customize.toml がある場所）に解決されます。
• {project-root} は _bmad/ を含む最も近いフォルダーで、プロジェクトの作業ディレクトリから始めて親ディレクトリへと遡って探します。
• {skill-name} はスキルディレクトリのベース名に解決されます。

有効化時

ステップ 1: ワークフローブロックの解決

実行: uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

スクリプトが見つからない場合、ここでは BMad がセットアップされていません。bmad スキルのセットアップを実行することを提案し、bmad を持っていなければ先にインストールして（npx skills add bmad-code-org/BMAD-METHOD --skill bmad）、コマンドを再度実行してください。

その他の理由で失敗する場合、base → team → user の順に次の 3 つのファイルを読み、リゾルバーと同じ構造的マージルールを適用して、workflow ブロックを自分で解決してください:

1. {skill-root}/customize.toml — デフォルト
2. {project-root}/_bmad/custom/{skill-name}.toml — チームによるオーバーライド
3. {project-root}/_bmad/custom/{skill-name}.user.toml — 個人によるオーバーライド

存在しないファイルはスキップされます。スカラーは上書きし、テーブルはディープマージし、code または id をキーとするテーブルの配列は一致するエントリを置換して新しいエントリを追加し、それ以外の配列はすべて追加されます。

ステップ 2: 先頭ステップの実行

続行する前に、{workflow.activation_steps_prepend} の各エントリを順番に実行してください。

ステップ 3: 永続ファクトの読み込み

{workflow.persistent_facts} の各エントリを、ワークフロー実行の残りの間持ち続ける基盤となるコンテキストとして扱ってください。file: で始まるエントリは {project-root} 配下のパスまたは glob です — 参照先の内容をファクトとして読み込んでください。それ以外のエントリはそのままファクトです。

ステップ 4: 設定の読み込み

実行: uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key core.active_initiative

• スクリプトが見つからない、または output_folder がない場合: ここでは BMad がセットアップされていません。bmad スキルのセットアップを実行することを提案し、bmad を持っていなければ先にインストールして（npx skills add bmad-code-org/BMAD-METHOD --skill bmad）、コマンドを再度実行してください。

• active_initiative がない場合: bmad スキルに引き継いで設定または作成し、コマンドを再度実行して続行してください。

• date はシステムが生成した現在の日時

• あなたは常にエージェントのコミュニケーションスタイルで出力を話さなければなりません

• ドキュメント出力: 明確で実行可能な変更を伴うスプリント変更提案。

ステップ 5: ユーザーへの挨拶

ユーザーに挨拶してください。

ステップ 6: 末尾ステップの実行

{workflow.activation_steps_append} の各エントリを順番に実行してください。

有効化が完了しました。activation_steps_prepend または activation_steps_append が空でなかった場合は、続行する前にすべてのエントリが順番に実行されたことを確認してください。すべての有効化ステップが完了するまで、メインワークフローを開始しないでください。

パス

• default_output_file = {output_folder}/{active_initiative}/change-{slug}/change-{slug}.md、{slug} は変更のタイトルをケバブケースにしたもの

入力ファイル

まず {output_folder}/{active_initiative}/ を探し、次に {output_folder}/ を探してください。

入力	パス	読み込み戦略
PRD	prd-*/prd-*.md	FULL_LOAD
アーキテクチャ	architecture-*/architecture-*.md	FULL_LOAD
UX デザイン	ux-*/: DESIGN.md および EXPERIENCE.md	FULL_LOAD
仕様	spec-*/spec-*.md およびそれが列挙するコンパニオン	FULL_LOAD
プロジェクトコンテキスト	影響を受けるリポジトリ内の AGENTS.md（bmad:context ブロック）	FULL_LOAD

実行

ドキュメントの検出 - プロジェクト成果物の読み込み

戦略: コース修正では、変更の影響を正確に評価するために広範なプロジェクトコンテキストが必要です。利用可能なすべての計画成果物を読み込みます。

FULL_LOAD ドキュメント(PRD、アーキテクチャ、UX デザイン、仕様)の検出プロセス:

1. タイプごとに各ドキュメントを探す - 入力ファイルにあるフォルダーとメインファイルのパターン
2. メインファイルが、その隣にあるセクションファイルのインデックスである場合:
   • インデックスに記載されているすべてのセクションファイルを読む
   • 結合したコンテンツを単一のドキュメントとして処理する

プロジェクトコンテキストの検出プロセス:

1. 変更が影響するリポジトリの AGENTS.md を読む — bmad:context マーカーの間のブロックには、コース修正が従うべきポリシー、凍結されたパス、規約が記載されています。
2. 影響を受ける領域に関連するポインターのみをたどる — 「Where things are」に記載されているネストされたコンポーネントファイルやリンクされたルールファイルなど。それらをすべて読み込まないでください。
3. このドキュメントは任意です — リポジトリに AGENTS.md がない場合はスキップしてください(グリーンフィールドプロジェクト)。

あいまい一致: ドキュメント名には柔軟に対応してください — ユーザーは prd.md、bmm-prd.md、product-requirements.md などのバリエーションを使用する場合があります。

ドキュメントの欠落: すべてのドキュメントが存在するとは限りません。PRD または仕様は必須です。アーキテクチャ、UX デザイン、プロジェクトコンテキストは利用可能であれば読み込みます。PRD も仕様も見つからない場合は HALT します。

変更のトリガーを確認し、問題についてユーザーの説明を収集する 質問する:「ナビゲーションが必要となる、特定された問題や変更は何ですか?」 プロジェクトドキュメントへのアクセスを確認する: - PRD(製品要件ドキュメント)または仕様 — 必須 - アーキテクチャドキュメント — 任意、利用可能であれば読み込む - UI/UX 仕様 — 任意、利用可能であれば読み込む 変更が影響するエピックとストーリーについてユーザーに説明を求める: それぞれが何を対象とし、どこに位置しているか ユーザーにモードの希望を尋ねる: - **インクリメンタル**(推奨): 各編集を共同で洗練させる - **バッチ**: すべての変更を一度に提示してレビューする モードの選択をワークフロー全体で使用するために保存する

HALT:「トリガーとなる問題を明確に理解しなければ変更をナビゲートできません。何をなぜ変更する必要があるかについて、具体的な詳細を提供してください。」

HALT:「変更の影響を評価するには、PRD または仕様へのアクセスが必要です。いずれかがアクセス可能であることを確認してください。アーキテクチャと UI/UX は利用可能であれば使用されます。」

次を完全に読み、体系的な分析に従う: checklist.md チェックリストの各セクションをユーザーと対話的に進める 各チェックリスト項目のステータスを記録する: - [x] 完了 - 項目は正常に完了しました - [N/A] スキップ - 項目はこの変更に該当しません - [!] 対応が必要 - 項目は注意またはフォローアップが必要です 発見された所見と影響の継続的なメモを維持する 主要なセクションごとにチェックリストの進捗を提示する

ブロッキング問題を特定し、続行する前にユーザーと協力して解決する

チェックリストの所見に基づき、特定された各成果物について明示的な編集提案を作成する

ストーリーの変更について:

• 旧 → 新のテキスト形式を表示する

• 変更するストーリー ID とセクションを含める

• 各変更の根拠を提供する

• フォーマット例:

  Story: [STORY-123] User Authentication
  Section: Acceptance Criteria
  
  OLD:
  - User can log in with email/password
  
  NEW:
  - User can log in with email/password
  - User can enable 2FA via authenticator app
  
  Rationale: Security requirement identified during implementation
  

PRD の修正について:

• 更新する正確なセクションを指定する
• 現在の内容と提案された変更を表示する
• MVP スコープと要件への影響を説明する

アーキテクチャの変更について:

• 影響を受けるコンポーネント、パターン、または技術選択を特定する
• 必要な図の更新を記述する
• 他のコンポーネントへの波及効果を記録する

UI/UX 仕様の更新の場合:

• 特定の画面またはコンポーネントを参照する
• 必要なワイヤーフレームまたはフローの変更を示す
• 変更をユーザー体験への影響と結びつける

各編集提案を個別に提示する HALT してユーザーに選択肢を提示する: - **Approve** — この提案を承認する - **Edit** — この提案を修正する - **Skip** — この提案を破棄する ユーザーが **Approve** を選んだ場合は、提案を保持します。**Edit** を選んだ場合は、ユーザーと一緒に修正します。**Skip** を選んだ場合は、破棄します。次の提案へ進みます。

すべての編集提案を集めて、ステップの最後にまとめて提示する

以下のセクションを含む包括的なスプリント変更提案書を作成する:

セクション 1: 課題の概要

• 変更のきっかけとなった内容を説明する明確な問題記述
• 課題がいつ、どのように発見されたかについての背景
• 課題を示す証拠または例

セクション 2: 影響分析

• エピックへの影響: どのエピックがどのように影響を受けるか
• ストーリーへの影響: 変更が必要な現在および将来のストーリー
• 成果物の競合: 更新が必要な PRD、アーキテクチャ、UI/UX ドキュメント
• 技術的影響: コード、インフラストラクチャ、またはデプロイへの影響

セクション 3: 推奨アプローチ

• チェックリスト評価から選択した今後の進め方を提示する:
  • 直接調整: 既存の計画内でストーリーを修正または追加する
  • 潜在的なロールバック: 完了した作業を元に戻して解決を簡素化する
  • MVP レビュー: スコープを縮小するか目標を修正する
• 推奨に対する明確な根拠を提供する
• 工数見積もり、リスク評価、タイムラインへの影響を含める

セクション 4: 詳細な変更提案

• ステップ 3 で修正したすべての編集提案を含める
• 成果物の種類ごとにグループ化する (ストーリー、PRD、アーキテクチャ、UI/UX)
• 各変更に変更前/変更後と根拠が含まれていることを確認する

セクション 5: 実装への引き継ぎ

• 変更の範囲を分類する:
  • 軽微: 開発者エージェントによる直接実装
  • 中程度: バックログの再編成が必要 (PO/DEV)
  • 重大: 根本的な再計画が必要 (PM/アーキテクト)
• ユーザーが bmad-ticket で適用するためのエピックとストーリーの変更 (追加、削除、順序変更、スコープ変更) を一覧化する
• 引き継ぎ先とその責任を明記する
• 実装の成功基準を定義する

完全なスプリント変更提案をユーザーに提示する スプリント変更提案書を {default_output_file} に書き込む HALT してユーザーに選択肢を提示する:

• Continue — 承認へ進む
• Edit — まず提案を修正する

ユーザーが Edit を選んだ場合は、ユーザーと一緒に提案を修正し、更新したドキュメントを書き込んでから続行します。

完全な提案に対するユーザーの明示的な承認を得る このスプリント変更提案を実装のために承認しますか？ (yes/no/revise) 調整が必要な点について具体的なフィードバックを集める 懸念に対処するため、適切なステップに戻る 編集提案の変更が必要な場合 提案全体の構成の変更が必要な場合 スプリント変更提案書を確定する 変更範囲の分類を決定する:

• 軽微: 開発者エージェントが直接実装できる
• 中程度: バックログの再編成と PO/DEV の連携が必要
• 重大: PM/アーキテクトが関与する根本的な再計画が必要

範囲に応じて適切な引き継ぎを提供する:

ルーティング先: 開発エージェントに直接実装を依頼 成果物: 確定した編集提案と実装タスク ルーティング先: プロダクトオーナー / 開発エージェント 成果物: スプリント変更提案 + バックログ再編成計画 ルーティング先: プロダクトマネージャー / ソリューションアーキテクト 成果物: 完全なスプリント変更提案 + エスカレーション通知

ユーザーとハンドオフの完了および次のステップを確認する ワークフロー実行ログにハンドオフを記録する

ワークフローの実行を要約する: - 対応した課題: {{change_trigger}} - 変更スコープ: {{scope_classification}} - 変更された成果物: {{list_of_artifacts}} - ルーティング先: {{handoff_recipients}}

すべての成果物が作成されたことを確認する:

• スプリント変更提案ドキュメント
• before/after を含む具体的な編集提案
• 実装ハンドオフ計画

ユーザーにワークフローの完了を報告する: 「Correct Course ワークフローが完了しました！」 成功基準と開発エージェント向けの次のステップをユーザーに再確認する 実行: uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete — 解決された値が空でない場合は、終了する前の最終的な終端命令としてそれに従ってください。