Sigues un tutorial de hace unos meses para enseñarle Notion a tu agente: hermes skills search notion, y las entradas integradas ya no están — solo quedan las fuentes de repositorios. Empiezas a preguntarte si rompiste tu instalación. No lo hiciste. Hermes retiró siete skills opcionales integradas porque los problemas que resolvían ahora tienen mejores dueños.

No es una función que se recorta, sino un nuevo reparto de dónde vienen las skills. Entenderlo te ahorra dos tipos de dolor: instalar algo que ya no existe, e instalar algo que después se ejecuta bajo una política obsoleta.

Las siete skills retiradas y quién tomó el relevo

Estas skills opcionales integradas se eliminaron porque los MCP oficiales de los proveedores, los catalog plugins, los backends de búsqueda incluidos o los repositorios de skills de los propios proveedores las cubren mejor:

Skill integrada retirada	Ahora la cubre
notion	MCP oficial de Notion en el catálogo MCP (OAuth, sin necesidad de Portal) + conector alojado + makenotion/skills
airtable	MCP oficial de Airtable + conector alojado + Airtable/skills
shopify	Conector alojado + la skill mantenida por el proveedor en Shopify/Shopify-AI-Toolkit
duckduckgo-search	Backend de búsqueda web ddgs incluido (web_search funciona sin clave)
searxng-search	Backend searxng incluido vía SEARXNG_URL
honcho	El catalog plugin honcho, dueño de los comandos hermes honcho que documentaba esa skill
mpp-agent	Los catalog plugins verificados pay / pay-cli (HTTP 402 / x402 / MPP)

Un efecto secundario que conviene conocer: AIRTABLE_API_KEY salió de la lista de variables de entorno opcionales, porque esa skill era su único consumidor. NOTION_API_KEY se queda, ya que el sink de Notion del pipeline de reuniones de Teams todavía la lee.

Así que si usabas la skill integrada para Airtable, el camino a seguir es el MCP oficial o el repo de skills del proveedor. La capacidad no desapareció: se mudó a la parte que sigue los cambios de API.

Taps: dónde se descubren realmente las skills

La búsqueda de skills no solo recorre tu directorio local. Mira a través de un conjunto de fuentes llamadas taps. Los taps por defecto son un conjunto fijo de repositorios — openai/skills, anthropics/skills, huggingface/skills, NVIDIA/skills y otros — y este cambio añadió tres repos de proveedores:

• makenotion/skills (ruta skills/)
• Airtable/skills (ruta plugins/airtable/skills/)
• Shopify/Shopify-AI-Toolkit (ruta skills/)

La diferencia entre un repo de proveedor y un repo comunitario general no es la calidad, sino la propiedad clara. El repositorio pertenece al proveedor y la licencia es explícita, así que puede sumarse a la lista de confianza por defecto en lugar de tratarse como contenido community en cada instalación.

Puedes añadir taps tú mismo, que es la forma más barata de distribuir skills dentro de un equipo:

hermes skills tap list            # fuentes configuradas
hermes skills tap add <owner>/<repo>
hermes skills browse --source github
hermes skills inspect notion-cli  # léelo antes de instalar
hermes skills install notion-cli

No confundas hermes skills tap con hermes skills trust. El primero gestiona dónde se encuentran las skills; el segundo decide si las skills locales del repo, como ./.hermes/skills, pueden cargarse siquiera. Nombres parecidos, trabajos sin relación.

Niveles de trust: la tabla que decide qué se instala

Después del escaneo, una skill recibe un nivel de trust, y la política de instalación es una consulta sobre ese nivel cruzada con el veredicto del escaneo (safe / caution / dangerous):

Nivel de trust	safe	caution	dangerous
builtin	permitir	permitir	permitir
trusted (repos de proveedores / oficiales)	permitir	permitir	bloquear
community	permitir	bloquear	bloquear
agent-created	permitir	permitir	se entrega al agente

Esta tabla explica dos cosas con las que la gente tropieza. Primero, por qué la misma skill se instala desde un repo y no desde otro: la fuente fija el nivel, y el nivel decide si los hallazgos caution se bloquean. Segundo, por qué vale la pena listar los repos de proveedores de forma explícita: trusted deja pasar caution, community no. Esa única celda es toda la diferencia.

trusted no significa libre de riesgo. Los hallazgos dangerous se bloquean desde cualquier fuente que no sea builtin, sin excepción.

El bug de caché de una línea que mantenía una política antigua

Los escaneos de skills se cachean para que las instalaciones no reescaneen todo. La clave de caché usaba el hash del contenido, la fuente y la versión del escáner — y, de forma bastante elocuente, no el nivel de trust.

La consecuencia es concreta. Escaneas una skill, luego actualizas Hermes después de que su repositorio se añadió (o se quitó) de la lista de confianza, y las instalaciones siguen aplicando el nivel de trust registrado en ese escaneo anterior, hasta que cambie el contenido de la skill. En otras palabras, las ediciones de la lista de repos de confianza se saltaban por completo la clave de caché.

El arreglo mete el nivel de trust actual en la clave de caché: un escaneo cacheado solo se reutiliza si el nivel de trust actual de la fuente sigue coincidiendo; si no, la skill se vuelve a escanear. Una línea, con tests en ambos sentidos: un repo recién marcado como trusted se reescanea como trusted, uno eliminado se reescanea como community, y una fuente sin cambios sigue siendo un acierto de caché.

Ese arreglo está fusionado en main pero no está en el tag v0.22.7, así que llega con el próximo release. Mientras tanto, si cambiaste el trust hace poco y la política parece equivocada, hermes skills audit para reescanear las skills instaladas es el workaround directo.

Tres cosas que hacer ahora

1. Inventario: ejecuta hermes skills list y busca cualquier cosa que siga apuntando a una skill retirada, sobre todo nombres codificados a mano en scripts del equipo.
2. Redirige: mueve la automatización de Notion, Airtable y Shopify a los MCP oficiales o a los repos de skills de los proveedores; para búsqueda, usa los backends ddgs / searxng incluidos en lugar de instalar una skill.
3. Audita: tras actualizar, ejecuta hermes skills audit una vez para que nada siga corriendo bajo un nivel de trust antiguo.

Menos skills integradas suele ser buena noticia. Siete implementaciones menos que mantener, repos de proveedores que siguen sus propias APIs y MCP oficiales que llegan con OAuth en vez de pedirte copiar una API key: la carga de mantenimiento aterrizó donde corresponde.

Para seguir leyendo: skills locales del proyecto y la puerta de trust, las tres skills opcionales añadidas antes, una actualización guiada, qué más hay en la ventana de v0.22.7.