Tech Radar Boot

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:

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 neutral background — use only if helpful.

Strip HTML tags to plain text and condense the "Why?" to one or two sentences for the context table (quote it more fully when the ring is Stop or when the user is directly weighing that technology).

Step 5: Recommend Alternatives for Stop

When a candidate matches a Stop blip (or is a legacy technology the radar clearly discourages), select Tikal-aligned replacements from the same quadrant on Keep or Start, guided by the "Why?" text. Common examples the dataset supports:

• 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

Do not hardcode substitutions beyond what the loaded dataset supports — derive alternatives from the radar's actual Keep/Start blips in that quadrant.

Absent Context

If team-boot injected no team context this session (no Team Context & Decisions section in the first user message — unconfigured project or hook failure): say so in one line, emit the section heading with a 0 radar technologies matched (no team context injected — run /team-setup) source line, and continue the task on the live radar lookup. Never treat a missing injection as an empty record set. Recovery: run /team-diagnose.

Step 6: Inject Tech Radar Context (Output Contract)

The script's stdout goes to the tool channel — invisible to the user. ALWAYS re-emit the full Tikal Tech Radar Context section in your visible response, before the task answer (or, when 0 matched, the heading + _Source: line). Emit it as markdown blocks — heading, table rows, guidance bullets, and source line each on their own lines; never collapse the section into a single line.

## 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._

• One row per matched blip (include duplicates across quadrants when relevant).
• Group a short Radar guidance list: safe-to-adopt vs avoid-with-alternatives.
• Add a _Source_ line noting the data came from the live radar source and how many technologies matched.
• N = blips scanned in the loaded dataset; K = rows shown in the table. K MUST equal the table rows shown. 0 rows matched → emit the section heading + the _Source: line only — no table. A 0-row table header collapses into unrendered single-line markdown; never emit one.

If no candidate technology matches any blip, state that plainly with the heading

• _Source: line (e.g. _Source: … · 0 technologies matched._) — no table — do not fabricate radar placements.