tech-radar-boot

tech-radar-boot

概要

team-boot の Class Boots カタログに掲載されている 5 つの class boots の 1 つであるこのスキルは、テクノロジーの選定を扱います。現在のプロンプトに関連するテクノロジーについて Tikal の見解を提示し、イスラエルの Tech Radar に基づいてテックスタックを選べるようにします。また、選定したスタックを ADR クラスの意思決定として記録するための提案も行います。この boot は /architect-specify を提案しますが、それ自体でドラフトを作成することはありません。

レーダー検索は team-discover と同様に機能しますが、検索対象はチームの CDR インデックスではなく、ライブ取得する Tikal Tech Radar データセット（https://tikalk.com/radar.json）です。プロンプトから候補となるテクノロジーを抽出し、レーダーの blips と照合して、コンパクトな Tech Radar Context テーブル（リング、象限、Tikal の「Why?」の見解）を挿入します。また、Stop に該当するものについては、Tikal の方針に沿った代替案も提示します。

レーダーには 4 つの 象限 — DevOps、Backend、AI/ML、Web/Mobile — と、導入度を示す 4 つの リングがあります。

リング	意味	指針
Try	表面的には良さそうに見える新しいもの（評判が良い、新しいソリューション）	調査・評価します。まだ本番での使用は推奨されていません
Start	より多くの企業が使うべき優れたソリューション。ベータ版の場合は、積極的な開発と貢献が行われています	新規プロジェクトでの採用を推奨します
Keep	安定版（ベータ版ではない）で、主要な支持者から受け入れられています（大規模なコミュニティがあり、企業で利用されています）	現在および新規の作業で、デフォルトで推奨します
Stop	企業に使用をやめるよう推奨する項目です。より優れた代替案があります	使用を避けるよう警告し、Keep／Start の代替案を推奨します

各 blip の description には、HTML の <p>Why?</p> ブロックと、それに続く <p>Description</p> ブロックが含まれています。Why? のテキストには、Tikal の明確な立場とその根拠が記載されています。提示すべき意見はこれです。1 つのテクノロジーが（異なる象限で）異なるリングに複数回登場する場合があります。関連する配置をそれぞれ報告してください。

使用するタイミング

プロンプトにテクノロジーの選定または評価が含まれる場合は、次のような例を含め、このスキルをモデルから呼び出します。

• フレームワーク、ライブラリ、データベース、メッセージブローカー、クラウドツールを選定する。
• 選択肢を比較する（「X と Y のどちらか」、「Z を使うべきか」）。
• スタックの決定が暗黙に含まれるシステム、サービス、またはパイプラインを設計する。
• 既存のスタックをモダナイズまたは置き換えるためにレビューする。
• セッションの途中でテックスタックの選択が発生する（ADR 検出トリガー）。

テクノロジーの選定を伴わない純粋なビジネス／プロダクトに関する質問や、ユーザーが明示的にレーダーを無視するよう指示した場合は、呼び出さないでください。

該当するタスクの開始時に呼び出してください。todo リストの計画や実装を始める前に、レーダーのコンテキストを計画に反映できるようにします。 セッションの終了時まで先送りしてはいけません。

手動での呼び出し：

/tech-radar-boot               # inject radar context for the current prompt
/tech-radar-boot redis vs kafka

（/tech-radar-context は、このスキルの非推奨エイリアスとして引き続き使用できます。）

基本プロセス

ステップ 1：候補となるテクノロジーを抽出する

現在のプロンプト（または呼び出し元のスキルから提供された説明）から、名前が挙げられている、または明確に示唆されているテクノロジーをすべて抽出します。言語、フレームワーク、ライブラリ、データベース、ブローカー、CI/CD ツール、クラウドサービス、AI/LLM ツール、ビルドツールなどが対象です。明らかな別名は正規化します（例：「postgres」→「PostgreSQL」、「k8s」→「Kubernetes」、「GH Actions」→「GitHub Actions」）。

プロンプトで製品名を挙げずにカテゴリが示されている場合（例：「ベクトルデータベースが必要」、「Python の Web フレームワークを選んで」）は、そのカテゴリをクエリとして扱い、その分野でレーダーが推奨する選択肢を提示します。

Step 2: ライブレーダーデータセットを検索する

このスキルディレクトリを基準とする決定論的な検索ヘルパースクリプトを実行します。

POSIX（bash + jq）：

bash scripts/bash/radar-search.sh <tech1> [tech2 ...]

Windows（PowerShell）：

pwsh scripts/powershell/radar-search.ps1 <tech1> [tech2 ...]

または、JSON 出力を使用する場合は、bash では --json、PowerShell では -Json を追加します。

スクリプトは https://tikalk.com/radar.json から最新のレーダー JSON を取得し、エイリアスのマッピング（k8s → Kubernetes、postgres → PostgreSQL、gh actions → GitHub Actions など）を処理し、Tikal の <p>Why?</p> に記載された見解を抽出して、Markdown の表を自動的に作成します。

テクノロジーが異なるリングの複数の配置に登場する場合（例：Node.js が DevOps: Stop と DevOps: Keep の両方にある場合）、スクリプトはそれを検出し、矛盾する指針の注記を表示します。

ライブレーダー JSON のスキーマ（https://tikalk.com/radar.json）：

{
  "title": "Explore the Tech Radar",
  "quadrants": ["DevOps", "Backend", "AI/ML", "Web/Mobile"],
  "rings": ["Try", "Start", "Keep", "Stop"],
  "blips": [
    {
      "name": "FastAPI",
      "quadrant": "Backend",
      "ring": "Keep",
      "description": "<p>Why?</p>\n<p>...Tikal's opinion...</p>\n<p>Description</p>\n<p>...</p>",
      "isNew": false
    }
  ]
}

Step 3: ブリップを照合する

Step 1 の各候補について、name が一致するブリップを検索します（一致では大文字と小文字を区別せず、エイリアスに対応し、「Airflow 2」／「Airflow 3」のようなマイナーバージョンの接尾辞や、「Redux」→「Redux Toolkit」のような部分一致も許容します）。候補は複数の象限にある複数のブリップに一致する場合があります。その場合はすべて残してください。

カテゴリを検索する場合（Step 1）、その分野でレーダーが最も強く推奨するものを選択します。一致する象限の Keep／Start のブリップを優先し、避けるべきものとして Stop のブリップを記載します。

Step 4: Tikal の見解を抽出する

一致したブリップごとに、description HTML を解析します。

• <p>Why?</p> ブロック内のテキスト（次の <p>Description</p> まで）がTikal の見解／根拠であり、主な判断材料です。
• <p>Description</p> ブロックは中立的な背景情報です。役立つ場合に限り使用します。

HTML タグを取り除いてプレーンテキストにし、「Why?」の内容をコンテキスト表向けに 1～2 文にまとめます（リングが Stop の場合や、ユーザーがそのテクノロジーを直接検討している場合は、より詳しく引用します）。

Step 5: Stop の代替案を推奨する

候補が Stop のブリップに一致する場合（またはレーダーが明らかに非推奨としているレガシーテクノロジーである場合）、同じ象限にある Keep または Start から、Tikal の指針に沿った代替案を選択します。「Why?」のテキストを参考にしてください。データセットがサポートする一般的な例：

• Airflow 2 → Airflow 3 / Dagster
• Create React App → Vite / Next.js
• Jenkins → GitHub Actions / GitLab CI / Tekton
• requirements.txt / Poetry → uv
• Moment.js / Luxon → day.js / date-fns
• Redux / Redux Toolkit → Zustand / TanStack Query
• Ant Design / Styled Components → Tailwind CSS / shadcn/ui / Radix UI

読み込んだデータセットが裏付けていない置き換え案をハードコードしないでください。レーダーのその象限にある実際の Keep／Start のブリップから代替案を導き出してください。

コンテキストがない場合

このセッションで team-boot がチームコンテキストを注入していない場合（最初のユーザーメッセージに Team Context & Decisions セクションがない場合。プロジェクトが未設定、またはフックに失敗した場合）、その旨を 1 行で伝え、セクション見出しに続けて 0 radar technologies matched (no team context injected — run /team-setup) というソース行を出力し、ライブレーダーの検索を続行します。注入がないことを、空のレコードセットとして扱ってはいけません。復旧するには /team-diagnose を実行します。

ステップ 6：Tech Radar のコンテキストを挿入する（出力契約）

スクリプトの標準出力はツールチャンネルに送られ、ユーザーには表示されません。必ず、タスクへの回答の前に、Tikal Tech Radar Context セクション全体をユーザーに見える応答で再出力してください（一致件数が 0 件の場合は、見出しと _Source: 行のみ）。見出し、表の行、ガイダンスの箇条書き、ソース行をそれぞれ独立した行にして、Markdown ブロックとして出力してください。セクションを 1 行にまとめてはいけません。

## Tikal Tech Radar Context

| Technology | Quadrant | Ring | Tikal's Opinion (Why?) |
|------------|----------|------|------------------------|
| FastAPI | Backend | Keep | Better alternative to Flask; async, fast, big and growing community. |
| Jenkins | Backend | Stop | Plugin hell + XML config; legacy vs GitHub Actions / GitLab CI / Tekton. |

**Radar guidance**
- ✅ Keep/Start: FastAPI — safe to adopt.
- ⚠️ Stop: Jenkins → consider GitHub Actions, GitLab CI, or Tekton (see Why? above).

_Source: Tikal Israeli Tech Radar (live: https://tikalk.com/radar.json) · N technologies matched._

_Searched N blips, K matched._

• 一致した blip ごとに 1 行を含めます（該当する場合、クアドラントをまたぐ重複も含めてください）。
• 簡潔な Radar guidance リストをまとめます：採用しても安全なものと、代替案とともに避けるべきもの。
• データがライブのレーダーソースに由来することと、一致したテクノロジーの数を記した _Source_ 行を追加します。
• N = 読み込んだデータセット内でスキャンした blip 数、K = 表に表示する行数です。K は表示された表の行数と一致しなければなりません。 一致する行が 0 件の場合は、セクションの見出しと _Source: 行のみを出力し、表は出力しません。0 行の表ヘッダーはレンダリングされない 1 行の Markdown に折りたたまれるため、決して出力しないでください。

候補テクノロジーがどの blip にも一致しない場合は、その旨を見出しと _Source: 行で明記してください（例：_Source: … · 0 technologies matched._）。表は出力せず、レーダー上の位置を捏造してはいけません。

ステップ 7：選定を記録する（意思決定の対応付け）

テクノロジーの選定は ADR クラスの意思決定です。現在の作業ディレクトリにローカルメモリインデックスがなく、そのディレクトリがワークスペース内にある場合（祖先に .gitmodules マーカーがあることで検出）、ワークスペースルートの docs/adlc/memory/ インデックスを読み込んでください（デュアルリードの順序を適用します：先に docs/adlc/memory、次に従来の .adlc/memory をフォールバックとして読み込みます）。

トリガー	アクション
技術スタックを選定した（「X を使います」）	ADR → レーダーの該当行を引用して /architect-specify を提案する
「X と Y」の比較が決着した	ADR → 比較の結果を添えて /architect-specify を提案する
Stop リングのテクノロジーをあえて採用した	ADR → レーダーのガイダンスを覆した理由を記録する /architect-specify を提案する

選定について Team Context & Decisions（ID | Name | Type | Rel | Status | Clarify）に行を追加または更新し、タスクリストの TODO としても記録してください（ドラフトが存在する場合は、セッション終了時に /architect-specify → 対応する clarify スキルを提案します）。コードを変更するタスクの後には、Unrecorded: 0 pending · Unclarified: 0 drafts になるまで Team Context & Decisions を確認する末尾の TODO を追加してください（ドラフトが Unclarified から外れるのは、その clarify スキルを実行した場合、またはユーザーが名前を指定した clarify スキルや execute スキルへ明示的に引き継いだ場合のみです）。このセッションですでに architect-boot が呼び出されている場合は、レーダーの根拠を記録台帳の行に追記してください。セッション終了時には、未記録のテクノロジー選定の決定（ID + 記録スキル）と、記録済みドラフト（ID + clarify スキル）をそれぞれ明記した clarify プロンプトを提示してください。ユーザーが clarify を延期した場合は、それらの行に引き継ぎ済みと記録してください。

エラー処理

• ライブ取得に失敗した場合（ネットワークエラー、タイムアウト、無効な JSON）、スクリプトは明確なエラーメッセージを標準エラー出力に出して、ゼロ以外の終了コードで終了します。スキルは、Tech Radar のソースに到達できなかったことを示す空のコンテキスト表を出力し、レーダーのコンテキストなしでユーザーのタスクを続行してください。古いキャッシュや同梱データを最新の情報であるかのように代用してはいけません。
• 一致がない場合は、見出しと 0 technologies matched のソース行のみを出力し、表は出力しません。

注意すべき兆候

• 読み込まれたデータセットに含まれていないテクノロジーについて、リング、象限、「Why?」の意見を捏造すること。代わりに 0 matches と報告してください。
• ライブ取得に失敗した際、キャッシュ済み、同梱済み、または古いレーダーデータへ黙って差し替えること。レーダーのソースにアクセスできない場合は必ず報告し、古いデータを最新のものとして提示しないでください。
• 読み込まれたレーダーに根拠のない、Stop から代替候補への置き換えをハードコードすること。
• 中立的な <p>Description</p> のテキストを Tikal の意見として報告すること。意見は <p>Why?</p> ブロックにあります。
• 重複するブリップを無視すること。同じテクノロジーが、異なるリングで別々の象限に配置されている場合があります。該当する配置をそれぞれ示してください。
• スキルの読み込みを作業そのものとして扱うこと。Core Process を実際に実行し、Tech Radar Context テーブルを生成する必要があります。
• スクリプトでレーダーの調査結果を読み取り、コンテキストのセクションを再出力せずに回答すること（スクリプトの標準出力はツールチャンネルに出力され、ユーザーには見えません）。ユーザーに見える応答には、必ず調査結果を含めてください。
• コンテキストのセクションを1行にまとめること。見出し、テーブルの各行、ガイダンス、ソース行は、それぞれ独立したMarkdownの行にしてください。
• レーダーのコンテキストを挿入しながら、記録の提案を省略すること。ADRに反映されなかったテクノロジーの選定は、消えてしまった決定です。
• 自分で草案（またはファイル）を書くこと。このブートは提案のみを行います。書き込むのは /architect-specify です。

検証

• プロンプトから候補となるテクノロジーを抽出した（または製品名が指定されていない場合はカテゴリに関するクエリを作成した）。
• レーダーデータセットを https://tikalk.com/radar.json からライブ取得した。
• <p>Why?</p> ブロックを出典とする意見を含む、「Technology / Quadrant / Ring / Tikal's Opinion (Why?)」列の Tikal Tech Radar Context テーブルを生成した。
• Stop リングに一致する項目には、データセットから導き出した、同じ象限にある Tikal の方針に沿った Keep／Start の代替候補を含めた。
• _Source_ 行でライブレーダーのソースと一致件数を報告する。一致項目がない場合は、データを捏造するのではなく、テーブルを出さずに見出しとソース行のみを表示する。取得に失敗した場合はエラーを報告し、レーダーのコンテキストなしでスキルを続行する。
• 今回のセッションで選定したテクノロジーは、記録スキルとして /architect-specify を指定して Team Context & Decisions に記載し、それぞれに _Suggested capture: … → run /architect-specify._ の行を含める。このスキルではファイルを書き込みません。

設定

• データソース：https://tikalk.com/radar.json（呼び出しのたびにライブ取得。スナップショットの同梱やキャッシュはありません）。
• 取得タイムアウト：10 seconds。取得に失敗した場合、処理をブロックしたり古いデータに差し替えたりせず、レーダーのコンテキストなしでスキルを続行します。
• 取得時のセキュリティ：ヘルパーは HTTPS（リダイレクトを含む）に通信を固定し、ネットワークエラー、タイムアウト、無効な JSON が発生した場合はフェイルクローズします。レーダーの内容は表示用データとして扱い、実行することはありません。取得に失敗した場合はその旨を報告し、レーダーのコンテキストなしで続行します。