Integrar Agent Skills en Omnilude

Introducción

Antes había escrito un post para presentar Skills y Agent Workflows.

Mientras lo releía, pensé: si los skills se conectan al chat con IA, pueden volverse realmente útiles.

Este artículo es un registro de implementación que nace de esa idea. Quise sacar los Skills de herramientas como Claude Code y Codex, hacer que un Agent los invoque dentro de un flujo de trabajo real, y ver qué cambia. Si esto funciona bien, quizá incluso LLMs más modestos puedan acercarse un poco más a Jarvis.

Explicar Skill en una sola frase

La definición más corta sería esta: un skill es un paquete de trabajo reutilizable que le enseña a un agente cómo resolver cierto tipo de tarea con un orden y unos criterios repetibles.

La guía pública de Anthropic también describe un skill como una carpeta centrada en SKILL.md, acompañada por scripts, references y assets cuando hace falta. Lo importante no es la forma sino el principio. En vez de meter todo el conocimiento dentro del prompt cada vez, permites que el agente abra el cuerpo del skill y sus referencias de manera progresiva, solo cuando lo necesita.

Esto importa más de lo que parece. Los agentes de propósito general son inteligentes, pero se desordenan fácilmente frente a tareas repetitivas. Incluso dentro del mismo repositorio, con el mismo trabajo y la misma petición, el tono, la estructura y los puntos omitidos pueden variar. Un skill sirve para reducir esa variación.

Hay tres principios que para mí son especialmente importantes. El primero es progressive disclosure, es decir, abrir documentos más profundos solo cuando hace falta. El segundo es composability, donde un skill no intenta resolverlo todo por sí solo, sino que trabaja junto con otros skills. El tercero es portability, para que no quede atado a una sola pantalla o a una sola herramienta.

La cadena de Skills que estoy construyendo

En mi repositorio local hay 25 skills bajo .codex/skills. Se reparten trabajos repetitivos como generación de documentos, implementación de APIs, CRUD de backoffice, SSE, pipelines narrativos, traducción, revisión y flujos de commit. Bajo .agents/skills mantengo el mismo catálogo alineado para reutilizarlo desde otra surface.

Y también hay una razón por la que Codex aparece de repente después de hablar tanto de Claude Code. En Corea hubo hace poco una promoción de OpenAI Pro con casi 90% de descuento a través de Kakao. Fue una buena oportunidad, así que ahora me pasé a Codex.

Volviendo al punto central, el eje de skills que uso con más frecuencia es bastante claro. prd-generator toma los requisitos y produce un PRD ajustado a nuestras reglas documentales, mientras que endpoint-implement-skill fija el patrón de implementación desde Entity hasta Controller. Si hace falta, frontend-task-handover continúa con un documento de traspaso para frontend, y branch-review revisa regresiones y riesgos al final.

Es decir, suelo ver los skills más como una cadena que como funciones aisladas.

De hecho, en CLAUDE.md ya dejé escrito qué skills deben conectarse primero según el tipo de trabajo. Por ejemplo, el trabajo de API sigue la cadena prd-generator -> endpoint-implement-skill -> frontend-task-handover, mientras que el trabajo de backoffice sigue prd-generator -> backoffice-crud-skill -> frontend-task-handover. En ese punto, un skill deja de sentirse como una ayuda secundaria y pasa a parecerse más a una regla operativa de trabajo.

Lo interesante es que este mismo post se apoya en la misma filosofía. El skill blog-post-writer que estoy usando ahora está diseñado para alinear de una vez la categoría del blog, el reading time, el tone, la longitud del excerpt, la canonical URL, el prompt de la miniatura y el esquema JSON de importación. Incluso escribir ya no depende solo de la intuición. También queda empaquetado como un formato de salida repetible.

Skills y asistentes

Cuando un skill entra al producto, deja de poder explicarse solo con SKILL.md. Si tomamos como referencia el blueprint detallado de current-weather-checker, el skill real se parece más a una unidad de runtime que agrupa no solo instrucciones y documentos de referencia, sino también código ejecutable, metadatos, políticas de red y estrategia de trigger. Por eso ahora, al mirar un skill, ya no pienso solo en la estructura de carpetas, sino también en qué se guarda, qué se ejecuta y cómo se conecta con el asistente.

Vista general de la estructura del skill

Si sigues el blueprint de current-weather-checker, la sustancia de un skill es más tridimensional de lo que parece. Lo primero que ves en pantalla es el nombre y la descripción, pero detrás hay Instructions, Scripts, References, Assets, Metadata y Runtime Policy. Gracias a esa composición, algunos skills solo enriquecen el contexto, otros se ejecutan directamente dentro del sandbox y otros pueden controlar de forma segura el acceso a la red externa.

En resumen, un skill no es solo un archivo de prompt. Se parece más a un objeto de definición que agrupa texto descriptivo + recursos de ejecución + política operativa. En particular, en los script skills, políticas de ejecución como networkPolicy y allowedDomains determinan los permisos reales. Leer solo body no basta para entender qué puede hacer realmente ese skill. Justamente por eso los blueprints son útiles: restauran de una sola vez la estructura que está detrás de la pantalla.

Vista general de la integración con asistentes

El siguiente punto importante no es el skill en sí, sino quién posee ese skill, bajo qué condiciones se invoca y por qué ruta se ejecuta después de ser seleccionado. En la estructura de Omnilude, el skill no cuelga de forma suelta de un agent, sino que se mapea a un assistant, y el orchestrator lee ese mapping y la información del trigger para decidir la ruta real de ejecución. Los skills ejecutables fluyen hacia el sandbox, mientras que el material context-only fluye hacia el prompt de la respuesta final.

Entorno de ejecución aislado

Los scripts de los skills ejecutables no corren directamente dentro del proceso del assistant. AssistantSkillScriptExecutor delega la ejecución a un sandbox pod separado a través de sandbox-bridge, y el script corre dentro de ese entorno aislado, recibiendo stdin JSON como entrada y devolviendo stdout JSON como salida. Esta estructura separa el núcleo del assistant del código de ejecución y, al mismo tiempo, permite controlar el alcance del acceso externo con networkPolicy y allowedDomains.

Dicho de forma simple, el assistant decide qué ejecutar, y el sandbox es el lugar donde esa ejecución se procesa de forma segura. Cuantos más skills haya, más importante se vuelve esta separación. Permite aislar fallos, dividir permisos de red con más precisión y rastrear más fácilmente qué script se ejecutó bajo qué política.

Mirado desde ese flujo, un skill se parece más a un módulo que el assistant selecciona y ejecuta cuando lo necesita, que a un documento subordinado del assistant. Por eso, a medida que los attached skills se vuelven más potentes, lo importante ya no es cuán larga es la explicación, sino cuán claramente están diseñados mapping, trigger, execution y observability. Al final, un buen skill no es solo un documento bien escrito. Es una superficie de ejecución estructurada que un assistant puede invocar de forma confiable.

Cierre

Si el post sobre workflow del 18 de febrero de 2026 explicaba cómo fluye un agente, este post trata de cómo fijar ese flujo dentro de una estructura estable a través de skills.

Un skill no es una opción mágica. Pero sigue siendo una herramienta muy potente para reunir en una sola unidad el trabajo repetitivo, los estándares de trabajo, el contexto de referencia, el formato de salida y las rutas de ejecución, tanto para individuos como para equipos.

La próxima vez quiero traer casos más concretos, desde la implementación y la operación, para mostrar cómo la combinación de skills y assistants puede mejorar la experiencia real de un agente.