Hermes Agent: la guía práctica (CLIs, skills, crons, kanban)

En el vídeo anterior instalé Hermes en un VPS como root. Una hora entera de vídeo. Usuario dedicado, sudoers, securización: la parte técnica, en detalle.

Este es distinto. Esta es la guía práctica: cómo lo uso de verdad, cada día.

Y si te quedas con una sola cosa de este artículo, que sea el orden de las capas:

VPS → CLIs → skills → board.

Si te saltas los CLIs, todo lo que va encima cojea. Vuelvo a ello.

La instalación, versión corta

La instalación root ya la hice en vídeo. Lleva más de una hora si quieres dejarla bien configurada y segura. Si quieres ese nivel de detalle, está en este artículo.

Pero para mis pruebas y mis vídeos uso la instalación gestionada. En dos clics.

La idea: coges un VPS, vas al catálogo de aplicaciones Docker, buscas Hermes Agent y tienes una instancia preconfigurada. Un KVM 2 basta de sobra para mover este tipo de agente.

Dos cosas que anotar al desplegar:

• El nombre de usuario (hermes) y la contraseña de admin. Si se te olvidan, tranquilo: están en las variables de entorno del proyecto.
• Dos formas de entrar: la terminal directamente en el navegador, o por SSH como siempre si eres algo más geek.

Conecta un modelo, si no no haces nada

Mientras no tengas un modelo conectado, Hermes no sirve de nada. Es lo primero que hay que hacer en una instancia nueva.

Tienes algo de crédito inicial con un modelo por defecto, pero se agota rápido. Yo conecto mi suscripción.

hermes model

Puedes lanzarlo por SSH o pasar por el dashboard: funcionan los dos. En mi caso conecto Codex CLI por OAuth, lo que me permite usar mi suscripción de ChatGPT en lugar de pagar por llamada. Recuperas un código, lo pegas y listo.

Me quedo en GPT-5.5 aunque ya esté la 5.6, simplemente para no quemar demasiados tokens.

⚠️ Lo importante sobre Claude. No puedes usar tu suscripción de Claude como chatbot dentro de Hermes. Puedes ir por la API, pero sale caro. La solución real es delegar en Claude Code — lo explico más abajo.

Las tres interfaces

A Hermes se llega de tres formas, y no sirven para lo mismo.

La Web UI no viene instalada de serie. Puedes ir por el catálogo o —lo que hice yo— pedírselo. Le di el enlace de la documentación y se la instaló solo.

Dos trampas, eso sí:

1. La instala en interno. Hay que pedirle explícitamente que la exponga para poder acceder desde fuera. Y no lo pilla a la primera: te dirá que está arrancada, porque desde su punto de vista es cierto. Necesitas tener clara la diferencia entre IP interna e IP externa para saber qué pedirle.
2. Dos ajustes siguen siendo manuales: abrir el puerto 8787 en el editor YAML del Docker, y añadir una regla de firewall que permita tráfico TCP/UDP en ese puerto.

Un último detalle: no todos los comandos existen en los tres entornos. Conviene saberlo antes de pasar diez minutos buscando un comando que no está disponible donde estás.

Los comandos que debes conocer

Empieza por /help. Hay un buen montón, y es el comando que tienes que dominar.

Los que uso de verdad:

• /personality — cambiar de personalidad. Técnica, creativa, teacher, pirata… puedes definir las tuyas. Es algo divertido, pero está bien.
• /rollback — volver atrás sobre archivos. El equivalente al rewind de Claude Code.
• /steer — corregir sin interrumpir. Está analizando logs, le cuelas una segunda instrucción y la integra sin romper la primera. Muy útil.
• /learn — lo que acabas de hacer se convierte en un skill. Trabajas sobre la arquitectura de un proyecto, haces /learn y se la queda.
• /suggest — te dice qué automatizar.

Además tienes todo lo de sesiones (new, clear, history, save, retry, undo, title, ramas) y el resto: kanban, memoria, crons, skills, plugins, tools.

Los CLIs: las manos de tu agente

Es la parte que todo el mundo se salta. Es la más importante.

Un CLI es una mano que le das a tu agente. Sin manos intenta esquivar el problema, y no se le da bien.

La demo lo dice todo. Le pido lo mismo a dos instancias: «lístame los proyectos de mi repo de GitHub».

• Sin el CLI gh: da vueltas, prueba con HTTP, improvisa scripts y devuelve una lista completamente desviada que no tiene nada que ver con lo que pedí.
• Con gh: unos segundos, todos mis repos. Y desde ahí puede abrir pull requests, mirar las últimas revisiones, los despliegues, los commits, las ramas.

Lo mismo con los transcripts de YouTube. Sin yt-dlp se lanza a un fetch improvisado y se pierde. Con él, le digo «recupérame los SRT» y me da el archivo.

Los CLIs que tengo instalados:

Sobre Google Workspace en particular: configurar autenticaciones, dominios y servidores a mano es extremadamente pesado. Los agentes lo hacen muy bien.

Los skills solo son eficaces si debajo están los CLIs adecuados. Primero los CLIs, los skills encima.

Y un punto que va a contracorriente: uso cada vez menos MCP y cada vez más CLIs. El reflejo a coger es buscar un SaaS que tenga API y darle la documentación de la API al agente. Sin MCP.

Bonus si vienes de OpenClaw: tus skills se importan y funcionan casi de inmediato. Así recuperé mi skill de Google Calendar, Gmail, mi brief matinal, mis newsletters, mi vigilancia tecnológica y mi deep research.

Mis casos de uso

Los casos de uso son tu negocio. Son infinitos: dependen de tu actividad y de tu creatividad. Estos son los míos, para que te hagas una idea de cómo queda en real.

Los crons

Tres corren a diario en mi setup:

• El brief de la mañana. Tiempo, calendario, tareas en curso, emails importantes. Llega por email y por Telegram.
• La vigilancia tecnológica. Un top 3, las salidas del día, recibido en Telegram y WhatsApp, y formateado por email. Incluso termina con una recomendación de contenido que puedo seguir o no.
• La auditoría de seguridad. Un skill que lanza pnpm audit, Trivy y Snyk, y luego llega hasta el pen test. Si sale algo, me avisa automáticamente. No tengo que pensarlo: es proactivo.

Para crear un cron: se lo prompteas, o pasas por el dashboard (fecha, prompt, skill de referencia, canal de entrega, perfil, modelo).

El soporte por email — inbox cero

Uso Front. El agente trata lo que entra cada día:

• El spam, lo archiva solo.
• Los acuses de recibo (gente que responde «ok, recibido» a la newsletter), los contesta solo.
• Las peticiones de recursos, prepara el email — pero lo deja en borrador. No lo envía.
• Las colaboraciones, las analiza y les pone una nota sobre 5. Yo miro, y si no me gusta dejo un comentario mencionándolo: «eliminar» o «responder». Él se encarga después.

Sustituyó un puesto de asistente. Antes todo acababa en la papelera. Mi agente lo hace mejor.

Construir features con Claude Code

No puedes usar tu suscripción de Claude como chatbot en Hermes. Pero sí puedes instalar el CLI de Claude Code en el VPS y delegarle el desarrollo.

Anthropic iba a cortar este uso el 15 de junio. Dieron marcha atrás: está incluido al 100 % en los planes Pro y Max. Así que puedes exprimir tu suscripción, con los últimos modelos.

Mi skill build-feature encadena:

1. Prerrequisitos — comprobar que el repo no está en mal estado
2. Rama + worktree — el desarrollo va aparte, lo que permite lanzar varias features en paralelo
3. Implementación
4. Verificación — test, build
5. Commit
6. Pull request en GitHub (así que, otra vez: hace falta gh)
7. Informe, enviado directamente

Con una regla crítica: nunca commit en main, master o dev. Siempre en una rama aparte.

Lo uso para cosas acotadas. Un bug identificable en mi SaaS, un cambio de etiqueta, algo en lo que confío razonablemente. Le dejo trabajar, leo la pull request y si cuadra hago merge — directo a producción.

Al principio da un poco de miedo dejar que un agente programe, haga commit, push y abra PRs. Pero si está bien encuadrado, si tus skills están bien hechos y dominas tu arquitectura, puedes hacer más del 50 % del desarrollo así. El resto —lo realmente complejo— lo desarrollas en local con Claude Code. Sigue siendo la mejor forma de programar.

La investigación profunda

Mi caso de uso favorito, de lejos.

Tres fuentes conectadas:

• Brave Search API para la búsqueda web. La versión gratuita basta de sobra para empezar.
• Jina para leer posts en X (si no, hay que pagar la API). Funciona una de cada dos veces, pero es mejor que nada.
• Supadata para los transcripts de vídeos de YouTube, con yt-dlp como fallback si falla.

El workflow del skill:

1. Encuadre — reformula mi petición y pregunta si algo está difuso
2. Exploración amplia con Brave — se queda con las 5 a 10 URLs más relevantes
3. Lectura en profundidad — páginas, posts de X y los vídeos de YouTube que encuentre: lee los transcripts y los interpreta
4. Síntesis

Por qué es mi favorito: llevo más de siete años creando contenido. Durante años recogía los datos a mano, los guardaba en mi rincón y hacía yo mismo las síntesis.

Ahora puedo estar con el móvil, lanzarle una idea que se me acaba de ocurrir, y me lo compila todo. Después soy yo quien decide si merece un contenido o no. Pero tengo la materia prima.

Los visuales

No prompteo mis esquemas a lo loco cada vez. Todo está en skills, con plantillas, tipografía y colores definidos de una vez por todas.

• Nano Banana — dos temas, un catálogo de layouts: fan out, kanban, timeline horizontal, escena interactiva
• Excalidraw — generado y luego compartido directamente en Supabase, para recuperarlo después
• Slides HTML — un tema definido, títulos, subtítulos, efectos, y un 20 % del ancho reservado a la derecha para la cámara

Hay que pensarlo una vez. Después reutilizas y dejas correr la creatividad.

El pipeline de contenido

Aquí es donde todo encaja. A partir de una sola fuente — el vídeo — produce:

• El prompt de miniatura para mi SaaS de miniaturas. Conoce el tema del vídeo y propone ángulos. Puedo llamar directamente a las API del SaaS, o quedarme solo con los prompts para poder editarlos.
• Los posts de LinkedIn y X. Sabe que el formato no es el mismo entre X, LinkedIn y Bluesky, y adapta.
• La programación en Typefully, vía su API.
• Los artículos de blog, en francés, inglés y español. Conoce mis API, crea el artículo, pone la imagen, pone el enlace al vídeo.
• El enlace corto mkc.sh con los UTM, inyectado automáticamente en cada post.
• La actualización del content registry — un proceso interno: con cada contenido nuevo se actualiza el registro.

El enlace corto es lo que hace medible todo lo demás. Un ejemplo concreto: en uno de mis vídeos, 668 clics. 458 desde LinkedIn, 171 desde X y casi nada en Bluesky. Nunca entro en la plataforma de tracking: es automático.

Y para que quede claro: no soy yo quien redacta esos posts, y no me da vergüenza decirlo. Es contenido que he creado, en el que he trabajado, cuya investigación he hecho. Que la IA lo condense en un post no me molesta.

El kanban: lo que sobrevive a la sesión

Todo lo anterior tiene un límite.

Un comando goal, un background, un prompt normal — todo eso muere con la sesión. Tu sesión tiene una vida útil, estás limitado en tokens y después se olvida.

El kanban, en cambio, se guarda. Persiste aunque reinicies.

Cómo funciona:

• Creas boards (creación de contenido, demo de vídeo…)
• Dentro, tareas que puedes asignar a agentes más concretos: un writer, un publisher, un designer
• Puedes promptearlas o crearlas a mano

Ahí está la ganancia real: pasar de un encadenado secuencial (el enlace corto, luego el post de LinkedIn, luego el de X, luego el prompt de miniatura, luego el artículo) a algo paralelo. Le das el vídeo de origen, le dices «lanza todo esto en paralelo en un kanban» y él lo trocea.

Cuándo usar qué:

El resumen

Cuatro capas, en este orden:

1. Un VPS — el agente corre 24/7, independiente de tu máquina
2. CLIs — las manos. Sin ellas, todo lo demás improvisa
3. Skills — tus procesos, escritos una vez
4. Un board — para lo que debe sobrevivir a la sesión

Solo con los CLIs y los skills ya organizas toda tu actividad. El board es el piso de arriba.

🎥 El vídeo completo (demos, pantallas y las trampas en directo): Hermes Agent — todos los casos de uso y skills

📬 Cada semana comparto mis workflows de agentes IA en The Agentic Dev: suscribirse

Y si quieres entender cómo mis agentes comparten la misma memoria, es por aquí.