plan-milestones

マイルストーンを計画する

docs/roadmap/INDEX.md を作成・保守します。これは、製品ビジョンと個々の機能仕様の間に位置するプログラム層です。つまり、どのマイルストーンが存在するか、どの順序か、どの作業を含むか、実際にコミットされているかを定めます。位置付け： define-project（ビジョン）→ plan-milestones（マイルストーン）→ frame-change → specify-behavior → … ロードマップ項目は、機能コードの唯一の登録者である specify-behavior が docs/specs/INDEX.md に登録すると、機能になります。このスキルがそのファイルに触れることはありません。

絶対原則

THE ROADMAP RECORDS INTENT. PROGRESS IS DERIVED, NEVER STORED HERE.

意図は、どのツールにも自力では判断できないものです。マイルストーンが約束する成果、順序、含まれる作業、延期された内容とその理由、そして人間がそれにコミットしたかどうかです。進捗はすでに一度だけ記録されています。各機能の requirements.md にある Status: として記録され、docs/specs/INDEX.md の該当行にも反映されています。ここにコピーをもう一つ作っても、その記録との間にずれが生じるだけです（理由は「合理化」を参照）。

そのため、このファイルには進捗列、ステータスフィールド、変更履歴、完了率を含めません。/refresh-roadmap-status が、仕様書と git から必要に応じて現在の状況を導き出します。ただし、Commitment は進捗ではありません。Planned | Committed | Closed は、誰にも導き出せない人間の決定を記録するものです。このフィールドは残し、進捗を追跡するものは追加しないでください。

モード

• create — docs/roadmap/INDEX.md がありません。作成します。
• update — ファイルが存在します。変更のシグナルをもとに見直します。

パックのシードは、次の順に解決します。最初に存在するパスを使います。(1) この SKILL.md の隣にある templates/、(2) 変数が設定されている場合は ${CLAUDE_PLUGIN_ROOT}/templates、(3) この SKILL.md からの相対パス ../../../templates。templates/roadmap-INDEX.md の見出しはすべて必須の項目です。各項目を埋めるか、None と記述してください。コメントブロックに、権威ある構造ルール S1–S8 と ID ルールが記載されています。ルールをここで書き直さず、テンプレートで確認してください。

作成

1. 入力を読む： マイルストーンが参照する **GOAL-N** ID を確認するため、docs/product/vision.md が存在する場合は読みます。ブラウンフィールドプロジェクトですでに出荷された作業は、どこにも含まれないのではなく、初期のマイルストーンに含める必要があるため、docs/specs/INDEX.md も読みます。また、frame-change から渡された分解情報があれば確認します。 完了条件：対象となる目標と、すでに出荷された作業を説明できます。
2. テンプレートを埋める：テンプレートを docs/roadmap/INDEX.md に反映します。マイルストーンごとに MILE-N を1つ、各項目には ROAD-N を1つ付与し、ID とスラッグで識別して、必ず1つのマイルストーンの下に置きます。 完了条件：すべての必須項目が埋まっているか、None と記されています。
3. ユーザー価値でグループ化する。 マイルストーンの Outcome: には、達成時に利用者ができることを、1文で記述します。コードを見ていない読者が検証できる内容にしてください。「ストレージ層を書き換える」のように作業内容しか表現できない成果は、マイルストーンではなく技術レイヤーです。それを実現するマイルストーンに含めてください。設計が固まっている場合は、マイルストーンの数を減らして規模を大きくします。早期のフィードバックによって後続の内容が変わる可能性がある箇所では分割します。 完了条件：すべてのマイルストーンに検証可能な成果があります。
4. 目標を記載する。 ビジョンがある場合は、各マイルストーンの Goals: に、そのマイルストーンが支援する有効な GOAL-N ID を記載します。どのマイルストーンからも参照されない有効な目標はすべて、日付と理由を付けて ## Goal dispositions の下に Deferred または Out-of-scope として記載します。ビジョンがない場合は Goals: None と記述し、処置テーブルは空のままにします。 完了条件：有効な目標がすべて考慮されているか、ビジョンがありません。
5. 順序と対象範囲を明記する。 各項目の After: には、テンプレートの形式で、依存するものを記載するか、none と記述します。Surfaces: には、対象となるコンポーネントまたはパスを記載します。対象範囲がまだ分からない場合は、理由を添えて None と記述します。 完了条件：すべての項目に After: と Surfaces: の行があります。
6. ## The approval gate を実行します。

更新

変更のきっかけとなるのは、新たなマイルストーン、順序の変更、スコープの変更、コミットメント、完了、または不要になった項目です。

順序の変更は、影響を受ける各マイルストーンのすべての項目に、テンプレートの形式で After: を記載します。 After: がある場合、リスト上の位置だけでは順序を示しません。

ファイル内にすでにあるすべての ID は固定です。 表の並べ替えで変わるのは順序だけで、ID は変わりません。別のマイルストーンに移動した項目も、元の ROAD-N を保持します。項目を廃止する場合は、理由を添えて取り消し線にする場合に限ります — ~~**ROAD-4**~~ dropped 2026-07-25: no custom search UI — これにより履歴が読みやすく保たれ、参照が宙に浮くこともありません。不要になった項目は削除せず、延期します。日付と理由を添えて、そのマイルストーンの Deferred: 枠に移してください。行を削除すると、その選択肢が検討されたことを示す唯一の記録が失われます（Rationalizations を参照）。

Approved のロードマップに重大な変更を加えると、承認状態は取り消されます。 Status: Draft に設定してから、ゲートを再度実行してください。重大な変更とは、マイルストーンの成果、構成項目、順序、コミットメントの状態、または目標の引用のいずれかを変更することです（編集しても事前承認が維持されない理由については Rationalizations を参照）。

マイルストーンの完了 — Committed → Closed への遷移の場合に限り、ほかのすべての編集ではスキップします — は、そのマイルストーンが達成されたと宣言するものです。このファイルだけでは、自らそう主張したところで達成を立証できません。

評価の引き継ぎがない `Committed → Closed` への遷移は拒否し、ユーザーに `/assess-milestone` の実行を案内してください。このルールは、該当スキルを一度も実行したことがないリポジトリも含め、すべてのリポジトリに適用されます。

書き込み引き継ぎとして、MILE-N、評価の序数、有効な判定、完了候補のリビジョン SHA が渡された場合、その序数に対応する docs/roadmap/assessments/<MILE-N>.md を読み、すべての値を再導出してください。書き込み引き継ぎの値は確認すべき主張であり、信頼すべき事実ではありません。次の5項目すべてを検証してください。

1. ブロックに同じ MILE-N が記載されている。
2. 参照された序数が存在する。
3. Candidate closing revision が、書き込み引き継ぎの SHA と一致する。
4. 現在の Human disposition が終端状態（Accepted または Overridden）である。
5. 有効な判定と Close decision が、書き込み引き継ぎで主張されている内容と一致する。

不一致があれば、完了を拒否し、どの値が一致しなかったかを報告してください。まず templates/milestone-assessment.md の A1–A7 に照らして検証してください。解析できない評価で、何かを承認することはできません。

ゲートを通過したら、このファイルの隣にある closure-writeback.md を読み、その指示に厳密に従ってください。Closed: SHA の書き込みと、承認ゲートの再実行が記載されています。

完了条件：変更が適用され、ID の移動や消失がなく、ゲートが実行されていること。

承認ゲート

docs/agents/issue-tracker.md の Draft surface が notion の場合は、このゲートの前に、このファイルの隣にある notion-draft.md を読み、その指示に従ってください。承認担当者はそのページを承認します。

テンプレートのルールブロックにある S1–S8 を検証してください。見つかった不備をすべて報告して停止してください。構造上の不備があるロードマップを、承認のためにユーザーへ提示してはいけません。ファイルに問題がなければ、全体を提示して停止してください。`Status: Approved` と記載するのは、ユーザーが明示的に承認した後に限ります。会話上の同意は承認ではありません。自分で承認したロードマップは、承認されたことにはなりません。

S1–S8 をチェックリストとして順に確認し、不備があれば項目名と該当箇所を示してから、ファイルを提示して停止してください。承認後は Status: Approved に設定してください。ユーザーが希望するたびに、/refresh-roadmap-status で計画の進捗状況を報告します。

完了条件：S1–S8 の確認に問題がなく、ユーザーが書面のファイルを承認し、Status: が Approved になっていること。

ROAD-N はスロットであり、機能ではありません

このルールを記載する場所はここだけです（ほかのスキルはここを参照してください。表を別の場所に再掲しないでください）。

	ROAD-N（プログラムのスロット）	Feature CODE（提供の単位）
保存場所	docs/roadmap/INDEX.md	docs/specs/ ＋ INDEX の行
トライアドの前に存在するか	はい — 仕様化されていない状態が通常です（R7）	specify-behavior が登録してからのみ
進捗	ここには保存しません	要件／INDEX の Status:
紐付け	—	INDEX の Roadmap item → 1 つの ROAD に対して最大 1 つの CODE（R6）

ROAD を作成しても機能は作成されません。紐付けは後で、specify-behavior が INDEX のセルに記入するときに行われます。スラッグのテキストが一致しても、ID が統合されるわけではありません。マイルストーンの成果には、複数の ROAD スロット（メンバーリストの順序）が必要になることがよくあります。作業開始時に、それぞれが個別の機能に紐付けられます。マイルストーン全体を 1 つの CODE にまとめてはならず、1 つの ROAD に 2 つの CODE を割り当ててもなりません（R6）。このスキルでは、リモートのトラッカープログラムオブジェクト（GitHub milestones、Linear initiatives、Projects）も作成しません。ミラーリングは configure-repo → docs/agents/issue-tracker.md の Program sync でオプトインでき、デフォルトではローカルのみです。

合理化

以下の各行は、ベースライン実行での合理化、またはその直接的な反響をそのまま記載したものです。

考え	実情
「ステータス列があれば追跡できる」	古くなります。機能の進捗は requirements.md の Status: に記録し、INDEX の行に反映します。残りは /refresh-roadmap-status が導出します
「ステータスの履歴を残すため、変更ログを追加しよう」	それは別の帽子をかぶった、同じ二重コピーです。Git にはすでにこのファイルの履歴が保存されています
「マイルストーン単位で機能のライフサイクルを再利用しよう」	Draft → Approved → In-progress → Implemented → Shipped は仕様を表します。マイルストーンが示すのはコミットメントであり、ライフサイクルではありません
「共有が以前より重要なので、MILE-2 にしよう」	順序は表の位置、識別子は ID です。行を移動しても番号はそのままにします
「自然な順序になるよう番号を振り直した」	番号を振り直すたびに、古い番号を参照していたものすべてが、気付かないうちに別のものを指すようになります
「実施しないので、その行を削除しよう」	日付と理由を添えて延期してください。項目を削除すると、その理由も一緒に失われます
「これは計画上の成果物だから、承認ゲートは適用されない」	承認ゲートがあるからこそ、ロードマップは誰かが書いた下書きではなく、コミットメントになります。ゲートは適用されます
「ユーザーが承認者で、今回の編集を依頼したのだから、Approved のままでよい」	依頼されたのは編集であり、結果を事前承認することではありません。Draft に戻し、ユーザーが新たに引き受ける内容を示してください
「2 週間前に承認済みで、これは単なる修正にすぎない」	修正された計画は別の計画です。独自の承認が必要です
「ここにはテンプレートがないので、形式を考えよう」	形式は templates/roadmap-INDEX.md にあります。形式を 2 種類作ると、1 つのルールセットでは確認できません
「ROAD のスラッグと機能が同じなので、同一の ID だ」	スロットと提供単位は別です。INDEX の紐付けで両者を結合しますが、ロードマップに CODE を記載することはありません
「ロードマップとボードを一致させるため、ROAD ごとに Linear Project / GH milestone を作ろう」	それはこのスキルの役割ではありません。プログラムのリモート同期はオプトインであり、通常は機能の issue の本文／ラベルのみが対象です
「マイルストーンの成果 1 つ → ROAD 1 つ → 機能 1 つ」	1 つの成果には順序付けされた複数の ROAD スロットが必要になることがよくあります。それぞれが開始時に個別の機能に紐付けられます

危険信号 — 中止してください

• 作業の進み具合を記録する列、フィールド、セクションを追加しようとしている
• ファイルにすでにある番号を変更しようとしている
• 項目を延期するのではなく、その名前が記された行を削除しようとしている
• このセッション中にユーザーがそう述べていないのに、Status: Approved と記載しようとしている
• ロードマップに機能コードを書き込もうとしている
• マイルストーンの成果が、人ができることではなく、実施した作業を記述している
• ROAD のスラッグを機能コードとして扱っている、またはこのスキル内で CODE を作成しようとしている
• このスキルから、リモートのトラッカープログラムオブジェクト（milestones / initiatives / projects）を作成しようとしている

No-op

docs/roadmap/INDEX.md が存在しないときにロードマップを参照するよう求められた場合は、プロジェクトにはまだロードマップのレイヤーがなく、このスキルで作成できることを伝えてから、そこで終了します。このレイヤーは任意であり、なくても機能フローが妨げられることはありません。