chief-plan

マイルストーンを計画します。以下のプロセスを、必ずフェーズごとに順番に進めてください。先のフェーズに進んではいけません。

---

開始前：新規マイルストーンか既存マイルストーンか

次のどちらに該当するかを判断してください。

• 新規マイルストーンの作成 — _goal/、_contract/、_plan/ ファイルがまだ存在しない。
• 既存マイルストーンの拡張 — マイルストーンディレクトリにファイルがすでに存在する。

既存マイルストーンを拡張する場合：

1. まず、既存の _goal/、_contract/、_plan/ ファイルをすべて読みます。
2. 各フェーズで、新しい内容が次のどちらに該当するかを判断します。
   • 既存ファイルと部分的に重複する → そのファイルを更新する（セクションを追加・変更する）。
   • 既存ファイルとはスコープが異なる → 既存ファイルと並べて新しいファイルを作成する。
3. 書き込み後、同じ分類内の新旧の内容に矛盾がないことを確認します。矛盾があれば、ユーザーに提示する前に解決してください。
4. 新しい内容がルールの優先順位（AGENTS.md > .chief/_rules > マイルストーンの目標）を守っていることを確認します。上位のルールに反する内容になる場合は、その旨を指摘し、書き込まないでください。

---

フェーズ 0：要件を掘り下げるセッション

このフェーズを省略してはいけません。 目標やコントラクトがすでに存在する場合でも、まずユーザーへの質問を通じて要件を掘り下げる必要があります。既存ファイルがあっても、要件の掘り下げを行うセッションの代わりにはなりません。既存ファイルに、質問して初めて明らかになる古い、または誤った前提が含まれている可能性があります。

何かを書く前に、要件を明確にするためのセッションを実施してください。

• マイルストーンのあらゆる側面について、共通理解に至るまで徹底的にユーザーに質問します。
• 設計の各分岐を一つずつ検討し、判断事項間の依存関係を順に解決します。
• 各質問について、推奨する回答も提示します。
• 質問は一度に一つずつ行います。
• コードベースの調査で回答できる質問は、ユーザーに尋ねる代わりにコードベースを調査します。

既存マイルストーンを拡張する場合は、次の点についても質問してください。

• 新しい作業が既存の目標やコントラクトとどのように関係するか。
• 既存の目標やコントラクトを見直す必要があるか。
• 既存のタスクに影響するか、優先順位を変更する必要があるか。

要件を掘り下げるセッションが完了したら、重要な決定事項を要約し、先に進む前にユーザーの確認を得ます。

---

フェーズ 1：目標の確認と作成

このフェーズを省略してはいけません。 目標ファイルがすでに存在する場合でも、コントラクトに進む前に、ユーザーに提示して確認と承認を得る必要があります。

要件を掘り下げるセッションに基づき、.chief/<milestone>/_goal/ の下にマイルストーンの目標ファイルを作成または更新します。

目標がすでに存在する場合：

• 各目標ファイルを読み、フェーズ 0 で決定した内容と一致していることを確認します。
• 要件を掘り下げるセッションで既存の目標が誤っている、または不完全であると判明した場合は、この段階で更新します。
• 既存の目標と、新規または変更した目標の両方をユーザーに提示します。

既存マイルストーンを拡張する場合：

• 新しいスコープが重複する場合は、既存の目標ファイルを更新します。
• スコープが異なる場合は、新しい目標ファイルを作成します。
• 同じマイルストーン内で目標同士に矛盾がないこと、また .chief/_rules/_goal/ や AGENTS.md と矛盾する目標がないことを確認します。

ここで停止してください。 新規および変更した目標をユーザーに提示します。既存の内容からの変更点を明示してください。先に進む前に、ユーザーから明示的な承認を得てください。

---

フェーズ 2：コントラクトの作成

.chief/<milestone>/_contract/ の下にマイルストーンのコントラクトを作成または更新します。

既存マイルストーンを拡張する場合：

• 新しいスコープが重複する場合は、既存のコントラクトファイルを更新します（例：既存のスキーマへのフィールドの追加）。
• スコープが異なる場合は、新しいコントラクトファイルを作成します（例：新しい API エンドポイント）。
• 同じマイルストーン内でコントラクト同士に矛盾がないこと、また .chief/_rules/_contract/ や AGENTS.md と矛盾するコントラクトがないことを確認します。

ここで停止してください。 新規および変更したコントラクトをユーザーに提示します。既存の内容からの変更点を明示してください。先に進む前に、ユーザーから明示的な承認を得てください。

---

フェーズ 3：TODO を作成する

.chief/<milestone>/_plan/_todo.md に、新しいタスクを 3～5 件追加するか、ファイルを更新します。

既存の TODO を拡張する場合：

• 新しいタスクは既存のタスクの下に追加します（完了済みのタスクを削除したり、順序を入れ替えたりしないでください）。
• 新しい作業によって既存の未完了タスクが無効になったり、置き換えられたりする場合は、その旨を明記します（例：- [ ] ~~task-2: old scope~~ → superseded by task-5）。
• タスク番号は、最後の既存のタスク番号から続けます。

停止してください。 更新した TODO リストをユーザーに提示します。新規および変更した項目を強調します。明示的な承認が得られるまで待機します。

---

フェーズ 4：タスク仕様を作成する（任意）

ユーザーに「詳細なタスク仕様を作成しますか、それともスキップしますか？」と尋ねます。

スキップの場合 → スキルを終了します。Builder-agent は TODO と目標、契約を基に作業します。

作成する場合 → 詳細なタスク仕様を .chief/<milestone>/_plan/task-<n>.md に作成します。

既存の TODO を拡張する場合：

• 新しく追加したタスクの仕様のみを作成します。
• 新しいタスクが既存のタスク仕様に記載された動作を変更する場合は、その仕様を参照し、相違点を説明します。

停止してください。 タスク仕様をユーザーに提示します。Builder-agent への委任前に、明示的な承認が得られるまで待機します。

---

競合解決ルール

各フェーズで、ユーザーに提示する前に次の点を確認します。

1. 同一バケット内の整合性 — 同じバケット（_goal/、_contract/、_plan/）内のファイル同士に矛盾がないこと。
2. バケット間の整合性 — 目標、契約、タスクが互いに整合していること（例：タスクが存在しない契約を参照していないこと）。
3. 階層ルールへの準拠 — より上位のルールに矛盾していないこと：
   • AGENTS.md がすべてに優先します。
   • .chief/_rules/** はマイルストーン単位の内容に優先します。
   • マイルストーンの _goal/ は最も優先度が低いものです。

競合が見つかった場合：

• 競合する両方の内容を示し、ユーザーに明確に伝えます。
• 解決案を提示します。
• 競合が解決されるまで先に進みません。

---

差し戻しルール

後のフェーズでユーザーからのフィードバックにより、前のフェーズの成果物に誤りや不足があると判明した場合、必ず前のフェーズに戻って修正します。壊れた前段階を回避するために、現在のフェーズで取り繕ってはいけません。

例：

• 契約のレビューで目標の前提が誤っていると判明した場合 → フェーズ 1 に戻り、目標を修正して承認を得てから、フェーズ 2 に進みます。
• TODO のレビューで契約にフィールドが不足していると判明した場合 → フェーズ 2 に戻り、契約を修正して承認を得てから、フェーズ 3 に進みます。

フェーズの順序は前後とも厳守します。前に進む場合は飛ばさず、後戻りする場合は必ず上流を修正します。

---

一般ルール

• ルールの階層に従います：AGENTS.md > .chief/_rules > マイルストーンの目標。
• ゲートでユーザーが内容を却下または変更した場合は、先に進む前に修正します。
• このスキルでは Builder-agent または tester-agent に委任しません。計画のみを行います。