architect-boot

architect-boot

概要

team-boot の Class Boots カタログに掲載されている 5 つの クラスブートの 1 つです。team-boot はセッション開始時に、常に関連するチームコンテキスト（constitution、CDR インデックス、スキルレジストリ）を注入します。このスキルは、プロジェクトメモリの Accepted ADR インデックスというアーキテクチャ決定レイヤーを必要に応じて読み込み、新たなアーキテクチャ上の選択が失われないよう、/architect-specify に記録することを提案します。このブートはファイルを書き込みません。記録用スキルを提案し、ユーザーが実行します。

決定を読み取ることと記録することは、1 つのループです。既存の ADR は作業の参考になり、作業中に行われた決定は、記録用スキルを通じて同じ記録システムに反映されます。

使用するタイミング

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

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

• アーキテクチャ作業（システム設計、AD.md の生成、サブシステム間のリファクタリング、依存関係の変更）を開始するとき。
• セッションの途中で、技術スタックの選択、パターンの選定、「Y ではなく X を選んだ」といった判断が生じ、アーキテクチャの話題に移ったとき。
• アーキテクチャをレビューまたは検証する際に、判断に至った背景が必要なとき。

技術選定では、tech-radar-boot も呼び出してください。レーダーのコンテキストを ADR に反映します。

基本プロセス

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

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

1. 優先：docs/adlc/memory/adr/adr.md（/architect-implement によって生成。行は | ADR で始まります）
2. フォールバック：.adlc/memory/adr/adr.md（従来のレイアウト、従来形式）

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

現在の作業ディレクトリにローカルのメモリインデックスがなく、そのディレクトリがワークスペース内にある場合（祖先ディレクトリにある .gitmodules マーカーで判定）、代わりにワークスペースルートの docs/adlc/memory/ インデックスを読み取ります（読み取り順序は両方を確認し、まず docs/adlc/memory、次に従来形式の .adlc/memory をフォールバックとして使用します）。

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

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

コンテキストがない場合

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

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

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

## ADR Context

| ID | Sub-System | Decision | Status |
|--|--|--|--|
| ADR-001 | lanes | Workflow lanes over flat queue | Accepted |

_Searched N ADRs, K matched._

## Drafts Pending Review

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

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

• インデックスの ID／Sub-System／Decision／Status を表示します（完全なインデックスには Date、Decision Makers、File も含まれます。タスクが行に該当する場合は、個別の ADR-*.md を読みます）。
• N はインデックスの行数の合計、K は現在のタスクに関連する行数です。K は表示する表の行数と一致しなければなりません。 該当する行が 0 件の場合は、セクション見出しと _Searched N ADRs, K matched._ の行のみを出力し、表は出力しません。0 行の表ヘッダーはレンダリングされず 1 行に折りたたまれるため、出力してはいけません。セクションは Markdown ブロックとして出力します。見出し、表の各行、件数行をそれぞれ別の行に記述します。

ステップ 3：アーキテクチャ上の決定の記録を提案する

トリガー	アクション
技術スタックの選択、「Y ではなく X を選んだ」	ADR → /architect-specify を提案する（最初に tech-radar-boot のコンテキストを取得）
パターンの選択、構造的なリファクタリング	ADR → /architect-specify を提案する
ADR クラスの決定がすでに台帳にある	提案が表示されたことを確認し、表示されていなければ再度表示する

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

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

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

このセッションで検出した ADR クラスの決定すべてについて、チームコンテキストと決定事項に行（ID | 名前 | 種類 | 関連性 | ステータス | 確認）を追加または更新します。今回の起動前に検出されたものも含めます。各決定をタスクリストの todo にも反映します（ドラフトが存在する場合は、セッション終了時に /architect-specify → 対応する確認スキルを提案します）。コードを変更するタスクの後には、未記録：保留中 0 件 · 未確認：ドラフト 0 件 になるまでチームコンテキストと決定事項を確認するための末尾の todo を追加します（確認スキルの実行、または名前を指定した確認スキルもしくは実行スキルへの明示的なユーザー引き継ぎがない限り、ドラフトは「未確認」から外れません）。セッション終了時には、未記録の決定（ID + 記録スキル）と .adlc/drafts/adr/ にある記録済みの ADR ドラフト（ID + 確認スキル）をそれぞれ明記した確認プロンプトを提示します。ユーザーが確認を延期した場合は、該当する行に引き継ぎ済みと記録します。

失敗時の処理

• インデックスとレコードの両方が見つからない場合は、見出しと _ADR を 0 件検索し、0 件が一致しました。_ のみを出力し、テーブルは出力せず、ユーザーのタスクを続行します。決してブロックしてはいけません。
• インデックスの行を解析できない場合は、不正な行をスキップし、スキップした件数を記載します。

注意事項

• ADR の行を捏造したり、表示されているテーブルの K 件を水増ししたりしないでください。
• インデックスを追加しても記録の提案を無視しないでください。この組み合わせが重要です。
• ドラフト（またはいかなるファイル）も自分で作成しないでください。起動時に行うのは提案のみであり、作成するのは /architect-specify です。
• 親ディレクトリをたどって .adlc/ を探してはいけません。
• レーダーが利用可能な場合、技術選定に関する ADR はレーダーのコンテキストなしで記録してはいけません。

確認

• _検索した ADR は N 件、一致したものは K 件です。_ を含む ADR コンテキストテーブルが出力されている（K = テーブルの行数）。
• 検出した ADR クラスの決定が、チームコンテキストと決定事項の行に追加されている。
• ファイルが作成されておらず、検出した ADR クラスの決定ごとに _記録を提案：… → /architect-specify を実行。_ の行がある。
• 技術選定に関する決定が tech-radar-boot → /architect-specify を経由している。