milestone-planning

マイルストーン計画

目的

明確な方向性をロードマップの構成に落とし込みます。このスキルが担うのは、タスク単位の設計ではなく、ドキュメントのガバナンスです。

使用する場面

• 分解できる程度に、計画の方向性が明確になっている
• マイルストーンの境界、モジュールのグループ分け、またはタスクの分解について、まだ決める必要がある
• タスク単位の spec.md 作業を始める前に、ユーザーがロードマップレベルのタスクを必要としている

使用しない場面

• 目標、制約、または今取り組む範囲と後回しにする範囲が、まだ本当に不明確である
• 現在のタスクが、確定済みのロードマップからすでに選択されている
• 現在の作業が、タスク単位の仕様書、計画、実装、またはブランチのクローズである

最初に読むもの

• docs/tasks/index.md
• docs/tasks/planning-inbox.md
• docs/tasks/backlog.md
• docs/tasks/ 以下の関連するマイルストーン、モジュール、タスクのドキュメント
• 現在のユーザープロンプト

担当するもの

• マイルストーンの境界
• 任意のモジュール境界
• ロードマップレベルのタスク分解
• Roadmap confirmed の状態とその影響
• planning-inbox、backlog、Handoff Notes のガバナンス
• 計画レビューの一時停止と、計画の引き継ぎに必要なコンテキスト

担当しないもの

• タスク単位の spec.md
• タスク単位の plan.md
• 実行環境の分離や実装
• 準備状況の確認、検証フロー、またはブランチのクローズ
• ロードマップ構成を装った実装レベルの順序づけ

開始時の確認事項

• 計画の方向性がまだ定まっていない場合は、planning-clarification に差し戻します。
• Open Milestones が空の場合は、分解する前に planning-inbox.md、backlog.md、プロンプトの根拠を確認します。
• 具体的な短期目標またはロードマップとの不整合を示す根拠がない場合は、計画モードについて質問します。
• ユーザーが Roadmap confirmed: no の状態で作業開始を求めている場合は、マイルストーンの構成が明示的に確定するまで、分解を暫定扱いにします。
• ユーザーが後続のマイルストーンに進む場合は、まず前のマイルストーンの完了を確定します。
• マイルストーンを確定する場合、または Roadmap confirmed: no を yes に変更する場合は、マイルストーンの目標に合致する繰り越しタスクがないか backlog.md を確認します。

標準フロー

1. 現在の課題が計画の曖昧さではなく、ロードマップの構成に関するものかを確認します。
2. 機能数ではなく、提供目標、フェーズの境界、または終了基準に基づいてマイルストーンの境界を決めます。
3. 明確に異なるオーナーシップ、リスク、依存関係、リリース、または受け入れの境界を持つ、複数の持続的な能力領域がある場合にのみ、モジュールを追加します。
4. 一貫した能力の成果ごとにロードマップのタスクを分割します。各タスクは、それぞれ独立してレビュー、引き継ぎ、完了できるものにします。
5. マイルストーンを確定する際は、該当する backlog.md のタスクをマイルストーンに昇格させるか、繰り越すことを明示します。
6. マイルストーン、モジュール、タスクの境界を定めた理由をロードマップのドキュメントに記録します。
7. ロードマップのドキュメントを作成または再編成した後、計画レビューのために一時停止します。

境界ルール

• マイルストーンの境界は、マイルストーンの規模を見た目上均等に保つことではなく、リリースやフェーズの意味に基づきます。
• 元の依頼の範囲が広いというだけで、巨大なマイルストーンをひとつのままにしないでください。実際のフェーズ、完了条件、リリースの境界がある場合は分割してください。
• モジュールは任意です。ひとつの機能領域に対して、何でも入る単一のモジュールを作成しないでください。
• 孤立したタスクを入れるためだけの、小規模な単発モジュールを作らないでください。
• タスクの境界は、実装設計より上位に保つ必要があります。ロードマップのタスクには、コード変更の順序ではなく、実現する機能を記述してください。
• core、foundation、mvp、polish などの曖昧なタスク名の中に、選択可能な複数の機能を隠さないでください。
• ファイル、エンドポイント、テスト、マイグレーション、リファクタリングの作業単位をロードマップのタスク名にしないでください。
• 実装、テスト、ドキュメント、検証、レビュー後の対応を、それぞれ別のロードマップタスクに分けないでください。ただし、それらのガバナンス作業そのものがユーザーに見える成果となる場合を除きます。
• タスクの順序は、数値のディレクトリ接頭辞ではなく、関連する順序付きリストで管理してください。
• アクティブなマイルストーンの進行中に新たに見つかった将来の作業は、デフォルトではタスク固有の plan.md ではなく、そのマイルストーンの Handoff Notes にまず記載してください。
• planning-inbox.md には目標とマイルストーン候補の方向性を記録し、具体的なタスクは記録しないでください。
• backlog.md には延期された具体的なタスクを記録し、広範な目標は記録しないでください。

目標の定義

• 目標とは、望ましい将来の状態、製品の成果、機会、またはフェーズの方向性です。ロードマップの形を決める前に、何を実現すべきか、そしてそれがなぜ重要なのかを説明します。
• 目標は通常、ひとつの実装タスクより広い範囲を指しますが、非常に大きい必要はありません。後にひとつのマイルストーンや複数のマイルストーンになることもあれば、明確化の結果、破棄されることもあります。
• 目標とは、コード変更、エンドポイント、マイグレーション、テストスイート、リファクタリングの作業単位、またはすでに選択可能な実装成果ではありません。
• フェーズの方向性を先に決めなくても、成果、概ねの範囲、受け入れチェックリスト、成功の指標を含む具体的な task.md を作成できる場合は、その項目をタスクとして扱ってください。
• 計画インボックスの項目を昇格させると、フェーズ境界について新たな判断をすることなく、マイルストーンと、それと同名の単一タスクが自然に作成される場合、その項目自体が実際のリリース、マイグレーション、またはフェーズの境界でない限り、バックログタスクまたは現在のマイルストーンのタスクに分類し直してください。
• 目標には、想定される実装手段ではなく、成果やフェーズを名前にしてください。

例：

• 計画インボックスに適した目標：API contract stability。目標の説明例：「バックエンドのレスポンスを予測しやすくし、フロントエンドと外部クライアントが成功、バリデーションエラー、業務エラーを一貫して処理できるようにする。」
• 目標ではなく、タスクに該当する項目：Unify API business error model and response envelope。これはすでに具体的な実装成果を示しており、ひとつの task.md になる可能性があります。
• このタスクに適した分類：Unify API business error model and response envelope を backlog.md または現在のマイルストーンに記載し、必要に応じて API contract stability のような目標の下に位置づけます。
• この目標から生まれる適切なマイルストーン：API Contract Stabilization。終了条件には、レスポンスの仕様が文書化されていること、クライアントにとって安全な互換性があること、コントラクトテストがあることなどを含めます。
• このマイルストーンに適したタスク：Define response envelope and business error semantics、Adapt callers to the unified response contract、Add API contract coverage and migration notes。
• 不適切な昇格例：計画インボックスの目標 Unify API business error model and response envelope → マイルストーン Unify API business error model and response envelope → 単一タスク Unify API business error model and response envelope。これはロードマップ上の判断を行わず、各階層でラベルを重複させています。

Handoff Notes の振り分け

• Handoff Notes は、タスク固有の plan.md ではなく、現在のマイルストーンの index.md に記録します。
• 現在のマイルストーンの終了基準を満たすために完了が必須の場合のみ、その項目を現在のマイルストーンに残します。
• 明らかに将来のマイルストーンに相当する作業であり、現在のマイルストーンを完了するために必須ではない場合は、その項目を後続のマイルストーンに移します。
• マイルストーンに割り当てられていない、具体的なタスクに相当するフォローアップ項目は、docs/tasks/backlog.md に移します。
• まだマイルストーンにできる段階ではない目標、フェーズ、機会、方向性は、docs/tasks/planning-inbox.md に移します。
• 明示的に破棄された場合、または追跡する価値がなくなった場合のみ、その項目を削除します。
• ユーザーが、現在の進行を中断するほど優先度が高いと明示的に判断した場合は、引き継ぎのみのフォローアップとして残さず、計画を立て直します。

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

• 新しいロードマップタスクのステータスは planned から始めます。
• タスクを分解、順序付け、または将来の候補として選定しただけの場合は、planned のままにします。
• タスク固有の準備作業または実装作業が実際に始まった場合のみ、タスクを in_progress にします。
• 選定したタスクが、外部依存関係、未解決の判断事項、失敗した前提条件、または明示的な停止条件によって現時点で進行できない場合のみ、blocked を使用します。
• ロードマップの計画だけを根拠に、タスクを completed にしないでください。完了は、実装、検証、必要なドキュメントやステータスの更新、および完了時の結果が確定した後の実行段階で判断します。
• タスクの Status は常に単一の選択肢にします。

Planning inbox

• planning-inbox.md は目標のレイヤーです。将来のプロダクト目標、機会、候補となるフェーズ、および長期的なロードマップの方向性を記録します。
• Planning inbox の目標には、実装を担う具体的なタスクではなく、計画対象となる将来の状態またはフェーズを記述します。
• 具体的なタスクに相当する作業を planning-inbox.md に記録しないでください。未完了のマイルストーンに属さない場合は、backlog.md に移します。
• 目標が未完了のマイルストーンにできる段階になった場合、または計画上の明確化が必要になった場合は、planning-inbox.md からその項目を取り出します。
• Planning inbox の目標がマイルストーンになったら、backlog.md を確認し、その目標に該当する保留中のタスクを探します。

Backlog

• backlog.md はタスクのレイヤーです。保持する価値はあるものの、未完了のマイルストーンに割り当てられていない、具体的な保留中のタスクを記録します。
• Backlog の項目はタスクとして具体化されている必要があります。成果、概略のスコープ、起点、および適合する可能性のある目標やマイルストーンを含めます。
• マイルストーンの計画、マイルストーンの確認、または Roadmap confirmed: no から yes への変更によって項目がアクティブなマイルストーンの検討対象になった場合は、backlog.md からその項目を取り出します。
• Backlog の項目は、マイルストーンのタスクに昇格した場合、明示的に破棄された場合、または別のタスクに置き換えられた場合に削除します。

ブロックされている場合

• 具体的な短期目標、または方向性のずれを特定する根拠がない場合は、計画モードについて次の質問をします。
  • Do you already have a concrete short-term target for this iteration, or do we need to realign the next stage of the roadmap first?
• ロードマップの構成が、未解決の目標や境界の曖昧さに依存している場合は、planning-clarification に戻します。
• マイルストーンの確認、完了、またはマイルストーンをまたぐ移動を妨げる未解決事項がある場合は、作業を停止してユーザーに直接確認します。

レビューとフォローアップ

• ロードマップのドキュメントを変更した後は、計画レビューの確認待ちで停止します。
• そのレビュー待ちの後に、進行を明確に示す表現があれば、通常のフォローアップを進める許可とみなします。
• レビュー後の通常のフォローアップでは、次の対応を既定とします。
  • レビュー済みの計画ドキュメントをコミットします。
  • ユーザーがコミットせずに残すよう明示的に依頼した場合を除きます。
  • その後、引き継ぎの状況を報告し、次に適用される段階へ進みます。
• 計画レビューの承認を、未解決の必須確認事項を省略する許可とみなさないでください。

厳格なゲート

• 先行するマイルストーンが未解決のまま未完了に見える場合は、後続のマイルストーンに進まないでください。
• ロードマップの構成が明示的に未確認のままの場合、continue をマイルストーンの確認として扱わないでください。
• Handoff Notes の項目が未解決のまま残っている場合は、マイルストーンを完了にしないでください。
• 完了したマイルストーンに追加作業を加えないでください。代わりに、新しい未完了のマイルストーン、バックログタスク、または計画インボックスの目標を作成してください。

出力

• 推奨するマイルストーン構成
• 1つのマイルストーンにする理由、または複数にする理由
• モジュールが必要かどうか
• マイルストーンまたはモジュールごとのタスクリスト
• 明白でない場合は、提供順序
• 前提条件または未解決の質問

停止地点

• 計画レビューの一時停止
• またはロードマップの曖昧さ、確認、完了に関する直接的な阻害要因の質問

引き継ぎ

• Decided
• Undecided
• Next skill
• Stop point

参考資料

• ロードマップ文書の形式には、references/roadmap-template.md を使用してください。