product-boot

product-boot

概要

team-boot の Class Boots カタログに掲載されている 5 つの クラスブートのうちの 1 つです。team-boot はセッション開始時に、常に関連性の高いチームコンテキスト（憲章、CDR インデックス、スキルレジストリ）を注入します。このスキルは、必要に応じてプロジェクトメモリから プロダクト意思決定レイヤーである Accepted PDR インデックスを読み込み、新たなプロダクトの選択が消えてしまわないよう、/product-specify に引き継ぐための記録を提案します。このブートはファイルを書き込みません。記録スキルを提案し、ユーザーが実行します。

意思決定を読むことと記録することは、ひとつのループです。既存の PDR は作業の参考となり、作業中に行われた意思決定は、記録スキルを通じて同じ記録システムに戻されます。

使用するタイミング

該当するタスクの開始時に呼び出します。todo リストの計画前、かつ実装前に呼び出し、PDR のコンテキストを計画に反映させてください。 セッションの終了時まで先延ばしにしないでください。

次の場合に呼び出します。

• プロダクト関連の作業を開始するとき（PRD の生成、機能の定義、ロードマップの計画、GTM の意思決定）。
• セッション中に、機能の範囲、ペルソナの定義、収益化、価格設定、ターゲット市場の選択など、プロダクトに関する話題が出てきたとき。
• 既存プロダクトの意思決定の背景を確認するとき（/product-analyze、/product-roadmap は読み込まれたインデックスを活用できます）。

基本プロセス

ステップ 1：PDR インデックスの場所を特定する

現在の作業ディレクトリから確認します（親ディレクトリを上にたどらないでください）。

1. 優先：docs/adlc/memory/pdr/pdr.md（/product-implement が生成。行は | PDR で始まります）
2. フォールバック：.adlc/memory/pdr/pdr.md（レガシーレイアウト、レガシー）

どちらも存在せず、docs/adlc/memory/pdr/PDR-*.md またはレガシーの .adlc/memory/pdr/PDR-*.md ファイルが存在する場合は、各ファイルから簡潔な表を作成します（ID はファイル名から、Feature-Area／Status／Title はフロントマターまたは最初の見出しから取得）。ディレクトリが空、または存在しない場合は、0 PDRs と報告します。行を捏造してはいけません。

現在の作業ディレクトリにローカルメモリインデックスがなく、そのディレクトリがワークスペース内にある場合（祖先ディレクトリの .gitmodules マーカーで判定）、代わりにワークスペースルートの docs/adlc/memory/ インデックスを読み込みます（読み込み順は同じで、docs/adlc/memory を先に確認し、レガシーの .adlc/memory をフォールバックとして確認します）。

ステップ 1b：PDR ドラフトのインデックスを読む

.adlc/drafts/pdr/ に status: proposed がフロントマターに記載された PDR-*.md ファイルがあるか確認します。これらは明確化待ちの PDR ドラフトです。各ファイルから ID／Title／Type／Status／Date を取得します。ディレクトリが空、または存在しない場合は、0 pending drafts と報告します。

コンテキストがない場合

このセッションで team-boot によるチームコンテキストの注入がなかった場合（最初のユーザーメッセージに Team Context & Decisions セクションがない場合。プロジェクトが未設定、またはフックに失敗）には、その旨を 1 行で伝え、セクション見出しに続けて、ソース行 0 PDRs matched (no team context injected — run /team-setup) を出力し、直接読み込んだ PDR インデックスに基づいてタスクを続行します。注入がなかったことを、記録が空であることとして扱ってはいけません。復旧するには /team-diagnose を実行します。

ステップ 2：PDR コンテキストを注入する（出力契約）

タスクへの回答より前に出力します。

## PDR Context

| ID | Feature-Area | Status | Title |
|--|--|--|--|
| AI triage | triage | Accepted | AI triage scoring |

_Searched N PDRs, K matched._

## Drafts Pending Review

| ID | Title | Type | Status | Date |
|----|-------|------|--------|------|
| (from .adlc/drafts/pdr/) |

_N pending drafts — run /product-clarify to review._

• インデックスから ID／Feature-Area／Status／Title を表示します（インデックス全体には Category、Date、Owner も記載されています。タスクが該当行に一致する場合は、個別の PDR-*.md を読みます）。
• N = インデックスの総行数、K = 現在のタスクに関連する行数です。K は表示する表の行数と一致しなければなりません。 一致する行が 0 行の場合は、セクション見出しと _Searched N PDRs, K matched._ の行のみを出力し、表は出力しません。0 行の表ヘッダーはレンダリングされず、1 行の Markdown として折りたたまれます。セクションは Markdown ブロックとして出力します。見出し、表の行、件数行はそれぞれ別の行にします。

ステップ 3：プロダクト上の意思決定の記録を提案する

トリガー	アクション
機能範囲の変更、対象に含める／含めない判断	PDR → /product-specify を提案
ペルソナの定義または改訂	PDR → /product-specify を提案
収益化、価格設定、ターゲット市場の選択	PDR → /product-specify を提案
PDR クラスの意思決定がすでに台帳にある	提案が表示されたことを確認する。表示されていなければ、再度表示する

検出した意思決定ごとに、表示される応答内に 1 行を出力します。

_Suggested capture: <decision name> → run /product-specify._

自分でドラフト（またはファイル）を書いてはいけません。ユーザーが /product-specify を実行すると、.adlc/drafts/pdr/ にドラフトが作成され、その後 /product-clarify が内容を確認します。

このセッション中に検出したすべての PDR クラスの意思決定について、チームのコンテキストと意思決定に行（ID | 名前 | 種別 | 関連 | ステータス | 確認）を追加／更新します。このブートの呼び出し前に行われたものも含みます。各意思決定をタスクリストの未完了項目にも反映します（既存のドラフトについては、セッション終了時に /product-specify → 該当する確認スキルを提案します）。コードを変更するタスクの後には、未記録：保留中 0 件 · 未確認：ドラフト 0 件 になるまで「チームのコンテキストと意思決定」を確認する未完了項目を追加します（ドラフトを「未確認」から除外できるのは、確認スキルを使うか、ユーザーが名前を指定した確認スキルまたは実行スキルに明示的に引き継いだ場合のみです）。セッション終了時に、未記録の各意思決定（ID + 記録スキル）と .adlc/drafts/pdr/ にある記録済みの各 PDR ドラフト（ID + 確認スキル）を明記した確認プロンプトを提示します。ユーザーが確認を先送りする場合は、それらの行に引き継ぎ済みの印を付けます。

失敗時の処理

• インデックスも記録も見つからない場合は、セクション見出しと _検索した PDR：0 件、該当：0 件。_ のみを出力し、表は出さずにユーザーのタスクを続行します。決して作業をブロックしません。
• インデックスの行を解析できない場合は、不正な行をスキップし、スキップした件数を記載します。

注意事項

• PDR の行を捏造したり、表示された表の件数を水増ししたりしないでください。
• インデックスを挿入しても、記録の提案を無視しないでください。この組み合わせが重要です。
• 自分でドラフト（またはファイル）を書かないでください。ブートが行うのは提案のみです。書き込みは /product-specify が行います。
• 親ディレクトリをたどって .adlc/ を探さないでください。

検証

• _検索した PDR：N 件、該当：K 件。_ とともに PDR コンテキスト表を出力した（K = 表の行数）。
• 検出された PDR クラスの意思決定が、「チームのコンテキストと意思決定」の行に追加されている。
• ファイルは書き込まれておらず、検出された PDR クラスの意思決定ごとに _記録の提案：… → /product-specify を実行。_ の行がある。