47 skills y 8 agentes de IA sincronizados desde un solo repo: así lo monté
Esta mañana abrí la terminal con 18 skills y un script que copiaba archivos. La cerré con 47 skills, 8 agentes sincronizados, un repo privado en GitHub como fuente de verdad y un sistema de importación inversa que rescata skills creadas por cualquier agente automáticamente.
No es un chatbot con plugins. Es un sistema operativo para agentes de IA.
Te cuento cómo lo monté, por qué funciona y qué aprendí en el proceso.
El problema: 8 agentes, 8 versiones distintas de la verdad
Trabajo con varios agentes de IA a diario. Claude Code para tareas pesadas de desarrollo, OpenClaw para el VPS, Hermes para automatizaciones, Kimi para consultas rápidas, OpenCode para coding… Cada uno tiene su propio sistema de “skills” — instrucciones especializadas que les dicen cómo hacer cosas concretas como generar una imagen, analizar SEO o gestionar un repo de GitHub.
El problema era evidente: si creaba una skill en Claude, Hermes no la veía. Si OpenClaw mejoraba una en el VPS, se perdía al sincronizar. Si Kimi generaba una skill nueva, nadie más se enteraba.
Era el caos. Ocho silos de conocimiento divergiendo silenciosamente.
La solución: fuente única + sincronización bidireccional
La arquitectura es más simple de lo que parece:
El flujo es este:
- Crear skill en la fuente →
setup-all.sh --allla distribuye a todas las CLIs - Agente remoto crea skill →
setup-all.sh --all --importla rescata y la copia a la fuente - Git →
skills-pushsube cambios,skills-pulllos baja y distribuye - Cron en el VPS → cada 30 minutos hace
git pullpara recibir skills nuevas
La clave está en cómo se distribuye. No todos los agentes pueden usar el mismo método:
Los que soportan symlink apuntan directamente al directorio fuente. Cualquier cambio que haga aparece al instante en los 5. Los que no, reciben una copia física vía rsync cada vez que ejecuto el script.
El verdadero avance: importación inversa
El --import es lo que cierra el círculo. Sin él, si OpenClaw crea una skill en el VPS y yo ejecuto setup-all.sh en el OMEN, el rsync machaca lo que haya en el VPS con lo que hay en local. Adiós skill nueva.
Con --import, el script primero escanea los directorios de los agentes remotos, detecta skills que no existen en la fuente, y las copia de vuelta antes de distribuir. Así nada se pierde:
github.com/asturwebs/bytia-skills
~/bytia/skills/ — Fuente de verdad local
47 skills: de qué son capaces estos agentes
El ecosistema actual cubre prácticamente todo lo que hago a diario:
Las skills se cargan bajo demanda. El agente no carga las 47 en contexto — solo invoca la que necesita cuando el trigger coincide con lo que le pides. Tener 47 skills no satura el modelo, le da más herramientas.
Si tienes un negocio y quieres automatizar procesos con agentes de IA que trabajen para ti 24/7, mira cómo puedo ayudarte con IA aplicada a negocio real.
Anatomía de una skill
¿Qué hay dentro de cada una de esas 47 skills? No es magia, es un estándar abierto llamado Agent Skills (agentskills.io). Cada skill es un directorio con un archivo SKILL.md que contiene:
- Frontmatter YAML con nombre, descripción y triggers (en qué momento el agente debe cargarla)
- Instrucciones paso a paso que el agente sigue cuando la invoca
- Ejemplos de uso y casos edge
Cuando le pido a Claude “audita el SEO de esta web”, el agente detecta el patrón, busca entre sus 47 skills, encuentra la skill seo-audit, la carga y ejecuta sus instrucciones. Sin intervención humana, sin copiar y pegar prompts.
Lo potente es que cualquier agente puede crear una skill nueva. Si durante una sesión Kimi genera un patrón útil para investigación, lo guarda como skill en su directorio. La siguiente vez que ejecuto setup-all.sh --import, esa skill vuelve a la fuente y se distribuye a los otros 7. El conocimiento fluye en ambas direcciones.
Lo que aprendí montando esto
—delete solo limpia archivos dentro de cada skill, no directorios enteros que ya no existen en la fuente. Tuve que añadir una pasada de limpieza de huérfanos explícita.git pull, el hook ejecuta setup-all.sh —all automáticamente. Bajas cambios del repo y en segundos están distribuidos a todos los agentes. Cero fricción.skills-check (alias de setup-all.sh —check) verifica en segundos que los 8 agentes más el workspace tienen exactamente las mismas skills. Si algo diverge, te dice cuáles faltan o sobran.Lo que cambiaría si empezara hoy
Con el ecosistema ya maduro y varias semanas de uso real, hay tres cosas que haría diferente desde el principio:
1. Tests desde el día uno. El primer bug de limpieza de huérfanos me pilló con 12 skills desincronizadas. Si hubiera tenido un test que verificara la integridad tras cada sync, lo habría pillado en minutos, no días. Ahora skills-check forma parte de mi flujo, pero debería haber sido lo primero.
2. Versionado semántico en las skills. Las skills evolucionan, y a veces un cambio rompe compatibilidad con agentes que esperaban la versión anterior. Un campo version en el frontmatter con reglas de compatibilidad habría ahorrado algún que otro dolor de cabeza.
3. Métricas de uso desde el inicio. Ahora sé que mis skills más usadas son blog-seo-post, github-workflow y local-ai-nemotron, pero no tengo datos históricos de cuándo se volvieron populares. Un simple contador de invocaciones por skill me daría señales tempranas de qué mantener y qué deprecar.
4. Política de conflictos en el cron. El git pull automático cada 30 minutos funciona… hasta que modificas la misma skill en local y en el VPS a la vez. Un conflicto de merge en un cronjob falla silenciosamente — la sincronización se para y nadie se entera. La solución que debería haber implementado desde el principio: el script detecta conflictos (git diff --check), fuerza --strategy-option theirs para el VPS (que es réplica, no fuente), y te notifica por Telegram con el log del error. Sin eso, un conflicto puede pasar días sin detectarse.
5. Gestión de secretos antes de distribuir. Distribuir 47 skills entre 8 agentes y un VPS significa que cualquier ruta absoluta (/home/asturwebs/...) o clave de API en texto plano se propaga a todos lados. Las skills deben usar interpolación de variables de entorno ($GITHUB_TOKEN en lugar del string real) y el script de sync debe excluir activamente archivos .env, .local y cualquier archivo con el flag secret: true en el frontmatter. No lo hice al principio y limpiar rutas hardcodeadas después fue tedioso.
¿Merece la pena?
Si usas un solo agente de IA, probablemente no necesitas esto. Pero si como yo trabajas con varios — cada uno con su fortaleza: Claude Code para razonamiento largo y desarrollo pesado, Gemini CLI para análisis multimodal, Codex para coding especializado, OpenCode como alternativa ágil, BytIA-KODE como agente propio con integración total, Kimi para velocidad en consultas rápidas, Hermes para automatizaciones, y OpenClaw para la infraestructura del VPS — tener un sistema que los mantiene a todos en la misma página es la diferencia entre un hobby y una infraestructura profesional.
En mi caso, pasé de perder skills regularmente a no haber perdido ni una en semanas. Y lo mejor: cualquier skill que cree OpenClaw desde el VPS aparece en mi máquina local en menos de 30 minutos, sin que yo mueva un dedo.
- • Usas 3+ agentes de IA a diario
- • Tienes skills que evolucionan con frecuencia
- • Trabajas en más de una máquina
- • Un agente remoto crea contenido
- • Necesitas reproducibilidad entre sesiones
- • Solo usas un agente (ChatGPT, Claude…)
- • Tus prompts son estáticos
- • No versionas tu trabajo
- • No necesitas reproducibilidad
- • Prefieres copy-paste entre sesiones
Los números después de semanas de uso
El setup completo — repo, script, 8 agentes, importación inversa — me llevó una tarde. El ROI ha sido inmediato: antes perdía 10-15 minutos al día gestionando versiones de skills entre agentes. Ahora es automático y verificable con un solo comando.
¿Quieres automatizar tu negocio con agentes de IA?
Te ayudo a diseñar e implementar el ecosistema de agentes que tu empresa necesita, desde la estrategia hasta el último script.
Cuéntame tu idea →Preguntas frecuentes
¿Qué es un ecosistema de agentes de IA?
Un conjunto de agentes de IA (como Claude Code, OpenClaw, Hermes) que comparten un sistema unificado de skills — instrucciones especializadas que les permiten hacer tareas concretas. Al sincronizarse desde una fuente única, cualquier skill que crea un agente está disponible para todos los demás automáticamente.
¿Cuántos agentes pueden trabajar juntos en este sistema?
En mi configuración actual conviven 8 agentes: Claude Code, Gemini CLI, OpenAI Codex, OpenCode, BytIA-KODE, Kimi CLI, Hermes Agent y OpenClaw (en un VPS remoto). Todos comparten exactamente las mismas 47 skills, sin versiones divergentes.
¿Cómo se sincronizan las skills entre agentes?
Uso dos métodos según el agente: symlink (enlace simbólico) para los agentes que corren en la misma máquina — es instantáneo, cualquier cambio aparece al momento. Y rsync para los que no soportan symlinks (Kimi, Hermes, OpenClaw) o están en un VPS remoto. Un script llamado setup-all.sh lo automatiza todo.
¿Qué tipo de skills tienen estos agentes?
Las 47 skills cubren generación de imágenes y vídeo con IA local, SEO y análisis web, publicación en X/Twitter, gestión de GitHub, investigación académica, desarrollo de software, operaciones ML, productividad con Google Workspace, monitoreo de salud, y mucho más. Cada skill es un directorio con un archivo SKILL.md que el agente carga bajo demanda.
¿Esto es útil para un freelance o una agencia pequeña?
Totalmente. Tener 8 agentes especializados compartiendo conocimiento permite hacer en horas lo que antes llevaba días. Desde auditar el SEO de una web hasta generar imágenes para un blog, pasando por escribir documentación técnica o analizar datos de Google Analytics. Y al estar todo versionado en git, no pierdes nada.
