/tech-radar-boot

name: tech-radar-boot
description: Use when choosing or evaluating a technology (framework, database, library, cloud tool) — injects Tikal Israeli Tech Radar context (adoption ring, quadrant, opinion, Keep/Start alternatives for Stop items) and pairs the selection with ADR capture via /architect-specify; invoked from team-boot's Class Boots catalog (formerly tech-radar-context).

tech-radar-boot

Overview

One of the five **class boots** surfaced by `team-boot`'s Class Boots catalog, this skill handles **technology selection**. It surfaces **Tikal's opinion** on the technologies relevant to the current prompt so a tech stack choice is informed by the Israeli Tech Radar, and it pairs the selection with decision capture: the chosen stack is an ADR-class decision that should be recorded via `/architect-specify`.

The radar lookup works like `team-discover`, but its search surface is the Tikal Tech Radar dataset (fetched live from `https://tikalk.com/radar.json`) instead of the team CDR index: it extracts candidate technologies from the prompt, matches them against radar **blips**, and injects a compact **Tech Radar Context** table (ring, quadrant, Tikal's "Why?" opinion) plus Tikal-aligned alternatives for anything on `Stop`.

The radar has four **quadrants** — `DevOps`, `Backend`, `AI/ML`, `Web/Mobile` — and four adoption **rings**:

| Ring | Meaning | Guidance | |------|---------|----------| | `Try` | New stuff that on the surface seems good (good press, new solution) | Explore / evaluate; not yet endorsed for production use | | `Start` | A good solution more companies should use; if in beta, active progress and contribution | Recommend adopting on new projects | | `Keep` | Stable release (non-beta) with major supporter acceptance (large community, used by corporates) | Recommend by default for current & new work | | `Stop` | Items we recommend companies stop using — better alternatives exist | Warn against; recommend a `Keep`/`Start` alternative |

Each blip's `description` embeds an HTML `<p>Why?</p>` block followed by a `<p>Description</p>` block. The **Why?** text carries Tikal's explicit stance and rationale — that is the opinion to surface. A technology may appear more than once (different quadrants) with different rings; report each relevant placement.

When to Use

Model-invoke this skill whenever the prompt involves **choosing or evaluating technology**, for example:

• Selecting a framework, library, database, message broker, or cloud tool.
• Comparing options ("X vs Y", "should we use Z").
• Designing a system, service, or pipeline where stack decisions are implied.
• Reviewing an existing stack for modernization or replacement.
• A tech stack choice emerges mid-session (the ADR detection trigger).

Do **not** invoke it for pure business/product questions with no technology selection, or when the user explicitly says to ignore the radar.

Invoke at the START of a matching task — before planning the todo list and before implementation — so the radar context informs planning. Never defer to session end.

Manual invocation:

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

(`/tech-radar-context` still works as a deprecated alias for this skill.)

Core Process

Step 1: Extract Candidate Technologies

From the current prompt (or the description provided by an invoking skill), extract every named or clearly implied technology: languages, frameworks, libraries, databases, brokers, CI/CD tools, cloud services, AI/LLM tooling, build tools, etc. Normalize obvious aliases (e.g. "postgres" → "PostgreSQL", "k8s" → "Kubernetes", "GH Actions" → "GitHub Actions").

If the prompt implies a category without naming a product (e.g. "we need a vector database", "pick a Python web framework"), treat the category as a query and surface the radar's recommended options in that space.

Step 2: Query the Live Radar Dataset

Execute the deterministic search helper script (relative to this skill directory):

POSIX (bash + jq):

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

Windows (PowerShell):

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

Or for JSON output (add `--json` for bash, `-Json` for PowerShell).

The script fetches the radar JSON fresh from `https://tikalk.com/radar.json`, handles alias mapping (`k8s` → `Kubernetes`, `postgres` → `PostgreSQL`, `gh actions` → `GitHub Actions`, etc.), extracts Tikal's `<p>Why?</p>` opinion, and formats the markdown table automatically.

If a technology appears in multiple placements with conflicting rings (e.g., `Node.js` is both `DevOps: Stop` and `DevOps: Keep`), the script detects and flags it with a **Conflicting Guidance** note.

**Schema of the live radar 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: Match Blips

For each candidate from Step 1, find matching blips by `name` (case-insensitive, alias-aware, allowing minor version suffixes like "Airflow 2" / "Airflow 3" and partial matches like "Redux" → "Redux Toolkit"). A candidate may match multiple blips across quadrants — keep them all.

For category queries (Step 1), select the strongest radar recommendations in that space: prefer `Keep`/`Start` blips in the matching quadrant, and note any `Stop` blips as things to avoid.

Step 4: Extract Tikal's Opinion

For every matched blip, parse the `description` HTML:

• The text inside the `<p>Why?</p>` block (up to the next `<p>Description</p>`)

is **Tikal's opinion / rationale** — the primary signal.

• The `<p>Description</p>` block is neutr