Cómo crear una Skill para Hermes Agent paso a paso

Crear una Skill para Hermes Agent me parece una de las formas más interesantes de ampliar lo que puede hacer el agente sin complicar innecesariamente su arquitectura.

Cuando empecé a plantearme este tipo de automatizaciones, una de las cosas que más sentido me hizo fue precisamente esa: no todo necesita convertirse en una integración programada desde cero.

Muchas veces ya tenemos las herramientas necesarias.

Tenemos comandos de terminal, scripts, Docker, Git, APIs, utilidades instaladas en el servidor o procedimientos que seguimos manualmente cada vez que ocurre algo. Lo único que falta es enseñarle a Hermes cómo queremos que utilice esas herramientas y en qué orden debe hacerlo.

Ahí es donde entran las Skills.

En lugar de volver a explicarle al agente cada vez qué comandos debe ejecutar, qué información debe comprobar o cómo debe reaccionar ante determinadas situaciones, podemos convertir ese conocimiento en una habilidad reutilizable.

Y esto abre bastantes posibilidades.

Podemos crear una Skill para revisar contenedores Docker, analizar logs, trabajar con repositorios Git, preparar despliegues, gestionar copias de seguridad, consultar documentación o ejecutar determinados procedimientos de mantenimiento.

En esta guía voy a explicar cómo crear una Skill para Hermes Agent desde cero, qué estructura tiene un archivo SKILL.md, cuándo merece la pena utilizar una Skill en lugar de desarrollar una Tool y cómo probar que nuestra habilidad realmente funciona.

La idea no es solamente terminar con un archivo Markdown.

Lo interesante es aprender a transformar un procedimiento que repetimos habitualmente en una capacidad que Hermes pueda reutilizar.

Qué es una Skill en Hermes Agent y para qué sirve

Una Skill es, simplificando bastante, una forma de enseñarle a Hermes cómo realizar una tarea determinada.

No tenemos necesariamente que añadir una capacidad completamente nueva al agente.

Podemos aprovechar herramientas que Hermes ya puede utilizar y proporcionarle las instrucciones necesarias para combinarlas correctamente.

Esta diferencia es importante.

Si Hermes ya puede ejecutar comandos en una terminal, por ejemplo, probablemente no necesitemos desarrollar desde cero una integración específica solamente para ejecutar docker ps, consultar unos logs o comprobar el estado de un servicio.

Podemos crear una Skill donde definamos:

• cuándo tiene sentido realizar esas comprobaciones;
• qué comandos deben utilizarse;
• en qué orden deben ejecutarse;
• cómo interpretar la información obtenida;
• qué situaciones requieren precaución;
• cómo comprobar que el procedimiento ha terminado correctamente.

Yo no veo una Skill únicamente como una función adicional.

Me resulta más útil verla como una forma de documentar un procedimiento para que Hermes pueda repetirlo siguiendo nuestros criterios.

Eso permite convertir tareas que normalmente requieren varias instrucciones en procesos bastante más reutilizables.

Qué puede hacer una Skill

Las posibilidades dependen principalmente de las herramientas disponibles en nuestra instalación de Hermes y del entorno donde se ejecute.

Podemos utilizar Skills para procedimientos como:

• revisar el estado de un servidor;
• analizar logs;
• trabajar con contenedores Docker;
• utilizar comandos Git;
• consultar determinada documentación;
• ejecutar scripts existentes;
• preparar informes;
• comprobar servicios;
• realizar determinadas tareas mediante SSH;
• seguir procedimientos de despliegue o mantenimiento.

Una Skill no tiene por qué hacer algo espectacular.

De hecho, algunas de las mejores automatizaciones son precisamente aquellas que eliminan pequeñas tareas repetitivas.

Si cada vez que aparece una incidencia tengo que explicarle a Hermes qué servicio debe revisar, qué logs consultar y qué comprobaciones realizar después, probablemente ese proceso ya sea un buen candidato para convertirse en una Skill.

Ejemplos de Skills para Docker, Git, logs, backups y SSH

Imaginemos que administramos varias aplicaciones mediante Docker.

Cuando un servicio deja de funcionar, nuestro procedimiento habitual podría ser:

1. comprobar los contenedores activos;
2. localizar contenedores detenidos;
3. revisar sus últimos logs;
4. comprobar el estado del servicio;
5. evitar reinicios automáticos si no conocemos todavía la causa;
6. presentar un diagnóstico antes de realizar cambios.

Todo eso puede convertirse en una Skill.

Podemos hacer algo similar con Git.

Por ejemplo, podríamos definir cómo queremos que Hermes revise cambios pendientes antes de actualizar una aplicación, qué ramas debe comprobar o qué verificaciones queremos realizar antes de un despliegue.

También podemos documentar nuestro procedimiento de backups o nuestras comprobaciones habituales cuando entramos por SSH en un servidor.

En mi caso, esta es precisamente una de las ideas que más me interesan de las Skills: no solamente estamos añadiendo funciones; también estamos enseñando al agente nuestros procedimientos.

Skill vs Tool en Hermes Agent: cuál necesitas realmente

Antes de crear nada, conviene responder una pregunta:

¿realmente necesito una Skill o debería desarrollar una Tool?

La frontera no siempre es absoluta, pero hay una regla práctica que me resulta bastante útil.

Si puedo enseñarle a Hermes cómo resolver el problema utilizando herramientas que ya tiene disponibles, empiezo pensando en una Skill.

Si necesito darle una capacidad técnica nueva, integrar una API de una forma muy controlada o realizar un procesamiento específico que debería comportarse siempre de manera determinista, probablemente tenga más sentido crear una Tool.

Cuándo es suficiente crear una Skill

Una Skill suele ser una buena solución cuando el trabajo consiste principalmente en:

• seguir instrucciones;
• ejecutar comandos de shell;
• utilizar herramientas que Hermes ya conoce;
• combinar varios pasos;
• interpretar resultados;
• aplicar un procedimiento;
• verificar que el resultado es correcto.

Pensemos de nuevo en Docker.

Si Hermes ya puede utilizar la terminal, no necesito programar una herramienta completa simplemente para enseñarle qué comandos utilizar cuando quiero diagnosticar un contenedor.

Puedo documentar el procedimiento en una Skill.

Lo mismo ocurre con muchas tareas basadas en Git, consultas de documentación o mantenimiento de servidores.

Cuándo merece la pena desarrollar una Tool

Una Tool empieza a tener más sentido cuando necesitamos algo diferente.

Por ejemplo:

• autenticaciones complejas;
• manejo específico de una API;
• procesamiento estructurado de datos;
• validaciones estrictas;
• operaciones que deben ejecutarse siempre exactamente de la misma forma;
• una nueva capacidad que Hermes no tiene disponible mediante sus herramientas actuales.

También elegiría una Tool cuando quiero reducir al máximo la interpretación del agente durante una operación sensible.

No todo debería delegarse a instrucciones flexibles.

Hay tareas donde interesa encapsular el comportamiento en código y exponer únicamente una operación bien definida.

Skill o Tool: ejemplos prácticos

Podemos utilizar esta tabla como regla orientativa:

Necesidad	Skill	Tool
Seguir un procedimiento	Muy adecuada	Posible
Ejecutar comandos existentes	Muy adecuada	Normalmente innecesaria
Utilizar herramientas ya disponibles	Muy adecuada	Posible
Interpretar resultados	Sí	Sí
Integración específica con API	Depende	Muy adecuada
Autenticación compleja	Limitada	Muy adecuada
Procesamiento personalizado	Limitado	Muy adecuada
Comportamiento altamente determinista	Depende	Muy adecuada

Para mí, esta separación evita uno de los errores más habituales al crear automatizaciones: convertir una tarea relativamente sencilla en un desarrollo mucho más complejo de lo necesario.

Cómo funciona una Skill de Hermes Agent

Una Skill necesita describir suficientemente bien la capacidad que queremos enseñar.

El elemento central suele ser un archivo llamado SKILL.md.

Este archivo combina metadatos con instrucciones que explican al agente cuándo utilizar esa habilidad y qué procedimiento debe seguir.

Dependiendo de la versión y configuración de Hermes que estemos utilizando, podemos tener diferentes opciones de metadatos o requisitos. Por eso conviene comprobar siempre la documentación correspondiente a nuestra instalación antes de depender de un campo específico.

El concepto general, sin embargo, es bastante sencillo.

Tenemos un directorio para nuestra Skill y, dentro, un archivo similar a este:

mi-skill/
└── SKILL.md

A partir de ahí podemos añadir otros recursos si nuestra habilidad los necesita.

El archivo SKILL.md

SKILL.md es donde describimos nuestra habilidad.

Normalmente encontraremos dos partes importantes:

1. metadatos o frontmatter;
2. instrucciones de la Skill.

Un ejemplo simplificado podría tener esta forma:

---
name: docker-diagnostics
description: Revisa el estado de contenedores Docker y analiza problemas básicos antes de realizar cambios.
---

# Docker Diagnostics

Utiliza esta skill cuando el usuario quiera diagnosticar un problema
relacionado con contenedores Docker.

## Procedimiento

1. Comprueba qué contenedores están ejecutándose.
2. Identifica contenedores detenidos o reiniciándose.
3. Consulta los logs relevantes.
4. Resume el posible origen del problema.
5. No reinicies ni elimines contenedores sin confirmación cuando la acción
   pueda afectar al servicio.

Esto no pretende ser una plantilla universal para todas las versiones de Hermes, sino mostrar la idea.

Una buena Skill debería responder rápidamente a varias preguntas:

• ¿para qué sirve?
• ¿cuándo debe utilizarse?
• ¿qué herramientas necesita?
• ¿qué pasos debe seguir?
• ¿qué debe evitar?
• ¿cómo verifica que ha terminado correctamente?

Frontmatter YAML e instrucciones

El frontmatter permite incluir información estructurada sobre la Skill.

Después encontramos las instrucciones en Markdown.

Aquí es donde conviene ser especialmente claro.

Decir:

Revisa Docker y arregla el problema.

es una instrucción demasiado vaga.

En cambio:

Comprueba primero el estado de los contenedores. Si alguno está detenido, revisa los últimos logs antes de sugerir un reinicio. Presenta primero el diagnóstico y evita eliminar volúmenes o contenedores salvo petición explícita.

define mucho mejor nuestro procedimiento.

Cuanto más importante sea la tarea, más útil resulta explicar los pasos, límites y verificaciones.

Cómo sabe Hermes cuándo debe utilizar una Skill

La descripción de la Skill es especialmente importante.

Debe explicar claramente qué problema resuelve.

Si creamos descripciones demasiado genéricas, el agente puede tener más dificultades para decidir cuándo resulta relevante utilizar esa habilidad.

Por ejemplo, una descripción como:

Ayuda con servidores.

resulta demasiado abierta.

Una descripción como:

Diagnostica incidencias en aplicaciones desplegadas mediante Docker comprobando contenedores, estado y logs.

expresa mucho mejor el contexto.

No se trata de escribir una descripción enorme.

Se trata de definir con suficiente precisión la tarea.

Cómo crear una Skill para Hermes Agent paso a paso

Una vez entendida la estructura, podemos crear nuestra propia habilidad.

Yo empezaría siempre por el procedimiento y no por el archivo.

Es bastante tentador abrir un editor, crear SKILL.md y empezar a escribir instrucciones sin haber pensado realmente qué queremos automatizar.

Normalmente funciona mejor hacerlo al revés.

1. Define primero el procedimiento que quieres automatizar

Antes de crear la Skill, escribe manualmente qué harías tú.

Supongamos que queremos diagnosticar una aplicación Docker.

Nuestro procedimiento puede ser:

1. comprobar si Docker está disponible;
2. listar contenedores;
3. identificar estados anómalos;
4. revisar logs relevantes;
5. comprobar si el contenedor se está reiniciando;
6. presentar un resumen;
7. pedir confirmación antes de determinadas acciones.

Este primer borrador no tiene que ser perfecto.

Pero debería reflejar un procedimiento que utilizaríamos realmente.

Las mejores Skills, en mi opinión, nacen de tareas que ya hemos realizado suficientes veces como para saber qué pasos funcionan y qué errores queremos evitar.

2. Crea el directorio de la Skill

A continuación creamos una carpeta específica.

Por ejemplo:

mkdir -p docker-diagnostics
cd docker-diagnostics

Dentro crearemos:

SKILL.md

En instalaciones donde las Skills se cargan desde una ubicación concreta, tendremos que situar posteriormente este directorio en la ruta correspondiente o añadirlo mediante la configuración disponible.

3. Crea el archivo SKILL.md

Podemos empezar con una estructura sencilla:

---
name: docker-diagnostics
description: Diagnostica problemas básicos en servicios Docker revisando estado, contenedores y logs.
---

# Docker Diagnostics

## Cuándo utilizar esta skill

Utiliza esta skill cuando sea necesario diagnosticar un problema
relacionado con servicios ejecutados mediante Docker.

## Procedimiento

1. Comprueba que Docker está disponible.
2. Lista los contenedores.
3. Identifica estados anómalos.
4. Consulta los logs relevantes.
5. Explica lo encontrado.
6. Evita acciones destructivas sin confirmación.

## Verificación

Comprueba que el diagnóstico identifica claramente el servicio afectado
y proporciona evidencia de los comandos utilizados.

Ya tenemos una Skill básica.

Pero todavía podemos mejorarla bastante.

4. Añade el frontmatter YAML

El frontmatter debería contener los metadatos que nuestra versión de Hermes admita y necesite.

Algunas Skills pueden requerir herramientas determinadas, variables de entorno, archivos de credenciales u otros requisitos.

Mi recomendación aquí es sencilla:

añade únicamente los requisitos reales de la Skill.

No conviertas el frontmatter en una colección de campos innecesarios.

Cuanto más sencillo sea entender qué necesita la habilidad, más fácil será mantenerla posteriormente.

5. Escribe instrucciones claras y accionables

Esta probablemente sea la parte más importante.

Una Skill no debería obligar al agente a adivinar nuestro procedimiento.

En lugar de:

Comprueba qué ocurre.

podemos escribir:

Lista primero los contenedores y revisa si alguno se encuentra detenido o reiniciándose. No ejecutes cambios hasta haber consultado los logs correspondientes.

Ese pequeño cambio elimina bastante ambigüedad.

También podemos especificar qué queremos recibir como resultado:

## Resultado esperado

Devuelve:

- contenedor afectado;
- estado actual;
- últimos errores relevantes;
- posible causa;
- siguiente acción recomendada.

Ahora Hermes sabe no solamente qué debe hacer, sino también cómo queremos organizar la respuesta.

6. Define errores, comprobaciones y resultado esperado

Un procedimiento real rara vez funciona siempre exactamente igual.

Puede ocurrir que:

• Docker no esté instalado;
• el usuario actual no tenga permisos;
• no exista el contenedor indicado;
• los logs estén vacíos;
• haya varios servicios afectados;
• una acción requiera confirmación.

Una buena Skill debería anticipar los casos más importantes.

Por ejemplo:

## Errores y situaciones especiales

- Si Docker no está disponible, informa del problema y detén el procedimiento.
- Si falta permiso para consultar los contenedores, no intentes modificar permisos automáticamente.
- Si no puedes identificar el servicio afectado, solicita más información.
- No elimines contenedores, imágenes o volúmenes como parte del diagnóstico.

Esto hace que la Skill sea mucho más útil que una simple lista de comandos.

Estructura recomendada de un archivo SKILL.md

No existe una única forma de escribir todas las Skills.

Sin embargo, para procedimientos operativos me resulta especialmente útil mantener una estructura predecible.

Así puedo crear nuevas habilidades más rápido y revisar las existentes sin tener que descifrar cada una desde cero.

Una estructura que utilizaría como punto de partida sería:

---
name: nombre-skill
description: Explicación breve y específica del propósito.
---

# Nombre de la Skill

## Cuándo utilizar esta skill

Explica qué situaciones deberían activar este procedimiento.

## Requisitos

Indica herramientas, comandos, configuración o dependencias necesarias.

## Procedimiento

1. Primer paso.
2. Segundo paso.
3. Tercer paso.

## Situaciones especiales

Define errores, excepciones y límites.

## Resultado esperado

Explica qué información debe devolver.

## Verificación

Indica cómo comprobar que la tarea se ha realizado correctamente.

Nombre y descripción

El nombre debería identificar fácilmente la habilidad.

La descripción tiene que ser mucho más útil para el agente que para una persona que está simplemente navegando por carpetas.

Por eso intentaría describir el problema que resuelve.

Por ejemplo:

description: Revisa contenedores Docker, detecta estados anómalos y consulta logs para diagnosticar incidencias.

es mejor que:

description: Herramientas Docker.

Cuándo debe utilizarse la Skill

Este apartado puede parecer redundante si ya tenemos una descripción, pero nos permite añadir matices.

Podemos escribir:

Utiliza esta Skill cuando:

- una aplicación ejecutada en Docker no responda;
- el usuario quiera comprobar el estado de los contenedores;
- sea necesario revisar logs de un servicio Docker;
- exista un contenedor que se reinicia repetidamente.

Esto proporciona bastante contexto.

Herramientas y requisitos

Si el procedimiento necesita Docker, Git, curl u otra utilidad, es conveniente dejarlo claro.

Cuando existen variables de entorno o credenciales, también tenemos que documentar sus requisitos de la forma admitida por nuestro entorno de Hermes.

El objetivo es evitar que la Skill dependa de condiciones invisibles.

Procedimiento paso a paso

Aquí deberíamos describir lo que realmente hacemos.

Un buen procedimiento suele tener:

• un punto de entrada claro;
• pasos ordenados;
• condiciones;
• límites;
• una salida esperada.

No hace falta convertir cada Skill en un manual de cincuenta páginas.

Pero sí deberíamos incluir la información que evitaría tener que volver a explicar manualmente la tarea.

Errores y situaciones especiales

Esta es una de las secciones que más valor añade.

Cuando diseñamos un procedimiento por primera vez tendemos a pensar solamente en el camino ideal.

Sin embargo, los agentes suelen trabajar mucho mejor cuando también les enseñamos qué hacer cuando ese camino no existe.

Verificación del resultado

También me gusta terminar explicando qué significa realmente que la tarea haya finalizado.

Por ejemplo, en una Skill de diagnóstico Docker, “terminar” no significa únicamente haber ejecutado docker ps.

Significa haber identificado el estado, revisado la evidencia disponible y devuelto un diagnóstico comprensible.

Ejemplo práctico: crear una Skill de Hermes Agent para revisar Docker

Vamos a reunir todo lo anterior en un ejemplo algo más completo.

Quiero crear una Skill que me ayude cuando una aplicación desplegada con Docker presenta problemas.

No quiero que el agente reinicie cosas automáticamente.

Primero quiero un diagnóstico.

Qué queremos que haga la Skill

El comportamiento será:

1. comprobar que Docker funciona;
2. listar contenedores;
3. localizar estados anómalos;
4. consultar logs;
5. identificar errores relevantes;
6. resumir la información;
7. pedir confirmación antes de realizar cambios importantes.

Esta última parte me parece especialmente importante.

Automatizar no debería significar convertir cualquier diagnóstico en una secuencia de acciones destructivas.

Crear el SKILL.md

Podríamos partir de algo como:

---
name: docker-diagnostics
description: Diagnostica incidencias en aplicaciones Docker revisando contenedores, estado y logs antes de realizar cambios.
---

# Docker Diagnostics

## Cuándo utilizar

Utiliza esta Skill cuando el usuario solicite diagnosticar un problema
relacionado con Docker o cuando una aplicación desplegada mediante
contenedores no funcione correctamente.

## Procedimiento

1. Comprueba que el comando `docker` está disponible.
2. Lista los contenedores y sus estados.
3. Identifica contenedores detenidos, unhealthy o en reinicio.
4. Consulta los logs del servicio afectado.
5. Extrae los errores relevantes.
6. Resume el diagnóstico.
7. Sugiere la siguiente comprobación o acción.

## Seguridad

No ejecutes automáticamente operaciones que eliminen contenedores,
imágenes, redes o volúmenes.

No reinicies servicios salvo que el usuario lo solicite o confirme
la acción después del diagnóstico.

## Resultado esperado

Incluye:

- servicio afectado;
- estado;
- evidencia encontrada;
- posible causa;
- siguiente paso recomendado.

## Verificación

Antes de terminar, comprueba que el diagnóstico está respaldado por
la información obtenida durante las comprobaciones.

Ya tenemos algo bastante útil.

Definir los comandos que puede ejecutar

En las instrucciones podemos explicar qué comandos suelen servir para cada paso.

Por ejemplo:

docker ps

o, cuando necesitemos ver también contenedores detenidos:

docker ps -a

Para consultar logs de un contenedor concreto:

docker logs --tail 100 nombre-contenedor

La Skill no tiene por qué convertirse en una gigantesca colección de comandos.

Me parece mejor explicar para qué se utiliza cada uno y en qué momento.

Enseñarle a interpretar contenedores y logs

Aquí está una de las diferencias entre una Skill útil y una lista de comandos.

No queremos solamente que Hermes ejecute docker ps.

Queremos que se fije en señales relevantes:

• contenedores detenidos;
• reinicios repetidos;
• estados unhealthy;
• errores recientes;
• excepciones;
• problemas de conexión;
• fallos de configuración.

Después debe relacionar esa información con el problema descrito por el usuario.

Añadir comprobaciones antes de actuar

También podemos enseñar nuestros criterios operativos.

Por ejemplo:

Antes de reiniciar un contenedor:

1. revisa sus logs;
2. identifica si el fallo parece recurrente;
3. comprueba si reiniciarlo podría interrumpir el servicio;
4. explica qué acción propones;
5. solicita confirmación si existe riesgo operativo.

Esta es precisamente la parte que más valor tiene para mí.

Estamos codificando conocimiento de trabajo.

No solamente estamos diciéndole al agente que sabe utilizar Docker.

Le estamos enseñando cómo queremos utilizar Docker en nuestro entorno.

Variables de entorno, credenciales y secretos en una Skill

Hay otro aspecto importante cuando empezamos a crear Skills más avanzadas.

Tarde o temprano alguna necesitará acceder a una API, un servidor o una herramienta autenticada.

Aquí debemos tener cuidado.

No deberíamos utilizar SKILL.md como un lugar donde escribir indiscriminadamente contraseñas, tokens o claves privadas.

Qué datos no deberías escribir directamente en SKILL.md

Evitaría incluir directamente:

• contraseñas;
• tokens de acceso;
• claves de API;
• claves SSH privadas;
• secretos internos.

El archivo debería describir qué credencial necesita la Skill, no necesariamente contener el secreto.

Variables de entorno

Para determinados valores, una variable de entorno puede ser una solución más razonable.

La Skill puede documentar que necesita una variable concreta y el entorno puede encargarse de proporcionar su valor.

Esto además facilita utilizar la misma Skill en varios servidores o instalaciones.

Archivos de credenciales

Algunas integraciones pueden necesitar archivos de configuración o credenciales.

De nuevo, la Skill debería depender del mecanismo de configuración correspondiente en lugar de incrustar información sensible en las instrucciones.

Hermes dispone, según versión y configuración, de mecanismos para declarar determinados requisitos como variables de entorno o archivos de credenciales. Conviene revisar cuáles están disponibles en nuestra instalación antes de diseñar la habilidad alrededor de ellos.

Cuándo una integración ya debería convertirse en una Tool

Este punto vuelve a conectarnos con Skill vs Tool.

Si para que una Skill funcione estamos empezando a construir una gran capa de autenticación, transformación de datos, control de errores y lógica específica, probablemente deberíamos detenernos.

Quizá el problema ya no sea “enseñar un procedimiento”.

Quizá estemos desarrollando una integración.

Y en ese caso una Tool puede ser una arquitectura más apropiada.

Cómo instalar y cargar una Skill en Hermes Agent

Una Skill perfectamente escrita no sirve de mucho si Hermes no puede encontrarla.

Aquí tenemos que comprobar cómo está configurada nuestra instalación.

Hermes permite trabajar con directorios de Skills y, dependiendo del entorno, podremos utilizar ubicaciones locales o directorios externos configurados para cargar nuestras habilidades.

En instalaciones donde se utilice el directorio habitual de usuario, podemos encontrarnos con una estructura similar a:

~/.hermes/skills/

y dentro:

~/.hermes/skills/docker-diagnostics/SKILL.md

Pero no asumiría esta ruta a ciegas en cualquier despliegue.

Comprobaría primero la configuración de la instalación correspondiente.

Dónde guardar las Skills

La idea general es mantener cada Skill dentro de su propio directorio:

skills/
├── docker-diagnostics/
│   └── SKILL.md
├── git-deploy/
│   └── SKILL.md
└── server-backup/
    └── SKILL.md

Esto facilita mantenerlas, compartirlas y ampliarlas posteriormente.

Añadir directorios externos

En determinados entornos podemos necesitar utilizar directorios adicionales.

Esto resulta especialmente útil si queremos mantener nuestras Skills dentro de un repositorio Git independiente en lugar de mezclarlas con otros archivos de configuración.

También puede ser práctico para compartir una biblioteca de Skills entre varios entornos.

Comprobar que Hermes reconoce la Skill

Después de añadirla, lo siguiente no debería ser asumir que ya funciona.

Hay que verificar que Hermes la ha cargado.

Si nuestra versión dispone de herramientas de gestión o visualización de Skills, podemos utilizarlas para comprobar qué habilidades están disponibles y revisar su contenido.

También podemos iniciar una sesión limpia y realizar una petición que debería activar claramente nuestra nueva Skill.

Por ejemplo:

Revisa por qué el contenedor de mi aplicación Docker está fallando.

Si la descripción y las instrucciones están bien definidas, debería resultar razonable que Hermes utilice la habilidad correspondiente.

Cómo probar una Skill de Hermes Agent

Crear la Skill es solamente la mitad del trabajo.

La otra mitad es comprobar su comportamiento.

Una habilidad puede ser perfectamente válida desde el punto de vista del archivo y aun así no funcionar como esperábamos.

Por eso probaría varias situaciones.

Probar la condición de activación

Primero utilizo una petición que debería activar claramente la Skill.

Después pruebo otra que no debería activarla.

Si una habilidad dedicada a diagnosticar Docker aparece constantemente ante cualquier pregunta relacionada con servidores, quizá su descripción sea demasiado amplia.

Si nunca aparece, puede ser demasiado específica o poco clara.

Comprobar que usa las herramientas correctas

Después revisaría el procedimiento.

¿Está comprobando primero el estado?

¿Consulta los logs antes de sugerir cambios?

¿Está utilizando información real o saltándose pasos importantes?

Aquí podremos descubrir que nuestras instrucciones contienen ambigüedades.

Verificar el resultado

También deberíamos comprobar la respuesta final.

Si definimos que queremos:

• servicio afectado;
• estado;
• evidencia;
• posible causa;
• siguiente acción;

deberíamos verificar que Hermes devuelve realmente esa información.

Probar situaciones de error

Esta es probablemente la prueba más importante.

Podemos comprobar qué ocurre cuando:

• Docker no está disponible;
• el contenedor no existe;
• no hay permisos;
• los logs no aportan información;
• hay varios contenedores afectados;
• el nombre del servicio es ambiguo.

Cuando probamos estos escenarios empiezan a aparecer mejoras que nunca habríamos detectado probando únicamente el caso perfecto.

Mi Skill no funciona: errores frecuentes y cómo solucionarlos

Cuando una Skill no funciona, el problema no siempre está en Hermes.

Muchas veces aparece en la propia definición de la habilidad.

Hermes Agent no detecta la Skill

Lo primero que comprobaría es:

• ubicación del directorio;
• nombre del archivo;
• configuración de las rutas de Skills;
• formato del frontmatter;
• errores de sintaxis.

Un pequeño problema de estructura puede impedir que la habilidad se cargue correctamente.

Error en el frontmatter YAML

YAML puede ser especialmente sensible al formato.

Problemas de indentación, caracteres inesperados o estructuras incorrectas pueden hacer que el archivo no se interprete como esperamos.

Si la Skill deja de cargar después de modificar el frontmatter, empezaría revisando precisamente esa zona.

La Skill no se activa cuando debería

Aquí revisaría principalmente la descripción.

Puede que hayamos explicado bien lo que hace para una persona, pero no suficientemente bien el contexto en el que debe utilizarse.

Conviene utilizar términos relacionados directamente con el problema.

Por ejemplo, en nuestra Skill:

• Docker;
• contenedores;
• logs;
• diagnóstico;
• servicios.

Hermes ejecuta pasos distintos a los esperados

Esto suele indicar que las instrucciones dejan demasiado espacio a la interpretación.

Podemos mejorar:

• el orden de los pasos;
• las condiciones;
• los límites;
• el resultado esperado;
• las acciones que requieren confirmación.

Una frase como:

Haz las comprobaciones necesarias.

puede sustituirse por una secuencia mucho más concreta.

Faltan herramientas, variables o dependencias

Otra posibilidad es que el procedimiento esté bien, pero el entorno no disponga de lo necesario.

La Skill debería dejar claro qué dependencias necesita.

Por ejemplo, no tiene demasiado sentido pedirle que utilice Docker en un entorno donde el comando no existe.

La Skill funciona unas veces y otras no

Aquí revisaría dos cosas:

1. si la condición de activación es suficientemente clara;
2. si el procedimiento contiene instrucciones ambiguas.

Cuanto más crítico sea el orden de una tarea, más explícito conviene ser.

Buenas prácticas para crear mejores Skills

Después de crear varias Skills, probablemente terminemos desarrollando nuestro propio estilo.

Aun así, hay varias ideas que intentaría mantener.

Una Skill debería resolver una tarea concreta

Evitaría crear una habilidad llamada:

Administración completa de servidores.

Probablemente abarque demasiado.

Preferiría separar procedimientos:

• diagnóstico Docker;
• revisión de espacio en disco;
• actualización de una aplicación;
• comprobación de backups;
• análisis de logs.

Skills más concretas suelen ser más fáciles de activar correctamente, probar y mantener.

Escribe procedimientos, no instrucciones vagas

Esta es probablemente la regla más importante.

No escribiría:

Arregla el servidor.

Escribiría qué significa para mí investigar el problema antes de modificar nada.

Una Skill es especialmente útil cuando convierte nuestra forma de trabajar en pasos comprensibles.

Haz explícitas las comprobaciones

Si algo debe verificarse, lo escribiría.

Por ejemplo:

Después del cambio, comprueba que el servicio responde correctamente.

No asumiría que esa comprobación ocurrirá automáticamente.

Evita acciones destructivas innecesarias

Especialmente en Skills relacionadas con servidores, bases de datos, Docker o archivos.

Eliminar algo, modificar configuraciones o reiniciar servicios puede tener consecuencias.

Podemos enseñar a Hermes cuándo queremos diagnóstico, cuándo puede sugerir una acción y cuándo debe pedir confirmación.

Mantén tus Skills actualizadas

Las Skills son documentación ejecutable en cierto sentido.

Y como cualquier documentación, pueden quedarse obsoletas.

Si cambia:

• una herramienta;
• un comando;
• nuestro despliegue;
• una API;
• el procedimiento interno;

también deberíamos revisar la Skill correspondiente.

Las Skills como biblioteca de conocimiento operativo

Después de entender cómo funcionan, creo que aquí aparece una de las posibilidades más interesantes.

Podemos dejar de pensar en las Skills como automatizaciones aisladas y empezar a utilizarlas como una biblioteca de conocimiento operativo.

Imaginemos que tenemos procedimientos definidos para:

• desplegar una aplicación;
• revisar una incidencia;
• comprobar backups;
• investigar un servidor;
• preparar una actualización;
• analizar logs;
• revisar un repositorio;
• preparar determinados informes.

Normalmente este conocimiento termina repartido entre documentación, comandos guardados, notas personales y experiencia adquirida con el tiempo.

Parte de ese conocimiento puede trasladarse a Skills.

Por ejemplo, podríamos crear:

skills/
├── diagnose-docker/
├── deploy-production/
├── verify-backups/
├── inspect-server/
├── update-application/
└── review-git-repository/

Cada una resolvería un problema concreto.

Con el tiempo, Hermes dejaría de ser únicamente un agente genérico con acceso a determinadas herramientas.

Tendría también acceso a nuestra forma de utilizar esas herramientas.

Para mí, esta es una diferencia bastante importante.

No se trata solamente de darle capacidad para ejecutar git, Docker o comandos de shell.

Se trata de decirle:

Cuando hagamos esta tarea, quiero que trabajemos así.

Eso reduce la necesidad de repetir instrucciones y ayuda a convertir procedimientos habituales en conocimiento reutilizable.

Y cuanto mejor definidos estén, más fácil será mantener una forma de trabajo consistente.

Las Skills de los agentes de ia Hermes

Crear una Skill para Hermes Agent no tiene por qué convertirse en un desarrollo complicado.

Muchas veces ya disponemos de todas las herramientas técnicas necesarias.

Lo que necesitamos es enseñarle al agente qué procedimiento debe seguir.

Podemos empezar con algo tan sencillo como un archivo SKILL.md que explique:

• cuándo utilizar una habilidad;
• qué pasos seguir;
• qué herramientas emplear;
• qué errores tener en cuenta;
• qué acciones evitar;
• cómo verificar el resultado.

A partir de ahí podemos añadir requisitos, configuración o recursos adicionales según lo necesitemos.

También considero importante no intentar resolver todo mediante Skills.

Cuando una integración requiere autenticación compleja, procesamiento específico o un comportamiento técnico estrictamente controlado, una Tool puede ser una solución mejor.

La clave está en utilizar cada mecanismo para el problema adecuado.

En mi caso, lo que más me interesa de las Skills es que permiten pasar de tener un agente genérico a tener un agente progresivamente adaptado a nuestro entorno.

Podemos enseñarle cómo diagnosticamos Docker, cómo revisamos servidores, cómo trabajamos con Git o qué comprobaciones realizamos antes de tocar un servicio.

El verdadero potencial del agente no está solamente en lo que sabe hacer cuando lo instalamos.

También está en todo lo que podemos enseñarle después.

Y probablemente ahí esté una de las claves de este tipo de herramientas: no intentar que la IA lo haga todo de forma genérica, sino enseñarle exactamente cómo queremos que trabaje con nosotros.

Dudas de la comunidad

¿Qué es una Skill en Hermes Agent?

Una Skill es una forma de proporcionar a Hermes instrucciones y procedimientos reutilizables para realizar una tarea determinada utilizando las capacidades y herramientas disponibles en el agente.

¿Qué diferencia hay entre una Skill y una Tool?

Una Skill resulta especialmente adecuada cuando queremos enseñar un procedimiento utilizando herramientas existentes.

Una Tool suele tener más sentido cuando necesitamos añadir una capacidad técnica nueva, implementar una integración específica o controlar el comportamiento mediante código.

¿Dónde se guardan las Skills?

La ubicación depende de la configuración de Hermes. En instalaciones que utilizan la estructura habitual del usuario podemos encontrarnos con directorios dedicados a Skills, aunque conviene comprobar siempre la configuración y documentación de nuestra versión.

¿Puede una Skill ejecutar comandos de terminal?

Una Skill puede indicar cómo utilizar herramientas de terminal cuando ese tipo de ejecución está disponible en el entorno de Hermes.

Precisamente por eso son especialmente interesantes para procedimientos relacionados con Docker, Git, diagnóstico de servidores o scripts existentes.

¿Puede una Skill utilizar una API?

Puede formar parte de un procedimiento que utilice herramientas capaces de consultar una API.

Sin embargo, si necesitamos autenticación compleja, lógica específica o una integración fuertemente controlada, puede ser más adecuado desarrollar una Tool.

¿Cómo puedo probar si una Skill funciona?

Conviene comprobar al menos cuatro aspectos:

1. que Hermes detecta la Skill;
2. que se activa ante las peticiones adecuadas;
3. que sigue el procedimiento definido;
4. que responde correctamente cuando aparecen errores o situaciones inesperadas.

¿Se pueden compartir las Skills de Hermes Agent?

Al estar organizadas como habilidades reutilizables, pueden mantenerse de forma independiente y distribuirse cuando su estructura y dependencias lo permitan. Antes de compartir una Skill conviene eliminar información sensible y documentar claramente sus requisitos.

¿Cuándo debería crear una Tool en lugar de una Skill?

Cuando el problema deje de consistir principalmente en enseñar un procedimiento y empiece a requerir una capacidad técnica propia.

Si estamos implementando autenticación, procesamiento específico, lógica determinista o una integración compleja, probablemente deberíamos valorar una Tool.

Opinión Personal

Las Skills son una de las partes más interesantes de Hermes Agent porque permiten adaptar el agente a nuestra forma real de trabajar sin tener que convertir cada necesidad en un desarrollo complejo.

Lo que más valor les veo es precisamente su capacidad para transformar procedimientos que repetimos constantemente en instrucciones reutilizables. Si cada vez que aparece una incidencia tenemos que explicarle a Hermes qué logs revisar, qué comandos ejecutar o qué comprobaciones hacer antes de tocar un servicio, probablemente ese conocimiento debería convertirse en una Skill.

También me parece especialmente útil la separación entre Skill y Tool. No todo necesita código, una integración específica o una arquitectura más compleja. Muchas veces el agente ya dispone de las herramientas necesarias y simplemente necesita saber cómo queremos que las utilice.

Para mí, ahí está el verdadero potencial de este sistema: pasar de utilizar un agente genérico a construir poco a poco un asistente que conoce nuestros procedimientos, entiende nuestras prioridades y sabe cómo abordar las tareas que realizamos habitualmente.

Con el tiempo, una buena colección de Skills puede terminar convirtiéndose en una auténtica biblioteca de conocimiento operativo. Y creo que esa capacidad de enseñar al agente cómo queremos trabajar puede ser incluso más interesante que añadirle constantemente nuevas herramientas.

¿Tú ya estás utilizando Skills en Hermes Agent? ¿Qué tareas o procedimientos te gustaría automatizar? Cuéntamelo en los comentarios, porque seguro que pueden salir ideas muy interesantes entre todos.