gds-correct-course

Correct Course - スプリント変更管理ワークフロー

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

あなたの役割： あなたは変更管理に取り組む開発者です。変更のきっかけとなった問題を分析し、GDD、エピック、アーキテクチャ、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

スクリプトが失敗した場合は、以下の 3 つのファイルを base → team → user の順に読み込み、リゾルバーと同じ構造マージ規則を適用して、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：設定を読み込む

{project-root}/_bmad/gds/config.yaml から設定を読み込み、次の項目を解決します。

• project_name、user_name
• communication_language、document_output_language
• game_dev_experience
• implementation_artifacts
• planning_artifacts
• project_knowledge
• システムが生成した現在の日時を date として設定
• 出力では、必ず設定の {communication_language} に沿ったエージェントのコミュニケーションスタイルを使用してください。
• 言語は {game_dev_experience} に合わせる必要があります。
• すべてのドキュメントを {document_output_language} で作成してください。
• ドキュメントの出力：更新後のエピック、ストーリー、または GDD のセクション。明確で実行可能な変更を記載してください。ゲーム開発の経験（{game_dev_experience}）が影響するのは会話スタイルのみであり、ドキュメントの更新には影響しません。

ステップ 5：ユーザーに挨拶する

{user_name} に、{communication_language} で挨拶します。

ステップ 6：末尾に追加するステップを実行する

{workflow.activation_steps_append} の各項目を順番に実行します。

アクティベーションが完了しました。activation_steps_prepend または activation_steps_append に項目が含まれていた場合は、すべての項目を順番どおりに実行したことを確認してから続行します。アクティベーションのステップをすべて完了するまで、メインワークフローを開始しないでください。

パス

• default_output_file = {planning_artifacts}/sprint-change-proposal-{date}.md

入力ファイル

入力	パス	読み込み戦略
GDD	{planning_artifacts}/*gdd*.md（全体）または {planning_artifacts}/*gdd*/*.md（分割）	FULL_LOAD
ナラティブ	{planning_artifacts}/*narrative*.md（全体）または {planning_artifacts}/*narrative*/*.md（分割）	FULL_LOAD
エピック	{planning_artifacts}/*epic*.md（全体）または {planning_artifacts}/*epic*/*.md（分割）	FULL_LOAD
アーキテクチャ	{planning_artifacts}/*architecture*.md（全体）または {planning_artifacts}/*architecture*/*.md（分割）	FULL_LOAD
UX デザイン	{planning_artifacts}/*ux*.md（全体）または {planning_artifacts}/*ux*/*.md（分割）	FULL_LOAD
技術仕様	{planning_artifacts}/*tech-spec*.md（全体）または {planning_artifacts}/*spec-*.md（全体）	FULL_LOAD
プロジェクト文書	{project_knowledge}/index.md（分割）	INDEX_GUIDED

コンテキスト

• 存在する場合は **/project-context.md を読み込みます

実行

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

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

FULL_LOAD ドキュメント（GDD、ナラティブ、エピック、アーキテクチャ、UX デザイン、技術仕様）の検出プロセス：

1. まず全体ドキュメントを検索 — 全体ドキュメントのパターンに一致するファイルを探します（例：*gdd*.md、*narrative*.md、*epic*.md、*architecture*.md、*ux*.md、*tech-spec*.md）
2. 分割版を確認 — 全体ドキュメントが見つからない場合は、index.md を含むディレクトリを探します（例：gdd/index.md、epics/index.md）
3. 分割版が見つかった場合：
   • index.md を読み込み、ドキュメントの構成を把握します
   • インデックスに記載されたすべてのセクションファイルを読み込みます
   • 結合した内容を単一のドキュメントとして処理します
4. 優先順位：全体版と分割版の両方が存在する場合は、全体版を使用します

INDEX_GUIDED ドキュメント（プロジェクト文書）の検出プロセス：

1. インデックスファイルを検索 — {project_knowledge}/index.md を探します
2. 見つかった場合：インデックスを読み込み、利用可能なドキュメントのセクションを把握します
3. 変更の分析に関連するセクションを選択して読み込みます。すべてを読み込まず、影響を受ける領域に関連するセクションのみを対象とします
4. このドキュメントは任意です — {project_knowledge} が存在しない場合（グリーンフィールドプロジェクト）はスキップします

あいまい一致：ドキュメント名は柔軟に扱います。ユーザーが gdd.md、game-design-document.md などの別名を使用している場合があります。

ドキュメントが見つからない場合：すべてのドキュメントが存在するとは限りません。GDD とエピックは必須です。アーキテクチャ、UX デザイン、技術仕様、ナラティブ、プロジェクト文書は、利用可能な場合に読み込みます。GDD またはエピックが見つからない場合は HALT します。

コーディング規約とプロジェクト全体のパターンを確認するため、存在する場合は **/project-context.md を読み込みます 変更のきっかけを確認し、問題についてユーザーから説明を得ます 次のように尋ねます：「ナビゲーションが必要となる、具体的に特定された問題または変更は何ですか？」 必要なプロジェクトドキュメントにアクセスできることを確認します： - GDD（ゲームデザインドキュメント） - 現在のエピックとストーリー - アーキテクチャドキュメント - UI/UX 仕様 - ナラティブデザインドキュメント ユーザーにモードの希望を尋ねます： - **段階的**（推奨）：各編集内容を共同で調整します - **一括**：すべての変更を一度に提示してレビューします ワークフロー全体で使用するため、モードの選択を保存します

HALT: 「変更のきっかけとなる問題を明確に把握できないため、変更のナビゲーションを進められません。変更が必要な内容と理由について、具体的に説明してください。」

HALT: 「変更の影響を評価するには、プロジェクトドキュメント（GDD、エピック、アーキテクチャ、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
  

GDD の変更について：

• 更新する正確なセクションを指定する
• 現在の内容と変更案を示す
• MVP の範囲と要件への影響を説明する

ナラティブデザインの変更について：

• 更新する正確なセクションを指定する
• 現在の内容と変更案を示す
• ストーリー、キャラクター、または世界観の一貫性への影響を説明する

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

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

UI/UX 仕様の更新について：

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

各編集案を個別に提示する この変更を確認して調整しますか？選択肢：承認 [a]、編集 [e]、スキップ [s] ユーザーのフィードバックに基づいて、各提案を繰り返し調整する

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

以下のセクションを含む、包括的なスプリント変更提案書を作成してください：

セクション 1：問題の概要

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

セクション 2：影響分析

• エピックへの影響：影響を受けるエピックとその影響
• ストーリーへの影響：変更が必要な現在および今後のストーリー
• 成果物の不整合：更新が必要な GDD、ナラティブ、アーキテクチャ、UI/UX のドキュメント
• 技術的な影響：コード、インフラストラクチャ、またはデプロイへの影響

セクション 3：推奨するアプローチ

• チェックリストの評価に基づき、選択した今後の進め方を提示する：
  • 直接調整：既存の計画内でストーリーを変更または追加する
  • ロールバックの検討：解決を簡素化するため、完了した作業を元に戻す
  • MVP の見直し：範囲を縮小するか、目標を変更する
• 推奨する理由を明確に示す
• 作業量の見積もり、リスク評価、スケジュールへの影響を含める

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

• ステップ 3 で調整したすべての編集案を含める
• 成果物の種類（ストーリー、GDD、ナラティブ、アーキテクチャ、UI/UX）ごとにまとめる
• 各変更に変更前／変更後と根拠を含める

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

• 変更の範囲を分類する：
  • 軽微：開発者エージェントが直接実装
  • 中程度：バックログの再編成が必要（PO/DEV）
  • 大規模：根本的な再計画が必要（PM/アーキテクト）
• 引き継ぎ先とその担当業務を指定する
• 実装の成功基準を定義する

完全なスプリント変更提案をユーザーに提示する スプリント変更提案のドキュメントを {default_output_file} に書き込む 提案全体を確認してください。続行する場合は [c]、編集する場合は [e] を選択してください。 完全な提案について、ユーザーから明示的な承認を得る このスプリント変更提案を実装に進めることを承認しますか？（yes/no/revise） 修正が必要な箇所について具体的なフィードバックを集める 懸念に対応するため、適切なステップに戻る 提案の編集に変更が必要な場合 提案全体の構成に変更が必要な場合 スプリント変更提案のドキュメントを確定する 変更範囲の分類を決定する：

• 軽微：開発者エージェントが直接実装できます
• 中程度：バックログの再編成とPO／開発者間の調整が必要です
• 大規模：PM／アーキテクトが関与する抜本的な再計画が必要です

変更範囲に応じて適切な引き継ぎを行う：

担当先：開発者エージェントが直接実装 成果物：確定した編集提案と実装タスク 担当先：プロダクトオーナー／開発者エージェント 成果物：スプリント変更提案とバックログ再編成計画 担当先：プロダクトマネージャー／ソリューションアーキテクト 成果物：完全なスプリント変更提案とエスカレーション通知

ユーザーとともに、引き継ぎの完了と次のステップを確認する ワークフロー実行ログに引き継ぎを記録する

ワークフローの実行内容を要約する： - 対応した課題：{{change_trigger}} - 変更範囲：{{scope_classification}} - 変更した成果物：{{list_of_artifacts}} - 引き継ぎ先：{{handoff_recipients}}

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

• スプリント変更提案のドキュメント
• 変更前／変更後を示す具体的な編集提案
• 実装への引き継ぎ計画

「Correct Course ワークフローが完了しました、{user_name} さん！」という個別メッセージを添えて、ワークフローの完了をユーザーに報告する 成功基準と開発者エージェントの次のステップをユーザーに伝える

次を実行する：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete — 解決された値が空でない場合は、終了前の最後の指示としてそれに従う。