team-boot

team-boot

概要

チームの AI 指令コンテキストを組み立て、セッション開始時にシステムプロンプトへ挿入します。 CDR インデックスには、利用可能なすべてのチームコンテキストモジュールが説明とともに一覧表示されます。タスクに該当するモジュールがあれば、必要に応じてファイル全体を読み込みます。

team-boot が挿入するのは、常に関連するレイヤーのみです。これには、コンスティテューションのタイトル、簡潔な CDR インデックス、Class Boots カタログ、スキルレジストリ、MCP サーバーが含まれます。4 つの記録クラス（ADR/PDR/ChDR/CDR の詳細）と技術選定は、以下の Class Boots を通じて必要に応じて読み込まれます。それぞれのインデックス挿入には、意思決定の記録が伴います。

検出はネイティブです。挿入された CDR インデックスは、プロンプトごとに LLM が現在のタスクに照らして独自に照合するため、スキルの呼び出しは必要ありません。 /team-discover は、複雑な機能の開始時などに明示的かつ構造化された再検出を行うための、別個のユーザーが呼び出すコマンドであり、ブートストラップのループには含まれません。

最短手順： チーム AI 指令コンテキスト（コンスティテューション、CDR インデックス、Class Boots カタログ）がすでにシステムプロンプトまたは最初のユーザーメッセージにある場合、イベントフックはすでに実行されています。何もする必要はありません。

Class Boots

Boot	挿入内容	呼び出すタイミング	記録方法
architect-boot	ADR インデックス（docs/adlc/memory/adr/ + レガシーな .adlc/memory/adr/）	アーキテクチャ関連の作業、技術スタックやパターンの選択	.adlc/drafts/adr/ へ直接書き込み
product-boot	PDR インデックス（docs/adlc/memory/pdr/ + レガシーな .adlc/memory/pdr/）	プロダクトや機能のスコープ、ペルソナ、収益化	.adlc/drafts/pdr/ へ直接書き込み
change-boot	ChDR インデックス（docs/adlc/memory/chdr.md + レガシーな .adlc/memory/chdr.md）	変更履歴の根拠、リバート、Issue に関連付けられたコミット	.adlc/drafts/chdr/ へ直接書き込み
team-levelup	CDR モジュールの本文（team-ai-directives）	セッション終了時、CDR の説明が該当するとき、再利用可能なチームパターン	adlc ブランチの drafts/cdr/ へ直接書き込み
tech-radar-boot	Tikal Tech Radar のコンテキスト	技術の選定や評価	レーダーのコンテキスト + .adlc/drafts/adr/ へ直接書き込み

タスクや意思決定が該当する行に一致する場合は、対応する Class Boot を呼び出してください。一致するタスクの開始時、ToDo リストを計画する前、実装を始める前に呼び出し、クラスのコンテキストを計画に反映してください。 セッション終了時まで先延ばしにしないでください。現在の作業ディレクトリにローカルのメモリインデックスがなく、そのディレクトリがワークスペース内にある場合（祖先ディレクトリの .gitmodules マーカーで検出）、ブートはワークスペースルートの docs/adlc/memory/ インデックスを読み込みます。各ブートは、クラスコンテキストのセクションと、検索した行（_Searched N <class> records, K matched._）を出力し、そのクラスに関する検出および記録のガイダンス全体を含みます。一致する行が 0 件の場合、ブートが出力するのはセクションの見出しと検索した行だけで、表は出力されません。

イベントフック（自動）

.events.json で宣言され、adlc-cli によって接続される session_start および session_compact イベントフックは、scripts/bash/boot.sh（POSIX）または scripts/powershell/boot.ps1（Windows）を実行します。このスクリプトは .adlc/init-options.json を読み込み、コンテキストブロック（コンスティテューション、CDR.md インデックステーブル、.skills.json）を組み立てて stdout に出力します。プラグインは結果をキャッシュし、すべてのステップでシステムプロンプトに挿入します（冪等です。同じキャッシュ済みコンテンツが使われ、蓄積されません）。session_compact の宣言により、コンパクション後の再挿入も仕様の一部となります。ハーネスが履歴を要約すると、生成されたプラグインがハンドラーを再実行し、重複排除ガードによって二重挿入を防ぎます。アダプターがまだ session_compact に対応していないエージェントでは、この処理はスキップされます。このマッピングは adlc-cli が管理します。

手動フォールバック（イベントに対応していないエージェント向け）

1. 現在の作業ディレクトリから .adlc/init-options.json を読み込みます。 親ディレクトリをさかのぼってはいけません。glob、find、または ファイル検索ツールを使って見つけてはいけません。
2. 未設定の場合（ファイルがない、null、またはパスが存在しない）：team-setup スキルを呼び出します。
3. このセッションに factory-setup スキルがインストールされていて、リポジトリのルートに .adlc/issues-provider.yml が見つからない場合：今すぐ /factory-setup を実行するかユーザーに尋ねます（プロバイダーの選択は質問に基づいて行われ、team-setup のモードと同じです）。ユーザーが断った場合、このセッションではスキップします。永続的なオプトアウトマーカーは意図的に用意されていません。
4. 設定済みの場合：コンテキストを組み立て、上記の Class Boots カタログに従います。詳しい手順は references/manual-fallback.md を参照してください。

意思決定の記録

意思決定が生じたら検出し、セッション中に .adlc/drafts/{type}/ へ軽量なドラフトを直接書き込みます。specify スキルの呼び出しは不要です。 唯一のゲートは、セッション終了時の確認です。

検出トリガー

パターン	種類	ドラフトの保存先	確認方法
技術スタックの選択、パターンの選定、「Y より X を選んだ」	意思決定	drafts/adr/	/architect-clarify
機能の範囲、ペルソナ、収益化	プロダクト	drafts/pdr/	/product-clarify
再利用可能なチームルール、「常に X を実行する」	パターン	drafts/cdr/	/team-levelup
リバート／ホットフィックスの根拠、課題に関連付けられたコミット、人が作成したメッセージ付きの git コマンド、作成者が記入した PR のタイトル／本文、CHANGELOG の編集	インシデント	drafts/chdr/	/change-clarify
採用した回避策、「Y のため、当面は X」	回避策	drafts/chdr/	/change-clarify
運用上の制約、「Z の場合に限り動作する」	制約	drafts/adr/	/architect-clarify
変更の中止、「X を簡素化しようとしたが Y が妨げになった」	中止	drafts/chdr/	/change-clarify
発見された評価基準	評価	drafts/evals/	/evals-clarify

比例性のゲートと信頼モデルについては references/decision-capture.md を参照してください。 意思決定がどれほど自明でないかに応じてドキュメントの詳しさを調整し、プロジェクトの知識をまとめてください。指示をそのまま書き起こしてはいけません。

チームのコンテキストと意思決定（毎回の応答）

すべての応答には、コンテキストを示す行と、対応が必要な意思決定の行をまとめた、6 列の表を 1 つだけ含めます。

## Team Context & Decisions

| ID | Name | Type | Rel | Status | Clarify |
|--|--|--|--|--|--|
| CDR-YYYY-NNN | <name> | <type> | <relevance> | in use | — |
| — | <decision> | <ADR/PDR/CDR/ChDR/Eval> | <trigger> | pending | <clarify skill> |

_Scope: N CDRs · A ADRs · P PDRs · C ChDRs · E evals · M skills — J rows shown · Unrecorded: N pending · Unclarified: M captured drafts._

Status が in use、Clarify が — の行は、コンテキストを示します（承認済みの記録のみ）。 Status が pending／captured／clarified／handed off で、Clarify にスキルが指定された行は、対応が必要な意思決定を示します。Status が in use のドラフト行は使用できません。ドラフトは、保留中の意思決定の行にのみ表示します。J = 表示されている全行。

• 検出：セッション中の意思決定を、上記のトリガーに照らし合わせます。
• 分類：記録の種類（ADR/PDR/CDR/ChDR）を割り当てます。
• 書き込み：ファミリー用のドラフトテンプレートを使い、.adlc/drafts/{type}/ に軽量なドラフトを直接書き込みます。
• 追跡：表の行を更新します（ID = ドラフト ID または —、Status = pending/captured/clarified/handed off、Clarify = 対応するスキル）。
• 提示：検出した意思決定ごとに、タスクリストの todo として提示します（ドラフト → セッション終了時に対応する clarify スキル）。コードを変更するタスクの後には、Team Context & Decisions の確認用 todo を末尾に追加し、Unrecorded: 0 pending · Unclarified: 0 drafts になるまで確認します（ドラフトが Unclarified から除かれるのは、その clarify スキルを実行した場合、またはユーザーが名前を指定した clarify スキルか execute スキルに明示的に引き継いだ場合のみです）。
• セッション終了時：終了前に、記録した各ドラフトの ID と clarify スキル名を示して、確認を促します。ユーザーが確認を延期した場合、該当する行を handed off にします。

Specify スキル（/architect-specify、/product-specify など）は、トレードオフ分析をガイド付きで行う対話的な詳細検討に引き続き利用できますが、日常的な記録には必要ありません。

失敗時の処理

• インデックスがなく、記録もない場合は、セクション見出しと _Scope: 0 CDRs · 0 ADRs · 0 PDRs · 0 ChDRs · 0 evals · 0 skills — 0 rows shown._ のみを出力し、表は出力せず、ユーザーのタスクを続行します。決して処理を止めてはいけません。
• インデックスの行を解析できない場合は、不正な行をスキップし、スキップした件数を記載します。

検証

• タスク一覧に、_Scope: N CDRs · A ADRs · P PDRs · C ChDRs · E evals · M skills — J rows shown · Unrecorded: N pending · Unclarified: M captured drafts._ が出力されていること （J = 表示されているすべての行。Status=in use の行は承認済みの記録のみであり、決定事項の行には明確化スキルが付与されています）。
• タスク開始時にクラスが起動していること（ToDo の計画前）。起動を先延ばしにしていないこと。 CWD にローカルメモリーがない場合は、ワークスペースルートへのフォールバックが適用されていること。
• 検出された決定事項が、対応する明確化スキルとともに表の行として追加されていること。
• 検出された決定事項がタスクリストの ToDo にも反映されていること。コードを変更するタスクの後に台帳確認の ToDo が追加されていること。確認は、セッション終了時の明確化プロンプトが提示されたうえで、Unrecorded: 0 pending · Unclarified: 0 drafts の状態になった場合にのみ完了していること。

未設定のプロジェクト

team-setup を実行して、このプロジェクトのチーム AI 指示を設定します。

ファクトリースキルがインストールされているものの、プロバイダー設定が解決されない場合は、factory-setup を実行するかどうか確認してください。