change-boot

change-boot

概要

team-boot の Class Boots カタログに掲載されている 5 つのクラスブートのうちの 1 つです。team-boot は、常に関連するチームコンテキスト（constitution、CDR インデックス、スキルレジストリ）をセッション開始時に注入します。このスキルは、必要に応じて変更履歴レイヤー（git 履歴から抽出された公開済み ChDR インデックス）を読み込み、変更理由の記録を提案します。これにより、変更理由をコミットメッセージだけに残すのではなく、履歴から見つかった内容には /change-init、このセッションで行った決定には /change-specify を使って回収できます。このブートがファイルを書き込むことはありません。記録スキルを提案し、実行するのはユーザーです。

過去の理由を読み、新たな理由を記録することは、ひとつのループです。公開済み ChDR はコードが現在の形になっている理由を説明し、作業中に見つかった変更理由は、記録スキルを通じて同じ記録システムに反映されます。

使用するタイミング

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

次の場合に呼び出してください。

• 不慣れなコードをリファクタリングまたは変更する場合 — 変更する前に、現在の形になっている理由を説明する ChDR がないか確認します。
• リバート、ホットフィックス、修正の連鎖を分析する場合（「なぜリバートされたのか？」）。
• セッション中に人が作成したメッセージを伴う git の変更を作成した場合（作成者が記述したメッセージを伴う commit／merge／revert／rebase／cherry-pick／tag、作成者が記述した PR のタイトルまたは本文、CHANGELOG の編集）— セッション終了時に、理由が自明でないため ChDR に記録する価値があるかを評価します。生成されたメッセージや空のメッセージを伴う定型的な操作は ChDR の対象ではありません（妥当性のゲート）。
• セッション中に変更理由が生じた場合 — リバート／ホットフィックスの説明、またはイシュートラッカーへのリンクを含むコミット（/change-init の抽出シグナル）。

基本プロセス

ステップ 1：ChDR インデックスを特定する

現在の作業ディレクトリから確認します（親ディレクトリをさかのぼって検索しないでください）。

• 優先：docs/adlc/memory/chdr/chdr.md（/change-publish によって生成。adr/adr.md や pdr/pdr.md と同様、クラスディレクトリ内にあり、行は | ChDR で始まります）
• フォールバック：docs/adlc/memory/chdr.md（旧形式のルートレベル配置）
• フォールバック：.adlc/memory/chdr.md（レガシーレイアウト、レガシー）

インデックスが見つからなくても、docs/adlc/memory/chdr/ChDR-*.md またはレガシーの .adlc/memory/chdr/ChDR-*.md ファイルが存在する場合は、各ファイルから簡潔な表を作成します（ID はファイル名から、Title／Status はフロントマターまたは最初の見出しから取得）。何も存在しない場合は 0 ChDRs と報告し、行を捏造しないでください。

現在の作業ディレクトリにローカルのメモリーインデックスがなく、そのディレクトリがワークスペース内にある場合（上位ディレクトリの .gitmodules マーカーで判定）、ワークスペースルートの docs/adlc/memory/ インデックスを読み取ります（デュアル読み込みの順序を適用し、まず docs/adlc/memory、次にレガシーの .adlc/memory をフォールバックとして確認します）。

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

.adlc/drafts/chdr/ にある ChDR-*.md ファイルのうち、フロントマターの status: proposed または status: discovered に該当するものを確認します。これらは明確化待ちの ChDR ドラフトです。フロントマターの proposed／discovered は台帳の Status captured に対応し、どちらも Unclarified の件数に含めます。各ファイルから ID／Title／Type／Status／Date を収集します。 ディレクトリが空または存在しない場合は、0 pending drafts と報告します。

コンテキストが存在しない場合

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

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

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

## ChDR Context

| ID | Title | Status | Date |
|--|--|--|--|
| ChDR-001 | Why payments retries are capped at 3 | stable | 2026-08-16 |

_Searched N ChDRs, K matched._

## Drafts Pending Review

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

_Unclarified: N ChDR drafts — run /change-clarify to review._

• インデックスから ID／タイトル／ステータス／日付を表示します（完全なインデックスには Issue、Commit、Note も含まれます。タスクが行に該当する場合は、個別の ChDR-*.md を読みます）。
• N = インデックスの行数、K = 現在のタスクに関連する行数です。**K は表示するテーブルの行数と一致しなければなりません。**該当する行が 0 行の場合は、セクション見出しと _Searched N ChDRs, K matched._ の行だけを出力し、テーブルは出力しません。0 行のテーブルヘッダーは、レンダリングされない 1 行の Markdown に折りたたまれるため、出力してはいけません。セクションは Markdown ブロックとして出力します。見出し、テーブルの行、件数の行はそれぞれ別の行にします。

ステップ 3：変更理由の記録を提案する

トリガー	アクション
理由を伴う revert または hotfix を実施／分析した	ChDR → /change-specify を提案する
Issue トラッカーへのリンクを含むコミットを作成した	ChDR → マージ後に /change-specify を提案する
セッション中に人が作成したメッセージ付きで Git コマンドを作成した場合、人が作成した PR のタイトル／本文、または CHANGELOG の編集	セッション終了時に評価する：自明でない理由がある場合は /change-specify を提案し、定型的な作業は比例性の基準に基づき省略する
履歴から修正チェーンを発見した	ChDR → /change-init（履歴のマイニング）を提案する
ChDR クラスの決定がすでに台帳にある	提案が提示されたことを確認し、提示されていなければ再提示する

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

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

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

このセッションで検出したすべての ChDR クラスの決定について（このブートの実行前に検出されたものも含めて）、Team Context & Decisions（ID | Name | Type | Rel | Status | Clarify）の行を追加／更新します。各決定はタスクリストの todo にも反映します（下書きが存在する場合、セッション終了時に /change-specify → 対応する clarify スキルを提案します）。コードを変更するタスクの後には、Unrecorded: 0 pending · Unclarified: 0 drafts になるまで Team Context & Decisions を確認するための todo を末尾に追加します（下書きが Unclarified から外れるのは、clarify スキルの実行、または名前を指定した clarify もしくは execute スキルへの明示的なユーザー引き継ぎがあった場合に限ります）。セッション終了時には、未記録の各決定（ID + 記録スキル）と .adlc/drafts/chdr/ にある各 ChDR 下書き（ID + clarify スキル）を明記した clarify プロンプトを提示します。マージ後の Issue リンク付きコミットも対象に含めます。ユーザーが clarify を延期した場合は、該当する行に引き継ぎ済みと記録します。

エラー処理

• インデックスと記録がどちらもない場合は、セクション見出しと _Searched 0 ChDRs, 0 matched._ の行だけを出力し、テーブルは出力せず、ユーザーのタスクを続行します。処理を止めてはいけません。
• 解析できないインデックスの行はスキップし、スキップした件数を記載します。

注意事項

• ChDR の行を捏造したり、表示するテーブルの行数を超えて K を増やしたりしないでください。
• インデックスを注入しながら、記録の提案を無視しないでください。この 2 つを組み合わせることが重要です。
• 下書き（またはファイル）を自分で作成しないでください。ブートが行うのは提案のみで、下書きは /change-specify が作成します。
• 親ディレクトリをたどって .adlc/ を探してはいけません。
• SHA／URL の出典情報なしに理由をマイニングしてはいけません。/change-clarify は出典情報のない Decision の主張を却下します。

検証

• ChDR Context テーブルを _Searched N ChDRs, K matched._ とともに出力した（K = テーブルの行数）。
• 検出した ChDR クラスの決定を Team Context & Decisions の行に追加した。
• ファイルは書き込まず、検出した各 ChDR クラスの決定に _Suggested capture: … → run /change-specify._ の行がある（履歴マイニングのシグナルでは /change-init を指定する）。