tech-radar-boot

tech-radar-boot

概述

这是 team-boot 的 Class Boots 目录列出的五个类启动工具之一，负责技术选型。它会展示 Tikal 的观点，说明与当前提示词相关的技术，帮助你根据以色列 Tech Radar 做出技术栈选择；同时也会提供记录建议：所选技术栈属于 ADR 类决策；该启动工具建议使用 /architect-specify，但自身不会编写草案。

Radar 查询的工作方式与 team-discover 类似，但搜索范围是 Tikal Tech Radar 数据集（实时从 https://tikalk.com/radar.json 获取），而不是团队 CDR 索引：它会从提示词中提取候选技术，将其与 Radar 条目匹配，并注入精简的 Tech Radar Context 表格（包含环、象限和 Tikal 的“Why?”观点），并为所有处于 Stop 环的技术提供符合 Tikal 建议的替代方案。

Radar 有四个象限——DevOps、Backend、AI/ML、Web/Mobile——以及四个采用环：

环	含义	建议
Try	表面上看起来不错的新事物（媒体评价不错、新解决方案）	探索／评估；尚未认可用于生产
Start	值得更多公司采用的好方案；如果处于 beta 阶段，则应有积极的进展和贡献	建议在新项目中采用
Keep	稳定版本（非 beta），并得到主要支持者认可（社区规模大、企业在使用）	默认建议用于当前和新项目
Stop	建议公司停止使用的项目——已有更好的替代方案	警示并建议采用 Keep／Start 环的替代方案

每个条目的 description 都包含一个 HTML <p>Why?</p> 块，后接一个 <p>Description</p> 块。Why? 文本体现了 Tikal 的明确立场和依据——应当展示的正是这一观点。同一种技术可能出现多次（位于不同象限），且环级别各不相同；应报告每个相关位置。

何时使用

只要提示词涉及选择或评估技术，就应在模型调用时使用此技能，例如：

• 选择框架、库、数据库、消息代理或云工具。
• 比较选项（“X 与 Y 对比”、“我们应该使用 Z 吗？”）。
• 设计涉及技术栈决策的系统、服务或流水线。
• 审查现有技术栈，以进行现代化改造或替换。
• 会话中途出现技术栈选择（ADR 检测触发条件）。

对于不涉及技术选型的纯业务／产品问题，或用户明确要求忽略 Radar 时，不要调用此技能。

遇到符合条件的任务时，应在开始时调用——在规划待办事项和实施之前——以便 Radar 上下文能够为规划提供依据。 不要拖到会话结束时再调用。

手动调用：

/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 框架”），就将该类别作为查询，并展示 Radar 在该领域推荐的选项。

步骤 2：查询实时 Radar 数据集

执行确定性搜索辅助脚本（相对于此技能目录）：

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 获取最新的 Radar JSON， 处理别名映射（k8s → Kubernetes、postgres → PostgreSQL、gh actions → GitHub Actions 等），提取 Tikal 的 <p>Why?</p> 观点，并自动生成 Markdown 表格。

如果某项技术出现在多个象限且对应的阶段相互冲突（例如， Node.js 同时出现在 DevOps: Stop 和 DevOps: Keep），脚本会检测到冲突， 并标注 冲突的指导意见。

实时 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
    }
  ]
}

步骤 3：匹配 Blip

对于步骤 1 中的每个候选项，按 name 查找匹配的 blip（不区分大小写， 识别别名，允许略有差异的版本后缀，例如“Airflow 2”/“Airflow 3”，以及 “Redux”→“Redux Toolkit”这类部分匹配）。一个候选项可能匹配多个象限中的 多个 blip——全部保留。

对于类别查询（步骤 1），从相应领域中选出最有力的 Radar 建议：优先选择 匹配象限中的 Keep/Start blip，并指出应避免的 Stop blip。

步骤 4：提取 Tikal 的观点

对于每个匹配的 blip，解析 description HTML：

• <p>Why?</p> 区块中的文本（直到下一个 <p>Description</p> 为止） 是 Tikal 的观点/理由——首要依据。
• <p>Description</p> 区块是中性的背景信息——仅在有帮助时使用。

去除 HTML 标签，转换为纯文本，并将“Why?”内容精简为一到两句话，放入上下文表格 （如果阶段为 Stop，或用户正在直接权衡该技术，则可引用更完整的内容）。

步骤 5：为 Stop 推荐替代方案

当候选项匹配到 Stop blip（或属于 Radar 明确不推荐的旧技术）时，从同一 象限中选择 Tikal 认可的 Keep 或 Start 替代方案，并以“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

不要硬编码超出已加载数据集支持范围的替换方案——应根据该象限中 Radar 的实际 Keep/Start blip 推导替代方案。

缺少上下文

如果本次会话中 team-boot 未注入团队上下文（首条用户消息中没有 Team Context & Decisions 部分——项目尚未配置或钩子执行失败）：用一行说明这一点，输出该部分标题，并添加 0 radar technologies matched (no team context injected — run /team-setup) 来源行，然后继续执行实时 Radar 查询任务。切勿将缺失的注入内容视为空记录集。恢复方法：运行 /team-diagnose。

步骤 6：注入 Tech Radar 上下文（输出约定）

脚本的 stdout 会发送到工具通道，用户不可见。始终在可见回复中、任务答案之前重新输出完整的 Tikal Tech Radar Context 部分（若匹配数为 0，则只输出标题和 _Source: 行）。 将其作为 Markdown 块输出——标题、表格行、指导要点和来源行各占一行；绝不要将此部分折叠成单行。

## 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 占一行（相关时，包括跨象限的重复项）。
• 整理一份简短的 Radar guidance 列表：可安全采用的技术，以及应避免并提供替代方案的技术。
• 添加一行 _Source_，注明数据来自实时 radar 源，以及匹配到的技术数量。
• N = 加载的数据集中扫描的 blip 数；K = 表格中显示的行数。**K 必须等于表格显示的行数。**匹配数为 0 → 只输出该部分的标题和 _Source: 行，不要输出表格。0 行的表格标题会折叠成未渲染的单行 Markdown；绝不要输出这种表格。

如果没有候选技术匹配任何 blip，请在标题和 _Source: 行中明确说明（例如 _Source: … · 匹配到 0 项技术。）——不要输出表格，也不要捏造 radar 评级。

步骤 7：记录选择（决策配对）

技术选型属于 ADR 级决策。如果当前工作目录中没有本地记忆索引，且该目录位于工作区内（通过祖先目录中的 .gitmodules 标记检测），则改为读取工作区根目录下的 docs/adlc/memory/ 索引（双重读取顺序适用：先读 docs/adlc/memory，再回退到旧版 .adlc/memory）。

触发条件	操作
选定技术栈（“我们将使用 X”）	ADR → 建议使用 /architect-specify，并引用为该选择提供依据的 radar 行
已解决“X 与 Y”的比较	ADR → 建议使用 /architect-specify，并附上比较结论
仍然采用 Stop 环技术	ADR → 建议使用 /architect-specify，记录覆盖 radar 指导的原因

在 Team Context & Decisions 中为该选择添加或更新行（ID | Name | Type | Rel | Status | Clarify），并同步添加为任务列表待办事项（对于已存在的草稿，建议在会话结束时使用 /architect-specify → 对应的 clarify 技能）；代码修改任务完成后，添加一条收尾待办，检查 Team Context & Decisions，直到 Unrecorded: 0 pending · Unclarified: 0 drafts（草稿只有通过其 clarify 技能，或用户明确将其交接给指定的 clarify 或 execute 技能，才能从 Unclarified 中移除）。如果本次会话中已调用 architect-boot，则在其记录行中补充 radar 证据；会话结束时，给出澄清提示，列明每项尚未记录的技术选型决策（ID + 记录技能）和每项已记录的草稿（ID + clarify 技能）；如果用户推迟澄清，则将这些行标记为已交接。

故障处理

• 实时获取失败（网络错误、超时、JSON 无效）→ 脚本以非零状态退出，并向 stderr 输出清晰的错误消息。该技能必须输出一个空的上下文表，注明 Tech Radar 源不可访问，并继续处理用户的任务，不附带 radar 上下文——绝不要将过时的缓存或捆绑数据冒充为当前数据。
• 无匹配项 → 仅输出标题和 0 项技术匹配 的来源行，不要输出表格。

红旗

• 为未出现在已加载数据集中的技术编造环形、象限或“Why?”观点——应改为报告 0 matches。
• 实时获取失败时，悄悄改用缓存、捆绑或过时的雷达数据——始终报告雷达源不可访问，绝不能把旧数据说成当前数据。
• 硬编码未经已加载雷达数据支持的 Stop→替代方案映射。
• 把中性的 <p>Description</p> 文本当作 Tikal 的观点来报告——观点位于 <p>Why?</p> 块中。
• 忽略重复的条目：同一技术可能位于不同象限、属于不同环；应列出每个相关位置。
• 把加载技能当作完成工作——必须实际运行核心流程并生成 Tech Radar Context 表。
• 通过脚本读取雷达发现后直接作答，却不重新输出上下文部分（脚本标准输出会进入工具通道，用户看不到）——可见回复必须包含这些发现。
• 把上下文部分压缩成一行——标题、表格行、指南和来源行都必须各占一行 Markdown。
• 注入雷达上下文，却跳过建议记录——未写入 ADR 的技术选型，最终只会成为转瞬即逝的决策。
• 自行撰写草稿（或任何文件）——启动流程只会提供建议；由 /architect-specify 负责写入。

验证

• 已从提示中提取候选技术（若未指定产品，则已形成类别查询）。
• 已从 https://tikalk.com/radar.json 实时获取雷达数据集。
• 已生成包含 Technology / Quadrant / Ring / Tikal's Opinion (Why?) 列的 Tikal Tech Radar Context 表，且观点来源于 <p>Why?</p> 块。
• Stop 环中的匹配项包含来自同一象限、与 Tikal 观点一致的 Keep/Start 替代方案，且这些方案是从数据集中得出的。
• _Source_ 行报告实时雷达数据源和匹配数；若无匹配，则不生成表格（仅保留标题和来源行），而非编造数据。若获取失败，则报告错误，并在不含雷达上下文的情况下继续运行技能。
• 本次会话中的技术选型会出现在 Team Context & Decisions 中，并以 /architect-specify 作为记录技能；每项都包含 _Suggested capture: … → run /architect-specify._ 行；此技能不会写入任何文件。

Configuration

• 数据源：https://tikalk.com/radar.json（每次调用时实时获取；无捆绑快照或缓存）。
• 获取超时：10 秒。获取失败时，技能会在不含雷达上下文的情况下继续运行，而不会阻塞或替换为过时数据。
• 获取安全性：辅助程序将传输限定为 HTTPS（包括重定向），并在网络错误、超时或 JSON 无效时安全失败。雷达内容仅作为展示数据处理，绝不执行。若获取失败，则报告错误，并在不含雷达上下文的情况下继续运行。