Skills imprescindibles para tu agente IA

Llevo tiempo dándole vueltas a una idea que no termino de digerir. Tienes Ollama funcionando, has instalado Open WebUI, te has bajado un par de modelos, has hecho alguna pregunta y el asistente te contesta. Y entonces te quedas mirando la pantalla y piensas: vale, ¿y ahora qué? Porque sí, tu IA responde preguntas. Pero no hace cosas. No busca en internet, no lee tus archivos, no ejecuta comandos, no te manda un Telegram cuando acaba una tarea. Es como tener un ordenador con Linux pero sin comandos. Técnicamente funciona, pero no haces nada útil. En este episodio te voy a contar exactamente cómo vestir a tu agente IA, cómo darle habilidades para que pase de ser un loro caro a un asistente que hace cosas. Y lo mejor de todo es que todo es local, todo en tu máquina, con herramientas que ya tienes instaladas.

¿Qué es una skill para un agente IA?

Antes de meter manos al código, vamos a ponernos de acuerdo en qué diantres es una skill. Una skill (o habilidad) es un conjunto de instrucciones estructuradas que le dice a tu agente cómo hacer algo. No es un programa. No es un script. Es una receta de comportamiento.

Piénsalo así. Cuando le pides a tu agente busca en internet las últimas noticias sobre Rust, el modelo sabe lo que es buscar en internet porque tiene ese conocimiento general. Pero si le pides cada mañana, antes de las 9, revisa mi correo, extrae los emails importantes, y resúmelos en un mensaje de Telegram, ahí el modelo necesita una guía. Necesita saber qué considera importante, cómo estructurar el resumen, a qué chat de Telegram enviarlo. Eso es una skill.

La cuestión es que una skill no es ni más ni menos que un archivo, normalmente SKILL.md, con frontmatter YAML y un cuerpo en markdown que describe paso a paso el procedimiento. El agente lo descubre automáticamente y lo carga bajo demanda. Cuando el contexto de la conversación coincide con la descripción de una skill, el agente la carga y la aplica sin que tengas que decirle carga la skill tal. Es como tener un cinturón de herramientas que el agente mismo decide cuándo usar.

Detrás de todo esto está el function calling (tool calling), un estándar implementado por OpenAI, Anthropic, Google y la mayoría de proveedores de LLM. El flujo es sencillo: el desarrollador define herramientas con nombre, descripción y esquema JSON de parámetros, el modelo recibe el prompt más la lista de herramientas disponibles, y si determina que necesita una herramienta, devuelve un tool_call con el nombre y los argumentos. La aplicación ejecuta la función y devuelve el resultado al modelo. Este mecanismo es el motor que permite que las skills funcionen, pero no te preocupes por los detalles internos ahora, que ya los veremos en episodios posteriores.

Skills más scripts: el matrimonio perfecto

Una de las cosas que más me ha cambiado el flujo de trabajo es entender que una skill puede incluir scripts. De hecho, mi método actual consiste en crear una skill para hacer algo y, una vez que la tengo, dejar que la IA genere los scripts que necesita. Pero ojo, no es tan inmediato como parece.

Te pongo un ejemplo. Cuando le dices a tu agente que cree una skill para buscar cosas en internet, lo primero que hace es generar un pequeño script en Python para hacer la búsqueda. Al día siguiente, cuando le vuelves a preguntar lo mismo, se vuelve a crear el mismo script en Python. Y al otro día, otra vez. Es un ciclo infinito de reinvención de la rueda.

La solución es sencilla: una vez que has visto su comportamiento, guardas el script para reutilizarlo más tarde. Y no solo eso, sino que le dices al agente que documente lo aprendido. Cada sesión de trabajo con un skill, cada vez que modificas algo, cada error que encuentras, le dices de todo lo que has hecho con este skill, de todo lo que has aprendido, guárdalo. Así el skill evoluciona, se vuelve más preciso, más robusto.

Esto es lo que convierte una skill básica en una herramienta realmente potente. No es solo que el agente sepa hacer algo, es que cada vez lo hace mejor porque tiene memoria de sus propios errores y aciertos.

La estructura de una skill

Una skill es un archivo con una estructura muy definida. Tiene una parte de metadatos (nombre, descripción, versión, autor, permisos) y luego el cuerpo con el procedimiento. En OpenCode, las skills viven en ~/.config/opencode/skills/<nombre>/SKILL.md. En Hermes Agent, en ~/.hermes/skills/<nombre>.md. Pero yo te recomiendo un enfoque más通用.

Yo personalmente guardo todas mis skills en ~/.agents/skills/. ¿Por qué? Porque la mayoría de los agentes —OpenCode, Hermes, OpenCloud, Claude Code— saben buscar ahí por defecto. Así, con independencia del agente que esté utilizando, los skills los tengo concentrados en un solo sitio. Es una decisión que tomé después de tener skills desperdigadas por tres directorios distintos y no recordar dónde había puesto cada cosa.

La estructura básica del frontmatter YAML incluye campos como name, description, version, author, license, category, tags y, muy importante, permissions. Los permisos son los que definen qué puede y qué no puede hacer esa skill. Y créeme, esto es fundamental.

Skills del sistema: que tu agente toque el sistema de archivos

La primera categoría de skills que necesitas son las que conectan a tu agente con el sistema operativo. Porque un agente que no puede leer archivos, escribir archivos o ejecutar comandos es un agente manco.

Empieza por lo básico: lectura de archivos. Tu agente necesita poder inspeccionar ficheros de configuración, logs, documentos. En OpenCode esto viene por defecto con las herramientas read, write, glob, grep. En Hermes Agent, el toolset file te da acceso al sistema de archivos. Pero ojo, y esto es importante, no le des acceso total al sistema sin control. Una skill bien hecha especifica qué archivos puede leer y dónde puede escribir. Por ejemplo, una skill para revisar logs de Nginx no necesita acceso a /etc/shadow.

La segunda skill de sistema imprescindible es la ejecución de comandos. Que tu agente pueda ejecutar systemctl status, df -h, docker ps, journalctl --since "1 hour ago". Esto convierte a tu agente en un administrador de sistemas que trabaja para ti. Pero aquí el riesgo es alto. Una skill de terminal mal escrita puede ejecutar comandos peligrosos. Por eso tanto OpenCode como Hermes tienen un sistema de permisos granular. Puedes permitir ciertos comandos y denegar otros.

Fíjate en este ejemplo de skill de sistema que uso a diario. Es la skill command-exec, que permite comandos de diagnóstico pero deniega explícitamente comandos destructivos:

---
name: command-exec
description: Ejecuta comandos de administración del sistema de forma segura
version: 1.0.0
author: atareao
category: sistema
tags:
  - administracion
  - monitoreo
  - terminal
permissions:
  terminal:
    allowed_commands:
      - "systemctl status *"
      - "df -h"
      - "free -h"
      - "uptime"
      - "journalctl --since *"
      - "docker ps"
      - "ss -tuln"
    denied_commands:
      - "rm -rf *"
      - "shutdown"
      - "reboot"
      - "systemctl stop *"
---

Fíjate en los permisos: solo comandos específicos, con patrones glob. No es ejecuta lo que quieras. Es ejecuta solo esto. Así mantienes el control. Y los comandos denegados son casi más importantes que los permitidos. Si no le dices explícitamente que no puede ejecutar rm -rf, el agente podría interpretar que sí puede hacerlo en según qué contexto.

La tercera skill de sistema es la navegación por el sistema de archivos. Que tu agente pueda hacer ls, find, du, saber qué hay en cada directorio. Esto es especialmente útil cuando tienes un servidor con años de historia y no recuerdas dónde dejaste aquel script.

Skills de búsqueda: que tu agente encuentre lo que necesita

Vale, tu agente ya puede leer archivos y ejecutar comandos. Ahora necesita encontrar información. Aquí entran las skills de búsqueda, y hay tres tipos que no pueden faltar.

Búsqueda web

La primera es la búsqueda web. Que tu agente pueda hacer consultas a internet. Sin esto, tu agente solo sabe lo que sabe su modelo, y los modelos tienen fecha de corte. Si le preguntas ¿qué versión de Go se publicó ayer?, sin búsqueda web no tiene ni idea.

Yo utilizo SearXNG, un metabuscador autohosteado que tengo montado en mi Slimbook One. La ventaja de SearXNG frente a otras opciones es que es un metabuscador: no tiene su propio índice, sino que consulta múltiples motores de búsqueda (Google, Bing, DuckDuckGo, Yahoo, etc.) y agrega los resultados. Esto significa que no dependes de un solo proveedor y, además, respeta tu privacidad porque no compartes tu dirección IP ni tus datos con los buscadores directamente.

Pero la verdadera ventaja para un agente IA es que SearXNG devuelve los resultados en formato JSON. Esto hace que las búsquedas sean rapidísimas porque el agente no tiene que parsear HTML ni hacer screen scraping. Recibe los datos estructurados y puede procesarlos al instante. Además, puedes configurar qué motores consultar, cuántos resultados devolver, y hasta filtrar por dominio o por tipo de contenido.

En Hermes Agent, la búsqueda web se activa con el toolset web. En OpenCode, puedes configurar un MCP de búsqueda como Tavily o DuckDuckGo. Pero mi recomendación es que te montes tu propio SearXNG, porque además de ser más privado, tienes control total sobre cómo se hacen las búsquedas.

Búsqueda local con ripgrep

La segunda es la búsqueda en documentos locales. Esto es RAG básico (Retrieval Augmented Generation) pero sin complicaciones. Tu agente necesita poder buscar en tus notas, en tu documentación técnica, en tus guías. No necesitas un sistema complejo. Una skill que use ripgrep sobre tus directorios de notas ya te da un 80% de lo que necesitas.

Ripgrep (rg) es una herramienta de búsqueda recursiva de texto escrita en Rust. Es increíblemente rápida, mucho más que grep tradicional. ¿Por qué? Porque está optimizada para ignorar directorios que no te interesan (como .git, node_modules), respeta las reglas de .gitignore por defecto, y usa paralelismo para buscar en varios archivos a la vez. En mis pruebas, rg es entre 5 y 10 veces más rápido que grep -r para búsquedas en directorios grandes.

La skill de búsqueda local que tengo configurada permite a mi agente buscar en mis notas y documentos con ripgrep, usando opciones como contexto de 3 líneas alrededor de cada coincidencia, búsqueda insensible a mayúsculas, y filtrado por tipo de archivo:

---
name: local-search
description: Busca en documentos y notas locales usando ripgrep
version: 1.0.0
author: atareao
category: busqueda
tags:
  - ripgrep
  - notas
  - documentos
permissions:
  terminal:
    allowed_commands:
      - "rg --no-heading -n *"
      - "rg -l *"
      - "rg -C 3 *"
      - "rg -i *"
      - "rg -t md *"
      - "rg -t py *"
  file:
    allowed_paths:
      - "/home/*/Notas"
      - "/home/*/Documentos"
---

El procedimiento es sencillo: el agente pregunta al usuario qué busca, busca primero en ~/Notas con rg -n -C 3 -i "término", y si no hay resultados, amplía a ~/Documentos. Si hay muchos resultados, pide al usuario que refine la búsqueda. Sencillo, efectivo, y no necesitas montar una infraestructura compleja.

Búsqueda semántica

La tercera es la búsqueda semántica. Aquí ya entramos en terreno más avanzado. En lugar de buscar por palabras clave, buscas por significado. Usas embeddings para encontrar fragmentos relacionados aunque no contengan las mismas palabras. Esto es lo que hace que tu agente entienda contexto, no solo coincidencias.

Para búsqueda semántica local, herramientas como sqlite-vec (una extensión vectorial para SQLite escrita en C puro, sin dependencias) te permiten indexar tus documentos y buscar por similitud. No necesitas una GPU para esto. Un modelo de embeddings pequeño como all-MiniLM-L6-v2 funciona perfectamente en CPU.

Y aquí un consejo que he aprendido a base de prueba y error: no intentes hacer búsqueda semántica sobre todo tu disco. Indexa solo lo que realmente necesitas: tus notas, tu documentación técnica, tus guías. Un índice bien curado de 500 documentos es mucho más útil que un índice gigante con ruido.

La diferencia entre RAG y GraphRAG es interesante. El RAG tradicional (Retrieval Augmented Generation) busca fragmentos de texto por similitud vectorial y los pasa al modelo como contexto. GraphRAG, por otro lado, construye un grafo de conocimiento a partir de los documentos, conectando entidades y relaciones, y luego navega ese grafo para encontrar información relevante. GraphRAG es más potente para preguntas que requieren conectar conceptos de varios documentos, pero también es más complejo de configurar y consume más recursos. Para el 80% de los casos, el RAG tradicional con SQLite y embeddings te sobra.

Skills de automatización: que tu agente trabaje mientras duermes

Esto es lo que separa un juguete de una herramienta de producción: la automatización. Que tu agente haga cosas sin que se lo pidas.

En Hermes Agent, esto se hace con cron jobs. Sí, como el cron de Linux pero integrado en el agente. Puedes programar tareas para que se ejecuten a una hora determinada, con un perfil concreto, y que el resultado se envíe a un destino específico. Mira este ejemplo de configuración:

hermes:
  cron:
    jobs:
      resumen-diario:
        schedule: "0 8 * * 1-5"
        profile: automata
        action: >
          Revisa el estado del servidor, comprueba los logs de las últimas
          24 horas, y genera un resumen de incidencias.
        destination: "telegram:3970104"
        toolsets:
          - terminal
          - file
      backup-nocturno:
        schedule: "0 3 * * *"
        profile: automata
        action: >
          Ejecuta el script de backup en /usr/local/bin/backup.sh.
          Si el backup falla, notifica inmediatamente.
        destination: "telegram:3970104"
        toolsets:
          - terminal

Fíjate en el campo destination. Puedes enviar el resultado a Telegram, Discord, Slack, email, o incluso a un archivo local. Esto convierte a tu agente en un sistema de alertas inteligente.

Pero la automatización no es solo cron. También son webhooks. Tu agente puede escuchar eventos externos. Cuando haces push a un repositorio, cuando un monitor de uptime detecta una caída, cuando recibes un email importante, el webhook dispara una acción del agente.

Un webhook no es más que una URL a la que un servicio externo hace una petición HTTP cuando ocurre un evento. Tu agente escucha en un puerto (por ejemplo, el 9090) y cuando recibe la petición, ejecuta la acción configurada. Es como tener un asistente que está siempre atento a lo que pasa en tus servicios.

Y luego están los scripts orquestados. Tu agente puede ejecutar scripts Bash, Python, Rust, cualquier cosa que tengas en tu sistema. La clave está en que el script no necesita ser complejo. Un script de 10 líneas que hace una copia de seguridad, otro que comprueba el espacio en disco, otro que actualiza los contenedores Docker. Luego el agente los orquesta.

Imagina esto: cada noche a las 3 AM, tu agente ejecuta un script que hace backup de tus bases de datos, luego otro que comprueba que los backups son válidos, luego te envía un mensaje a Telegram con el resultado. Y si algo falla, te despierta. Todo sin que muevas un dedo. Eso no es futuro. Eso es ahora. Con una skill bien escrita y un cron job, lo tienes funcionando en 15 minutos.

Skills de comunicación: que tu agente hable contigo

Un agente que trabaja pero no te cuenta lo que ha hecho es un agente que no sirve. Necesitas skills de comunicación.

Telegram es mi favorita. Configuras un bot de Telegram con BotFather, le das el token a tu agente, y ya puedes recibir mensajes, hacer consultas desde el móvil, y recibir alertas. En Hermes Agent, el gateway de Telegram está integrado. Configuras el bot en el config.yaml y listo.

¿Qué significa esto en la práctica? Que puedes hablar con tu agente desde el móvil. Le preguntas ¿cuánto espacio libre tengo en el servidor? y él ejecuta df -h y te responde. O le dices recuérdame mañana a las 10 que tengo reunión y él programa un cron job. La API de Telegram es HTTP-based, así que un simple curl basta para enviar mensajes:

curl -X POST https://api.telegram.org/bot<TOKEN>/sendMessage \
  -d "chat_id=3970104" \
  -d "text=Backup completado correctamente"

Luego está el email. Tu agente puede enviar y recibir correos. Esto es útil para tareas más formales: envía un resumen semanal a mi jefe, responde a este email con los datos actualizados, archiva los correos de más de 30 días. No necesitas un cliente de correo. El agente hace de intermediario.

Y las notificaciones locales. No todo tiene que ir a Telegram. A veces solo quieres que tu agente te muestre una notificación en el escritorio. Con notify-send en Linux, o con herramientas como ntfy, puedes recibir alertas locales. Una skill que ejecute notify-send "Backup completado" "Se han copiado 15GB correctamente" es simple pero efectiva.

Pero hay un detalle de seguridad que me parece brillante: el Tool Gateway. En Hermes Agent, puedes configurar qué toolsets están disponibles según desde dónde te conectes. Desde Telegram, solo web y search —nada de terminal, nada de archivos. Desde el escritorio local, todos los toolsets. Esto es seguridad en capas: si alguien intercepta tu Telegram, no puede ejecutar comandos en tu servidor.

hermes:
  gateway:
    telegram:
      "*":
        toolsets:
          - web
          - search
    local:
      "*":
        toolsets:
          - web
          - search
          - terminal
          - file
          - browser

Crea tus propias skills: las tres reglas de oro

Vale, ya has visto qué skills existen. Ahora te enseño a crear las tuyas. Porque las skills más útiles son las que escribes para ti, para tu flujo de trabajo, para tus problemas concretos.

La estructura de una skill es simple. En OpenCode, un archivo SKILL.md con frontmatter YAML y cuerpo en markdown. En Hermes Agent, lo mismo pero con extensión .md directamente. Pero la clave no está en el formato, está en cómo escribes las instrucciones.

Regla 1: Sé específico

No escribas revisa el sistema. Escribe ejecuta systemctl status --failed, si hay servicios fallidos, lista sus nombres y el motivo del fallo, luego intenta reiniciarlos con systemctl restart. El agente necesita instrucciones claras, no vaguedades.

Mira la diferencia:

Mal:

Revisa el sistema y dime si todo está bien.

Bien:

1. Ejecuta `systemctl status --failed` — si hay servicios fallidos,
   lista sus nombres y el motivo del fallo.
2. Ejecuta `df -h /` — si el uso de disco supera el 80%, marca alerta.
3. Ejecuta `free -h` — si la RAM usada supera el 90%, marca alerta.
4. Presenta los resultados en formato tabla con emojis de estado.

Cuanto más específico seas, más preciso será el resultado. Y después de probar la skill, documenta los errores para que no vuelvan a suceder. Le dices al agente has visto todos los errores que se han producido, con todo esto documéntalo para que la próxima vez no vuelva a suceder.

Regla 2: Define los límites

¿Qué archivos puede tocar? ¿Qué comandos puede ejecutar? ¿Qué APIs puede llamar? Si no defines los límites, el agente los interpretará por su cuenta, y no siempre acertará.

Lo que no puede hacer es casi tan importante como lo que puede hacer. Por ejemplo, si no quieres que cada vez que realice modificaciones en tu código compile, tienes que decírselo explícitamente. Yo lo pongo en mayúsculas para que no se le pase por alto: NO COMPILES DESPUÉS DE MODIFICAR EL CÓDIGO.

permissions:
  terminal:
    allowed_commands:
      - "systemctl status *"
      - "df -h"
      - "journalctl --since *"
    denied_commands:
      - "rm -rf *"
      - "shutdown"

Regla 3: Incluye ejemplos

Los modelos entienden mejor cuando ven un ejemplo. Si tu skill es para formatear respuestas, incluye un antes y un después. Si es para buscar en logs, incluye un ejemplo de búsqueda y su resultado esperado.

Ejemplo de petición del usuario:

"¿Hay algún problema en el servidor?"

Ejemplo de respuesta esperada:

📊 Estado del servidor — 29/08/2026 15:42
├── Carga:    0.5, 0.3, 0.2 (normal)
├── Memoria:  2.1G / 15.6G (13% — ✅ ok)
├── Disco:    120G / 250G (48% — ✅ ok)
├── Servicios: 0 fallidos ✅
└── Errores:   2 no críticos (permisos, no impacto)

Con estas tres reglas ya tienes algo fundamental para que todo ruede mucho mejor.

Procedimiento paso a paso y formato de salida

Además de las tres reglas, hay dos cosas más que marcan la diferencia. La primera es definir un procedimiento paso a paso. No le digas diagnostica el sistema, dile ejecuta un journalctl, ejecuta un systemctl status y revisa los servicios fallidos, ejecuta docker ps y dime los contenedores no saludables, genera un resumen estructurado de los errores críticos.

La segunda es definir el formato de salida. Dile exactamente cómo quieres que te dé la información. Quiero que me des la información en una tabla donde en la primera columna se vea si es un problema de red, un problema de almacenamiento o es un problema de cualquier otra cosa. En la segunda columna que me digas el servicio afectado. Si le dices el formato, todo funciona y todo fluye mucho mejor.

El ecosistema de skills: OpenCode, Hermes y más allá

Hasta ahora hemos visto skills como conceptos. Pero hablemos de los ecosistemas reales donde vas a usarlas.

OpenCode tiene un sistema de skills muy maduro. Los skills viven en directorios con SKILL.md, y el agente los descubre automáticamente. Puedes tener skills globales en ~/.config/opencode/skills/ y skills por proyecto en .opencode/skills/. Los skills por proyecto tienen prioridad sobre los globales. OpenCode además tiene un hub de skills, un repositorio comunitario donde la gente publica sus skills. Puedes buscar, instalar y publicar skills. Es como el npm de las habilidades de IA.

# En OpenCode: gestionar skills
opencode skill list
opencode skill install rust-review
opencode skill publish mi-skill
opencode skill create mi-skill

Hermes Agent tiene un enfoque similar pero con algunas diferencias. Los skills son archivos .md individuales en ~/.hermes/skills/. Hermes además tiene el concepto de niveles de divulgación: el nivel 0 es solo el índice (nombre + descripción), que se carga siempre en el prompt del sistema. El nivel 1 es el contenido completo, que se carga bajo demanda. Y el nivel 2 son archivos de referencia específicos dentro del skill.

Esto es importante porque el espacio en el prompt es limitado. No puedes cargar 50 skills completos en cada conversación. El sistema de niveles permite que el agente tenga un mapa de lo que sabe y cargue solo lo que necesita.

# En Hermes Agent: gestionar skills
hermes skill list
hermes skill view nombre
hermes skill install nombre
hermes skill create nombre
hermes skill enable nombre
hermes skill disable nombre

Y luego está el Model Context Protocol (los MCPs) que son como skills pero a nivel de protocolo. Los MCPs conectan al agente con fuentes de datos externas: GitHub, bases de datos, sistemas de archivos, APIs. Skills y MCPs son complementarios. Las skills le dicen al agente cómo hacer algo. Los MCPs le dan acceso a datos externos. Los dos juntos son la combinación ganadora.

Demo rápida: monta tu primera skill en 5 minutos

Vamos a hacerlo real. Te voy a enseñar a montar tu primera skill en menos de 5 minutos. Abre tu terminal.

# 1. Crea el directorio de skills (si no existe)
mkdir -p ~/.config/opencode/skills/health-check

# 2. Crea el archivo SKILL.md
cat > ~/.config/opencode/skills/health-check/SKILL.md << 'EOF'
---
name: health-check
description: Comprueba la salud del sistema en un solo comando
version: 1.0.0
permissions:
  terminal:
    allowed_commands:
      - "uptime"
      - "free -h"
      - "df -h /"
      - "ss -tuln"
---
Ejecuta estos comandos en orden y presenta los resultados en formato tabla:

1. `uptime` — tiempo de actividad y carga
2. `free -h` — memoria RAM y swap
3. `df -h /` — espacio en disco de la raíz
4. `ss -tuln` — puertos abiertos

Si algún valor supera el 80% de uso (disco o RAM), marca una alerta.
EOF

# 3. Verifica que OpenCode la detecta
opencode skill list | grep health-check

Ya está. Tienes tu primera skill funcionando. La próxima vez que le pidas a tu agente que revise el estado del sistema, cargará esta skill y seguirá el procedimiento.

Si usas Hermes Agent, es aún más directo:

hermes skill create health-check
# Esto te genera el archivo ~/.hermes/skills/health-check.md
# Lo editas con tu contenido y lo activas:
hermes skill enable health-check

Un ejemplo real: la skill del tiempo

Para que veas el potencial, te pongo un ejemplo que uso cada semana. Tengo una skill llamada weather que, cuando le digo dime la previsión meteorológica de Valencia para la próxima semana, activa un script en Bash que consulta una API meteorológica y me da el pronóstico directamente. Sin tener que crear un script en Python cada vez, sin reinventar la rueda.

El script en Bash está implementado para que haga exactamente esto: consultar la API, parsear los datos y devolver un pronóstico legible. El agente no se tiene que calentar la cabeza creando código cada vez que le pregunto por el tiempo. Simplemente ejecuta el script y me da la respuesta.

Esto es lo que hace que las skills sean tan poderosas. No es solo que el agente sepa hacer algo, es que lo hace de forma consistente, rápida y sin errores, porque el procedimiento ya está definido y probado.

Un agente sin skills es como un Linux sin comandos

Vale. Hemos cubierto mucho terreno. Skills de sistema, de búsqueda, de automatización, de comunicación. Cómo crearlas, cómo gestionarlas, dónde encontrarlas.

Pero quiero que te quedes con una idea, una sola, la más importante de todo el episodio:

Un agente sin skills es como un Linux sin comandos.

Técnicamente funciona. Tienes un kernel, tienes un shell, tienes un sistema operativo completo. Pero sin comandos (sin ls, sin cd, sin grep, sin systemctl) no puedes hacer nada útil. Es un sistema en teoría, no en práctica.

Con tu agente pasa exactamente lo mismo. Puedes tener el mejor modelo del mundo —DeepSeek V4, Claude Opus 4.7, Gemini 3.1— pero si no le das herramientas para actuar, solo te va a devolver texto bonito. Y texto bonito está bien para según qué cosas, pero no para administrar un servidor, no para automatizar tareas, no para construir un sistema de alertas.

Las skills son los comandos de tu agente. Son lo que transforma un modelo de lenguaje en un asistente real.

Y lo mejor de todo es que no necesitas ser un programador para crear skills. Necesitas saber qué quieres que haga tu agente, y ser capaz de describirlo paso a paso. El resto lo hace el propio modelo. Le dices crea una skill para hacer X y él te genera el archivo. Luego lo ajustas, lo pruebas, lo pones a funcionar. Es un ciclo de ajustar, probar, ajustar, probar. Empiezas con una skill pequeña y luego poco a poco vas guardando y mejorándola incrementalmente.

Empieza con una skill pequeña. Una que haga una cosa bien. La que más necesites en tu día a día. Para mí fue la de estado del sistema. Para ti puede ser la de buscar en tus notas, o la de enviar recordatorios a Telegram, o la de revisar logs de Docker.

Una skill. Una sola. Pruébala durante una semana. Cuando veas que funciona, crea otra. Y otra. Al cabo de un mes, tu agente hará más cosas por ti de las que tú mismo harías en ese tiempo.

Y eso, oyente, es el verdadero poder de la IA local. No es tener un modelo que responda preguntas. Es tener un asistente que hace cosas. Que trabaja mientras duermes. Que te avisa cuando algo falla. Que busca información cuando la necesitas.

Eso es una skill. Y eso es lo que separa un juguete de una herramienta.

---

Más información

• OpenCode — Agent Skills Documentation — Documentación oficial del sistema de skills de OpenCode
• Hermes Agent — Skills Overview — Documentación oficial de skills en Hermes Agent
• OpenAI — Function Calling Guide — Guía oficial de function calling, el mecanismo subyacente de las skills
• SearXNG — Metabuscador autohosteado — Documentación oficial del metabuscador privado
• ripgrep (rg) — GitHub — Repositorio oficial de ripgrep, búsqueda ultrarrápida en archivos
• sqlite-vec — Vector Search SQLite Extension — Extensión vectorial para búsqueda semántica local con SQLite
• Telegram Bot API Documentation — API oficial de bots de Telegram
• systemd.timer Manual — Documentación de systemd timers, alternativa a cron
• Episodio 796: Las Skills — Episodio anterior donde introduje el concepto de skills
• ntfy — Notificaciones push desde terminal — Herramienta para enviar notificaciones push desde línea de comandos