Encuentras una skill excelente. La instalas.

Encuentras otra que parece hacer lo mismo, pero tiene una etapa de revisión mejor. También la instalas.

Después aparece una tercera, con ejemplos más claros y una descripción que parece escrita para tu problema. Ahora tienes más opciones y una pregunta más.

¿Cuál debería usar?

Una skill es un paquete de instrucciones y recursos reutilizables que orienta una clase de tareas. El agente de IA es el sistema que recibe contexto, elige pasos y utiliza herramientas para ejecutarla. Tener varias skills disponibles debería ampliar la capacidad del agente. Sin criterio, también puede ampliar la confusión.

Esa necesidad de gestión me llevó a construir I-9 Skills, un proyecto público de I-9.ai para descubrir, crear, evaluar, organizar, mantener y distribuir skills. Utilizo la herramienta en mi entorno local y abrí el proyecto a quienes quieran experimentar, evaluar sus propias skills y contribuir con mejoras.

También creé el sitio de I-9 Skills, disponible en portugués, inglés y español, para presentar la biblioteca. El código y la documentación están en el repositorio público.

Mi intención es aprovechar las mejores contribuciones de las skills que encontramos por ahí — la crème de la crème — y convertirlas en mejores paquetes para un trabajo definido. Elegir lo que funciona, entender por qué funciona, combinar cuando tenga sentido y poder mejorar después.

Instalar una skill es fácil. Saber si sigue siendo la adecuada requiere trabajo.

Tres skills para el mismo trabajo. Ninguna decisión clara

Imagina que quieres revisar una aplicación. Una skill prioriza la arquitectura. Otra busca problemas de seguridad. Una tercera también se llama «revisión», pero fue escrita para comprobar el estilo del código.

Los nombres parecen equivalentes. Los resultados que entregan son distintos.

Si el agente elige por la etiqueta más parecida a tu petición, puedes recibir una respuesta impecable a una pregunta que nunca hiciste. Si carga todo, puede mezclar criterios que compiten entre sí y consumir contexto — el material disponible para orientar al modelo — sin aclarar el trabajo.

I-9 Skills trata el descubrimiento y el enrutamiento como responsabilidades distintas. Descubrir es encontrar y evaluar candidatos. Enrutar es elegir el procedimiento adecuado al objetivo y las restricciones de esa ejecución.

La entrada skill-routing puede recomendar una skill, una secuencia corta con entregables distintos, una lista limitada de alternativas que necesitan aclaración o none, cuando ninguna sea necesaria. El catálogo ayuda a encontrar candidatos; la elección exige leer SKILL.md, el archivo con las instrucciones y los límites del paquete.

Esto retoma una cuestión que ya exploré sobre skills disponibles que no llegan al trabajo: nadie debería tener que memorizar un menú invisible para que aparezca la capacidad correcta.

La skill que hace de todo, incluso lo que no pediste

Otro escenario: pides un análisis, pero la skill también incluye investigación, implementación, pruebas, instalación y publicación. Todo en el mismo paquete, con una descripción lo bastante amplia como para encajar en casi cualquier conversación.

Se convirtió en un pequeño departamento. Solo olvidó definir los puestos.

Eso puede volver ambigua su selección: quizá el procedimiento completo no corresponda, aunque una parte sea útil. También dificulta reconocer dónde termina el análisis y empieza una acción que requiere autorización.

En I-9 Skills, una responsabilidad por skill y un entregable principal revisable orientan el diseño. skill-design delimita el trabajo; skill-authoring produce el paquete; skill-evaluator evalúa su comportamiento. La auditoría y la refactorización — reorganizar preservando lo que debe seguir funcionando — ayudan a identificar solapamientos y proponer divisiones.

La idea es poder elegir, probar o corregir una pieza sin tener que reescribir el conjunto entero. Por eso la biblioteca utiliza meta-skills: skills cuyo trabajo es cuidar de otras skills y de su colección.

En otro agente, la misma skill se convirtió en otra cosa

Considera una skill instalada en el proyecto, otra copia en el entorno del usuario y una adaptación en otro agente. Todas llevan el mismo nombre. Una recibió una corrección. Otra conserva una regla antigua. La tercera incorporó un paso específico de esa aplicación.

Cuando el comportamiento diverge, ¿por dónde empiezas a buscar?

«Pero eso ya lo había corregido» se vuelve una frase poco útil cuando nadie sabe qué copia ejecutó el trabajo.

La propuesta del proyecto combina catálogo, procedencia e historial. El catálogo permite inspeccionar la colección; los registros distinguen fuentes y revisiones, incluso cuando coinciden los nombres. La instalación y la migración tienen responsabilidades propias, para que mover un paquete no signifique perder sus recursos o su procedencia.

Las skills están escritas en inglés y siguen el formato de la especificación Agent Skills. Cada paquete incluye su licencia Apache-2.0, referencias, recursos y scripts aplicables — pequeños programas auxiliares. Esos recursos se encuentran a partir del propio directorio de la skill; los resultados van al espacio de trabajo elegido por quien solicita el trabajo.

Esta autonomía permite llevar el paquete a otro entorno sin depender de un archivo olvidado en la máquina de quien lo creó. Las herramientas y configuraciones necesarias todavía deben declararse y prepararse.

La skill nació con un contexto limitado. Y quedó atrapada en él

Una skill pudo ser excelente para el problema que la originó. Después aparecen excepciones, cambia una documentación, encuentras un enfoque mejor o el agente falla en una situación que nadie había previsto.

Si la corrección queda solo en la conversación, el siguiente agente puede repetir el error. Si cada intento modifica la skill sin comparación, cuesta saber si mejoraste el procedimiento o simplemente lo acomodaste al último caso.

Aquí es donde quiero gestionar la evolución.

skill-evidence-collection organiza evidencias; skill-evolution produce una candidata basada en ellas; skill-optimization trabaja mejoras medibles en iteraciones delimitadas. La evaluación compara el comportamiento con casos y criterios definidos antes del veredicto. Adoptar la nueva candidata sigue siendo una decisión propia.

Un snapshot, una copia identificable de un estado, ayuda a conservar la versión anterior. skills-snapshot aborda su creación, verificación y restauración; skills-maintenance-scheduling prepara propuestas de mantenimiento recurrente. Puedes organizar la revisión y mantener un camino de vuelta sin convertir un calendario en autorización para cambiarlo todo.

Es la misma preocupación de aprender sin reescribir el pasado: un fallo puede justificar una investigación. La investigación debe sustentar el cambio.

Hay cosas buenas en varias skills. ¿Tengo que elegir solo una?

No siempre.

Imagina una skill con buenas preguntas para recopilar requisitos, otra con casos de prueba útiles y una tercera que explica bien cuándo interrumpir el trabajo. Son contribuciones distintas para un mismo objetivo.

Ese es el tipo de aprovechamiento que quiero facilitar. skills-discovery evalúa las fuentes; skill-domain-research investiga el tema en referencias fiables y en el conocimiento de quien responde por el proceso. Cuando dos o más skills aportan contribuciones distintas, skills-synthesis organiza qué combinar, qué descartar y por qué.

La síntesis no consiste en pegar tres textos y esperar que el tamaño se convierta en calidad. Consiste en preservar procedimientos útiles, compatibilidad de licencias, referencias y límites, resolviendo contradicciones antes de diseñar la nueva skill. Una única fuente contribuyente puede pasar al diseño sin una síntesis artificial; la investigación del tema sigue siendo necesaria.

Para mí, «lo mejor de lo mejor» expresa esa ambición de seleccionar y probar contribuciones. No es una certificación de haber encontrado la mejor skill de todo el mercado.

¿Instalada, olvidada o activada en el momento equivocado?

Una skill puede estar disponible y no ser elegida nunca. Otra puede aparecer en situaciones donde no debería. Una tercera puede leerse con frecuencia sin producir un entregable útil.

Estos problemas requieren observación. Por eso también trabajé el proyecto con hooks, integraciones activadas por eventos de la aplicación, y telemetría, registros delimitados de lo observado.

Los hooks de sesión pueden proporcionar un mapa compacto de las skills disponibles. Observar lecturas es opcional y depende del host, la configuración y el almacenamiento elegido. El adaptador documentado para Claude distingue intentos y lecturas nativas satisfactorias; los hooks de Codex proporcionan contexto sin prometer un recuento nativo de lecturas.

Para investigar consumo y recurrencia, es esencial separar las preguntas:

• ¿Se encontró o se leyó? Es una señal de disponibilidad o consulta.
• ¿Se utilizó su procedimiento? Es una declaración de activación que requiere un registro propio.
• ¿Terminó el trabajo y fue bueno el resultado? La finalización registrada y la calidad evaluada son evidencias diferentes.

Los registros del ciclo de vida permiten registrar selección, activación y resultados con identidad de la fuente y límites de cobertura. Son señales declaradas por quien las registra. Un recuento de lecturas no demuestra comprensión; la ausencia de registro no demuestra ausencia de uso.

Eso ayuda a formular mejores preguntas sobre efectividad. No convierte la frecuencia en calidad ni hace que una skill evolucione sola.

Un paquete completo, con identidad para cada pieza

La gestión abarca descubrimiento, investigación, diseño, síntesis, autoría, evaluación, seguridad, catálogo, evolución, instalación y publicación. Cada responsabilidad tiene su lugar.

Las skills siguen orientaciones y plantillas de estructura para declarar entradas, salidas, límites, recursos y verificaciones. Los validadores comprueban el formato y criterios adicionales de la colección. La evaluación del comportamiento busca errores que un archivo bien formado no revela.

También existe skill-icon-design, dedicada a crear iconos. Los paquetes de la colección incluyen iconos distintos y metadatos de interfaz para Codex, permitiendo su presentación visual en los clientes que admiten esa función. Al crear tus propias skills, el flujo también puede producir esa identidad.

Sí, el icono bonito viene incluido. Ayuda a reconocer la pieza. Aun así, hay que comprobar que haga bien el trabajo.

El núcleo es agnóstico del agente: seguir los procedimientos no exige un proveedor específico. Las integraciones añaden recursos según el host, la aplicación que ejecuta el agente. Hay manifiestos para Codex, Claude Code y Copilot; descubrimiento, interfaz, hooks y permisos deben verificarse en el entorno elegido. La portabilidad del paquete no promete un comportamiento idéntico en todos los clientes.

Experimenta con un problema que ya tengas

Puedes utilizar el proyecto como skills portátiles o como plugin, que añade la colección y sus integraciones a la aplicación. También hay una CLI, interfaz de comandos en el terminal, para catálogo, validación y herramientas de gestión, además de un servidor MCP, protocolo que conecta aplicaciones de IA con herramientas y recursos.

Para instalar la colección en el proyecto, el README utiliza la CLI externa Skills:

npx skills add i-9-ai/skills --yes

En ese comando, --yes selecciona las skills disponibles y omite los pasos de selección. La opción --global cambia el destino al ámbito del usuario. Comprueba el alcance y el agente elegido por el instalador.

Como alternativa, para Codex, con los requisitos del README preparados:

codex plugin marketplace add i-9-ai/skills --ref main
codex plugin add i9-skills@i9-skills
codex plugin list

La guía de instalación por plugin orienta la habilitación, actualización y eliminación. Reinicia la sesión o el cliente según esas indicaciones.

Nuestra CLI es otro paquete: @i-9.ai/skills. Node.js proporciona el entorno para ejecutar estos programas, y npm gestiona sus paquetes. Con los requisitos publicados preparados, npx permite ejecutar la CLI sin instalación global; la primera llamada puede descargar el paquete y sus dependencias:

npx --yes @i-9.ai/skills --help
npx --yes @i-9.ai/skills catalog overview
npx --yes @i-9.ai/skills catalog read --skill skill-authoring

Estos comandos consultan la colección incluida en la CLI. No instalan las skills en el agente. Para descubrir los paquetes del proyecto actual sin incluir los globales:

npx --yes @i-9.ai/skills context available-skills --project . --no-global

Con las skills disponibles en tu agente, empieza por una petición delimitada:

Usa skills-audit para analizar mi colección. Identifica skills con responsabilidades solapadas, versiones divergentes, recursos ausentes y descripciones que dificultan elegir el procedimiento correcto. Muestra las evidencias y propone prioridades de mejora. No modifiques archivos, instales ni publiques nada en esta etapa.

Después elige un hallazgo de la auditoría. Si hay buenas contribuciones en fuentes diferentes, pide un plan de síntesis. Si el problema es una responsabilidad excesiva, pide una división. Si una skill está fallando, lleva casos concretos a su evaluación y evolución.

El proyecto es experimental. Quiero que puedas probar con un objetivo pequeño, conservar el estado anterior y evaluar el resultado en tu entorno.

Si encaja con tu colección, conoce I-9 Skills en su sitio, prueba la biblioteca y cuenta qué encontraste: cuál era el problema, qué host utilizaste, qué esperabas y qué ocurrió. Un ejemplo mínimo, sin credenciales, datos personales ni material de clientes, ayuda a convertir comentarios en mejoras verificables.

Una buena skill merece ser encontrada, elegida en el contexto correcto y mejorada cuando la realidad muestra sus límites. Construí esta biblioteca para cuidar ese recorrido.

Para profundizar

• El modelo es solo el motor: sitúa las skills en el sistema que rodea al modelo.
• Especificación Agent Skills: explica la estructura portátil de instrucciones y recursos.

Referencias y límites de uso

• Sitio de I-9 Skills: presentación pública de la biblioteca en el idioma de este artículo.
• Repositorio y README: fuente de los comandos, responsabilidades, recursos de interfaz y vías de distribución. Los requisitos e integraciones deben comprobarse antes de instalar.
• Wiki, especialmente validación e investigación de fuentes: documenta el método y las verificaciones. La conformidad estructural no certifica calidad en producción.
• Hooks y evidencias del ciclo de vida: delimitan observación, configuración y registros declarados. No prueban activación por lectura ni efectividad por frecuencia.
• Pilotos nativos: verificaciones delimitadas de integración, sin certificación universal de hosts o del comportamiento de los modelos.

Las situaciones de este artículo ilustran los problemas que motivaron el proyecto. Mi utilización local es un relato de uso; no sustituye una evaluación independiente ni demuestra una mejora cuantitativa de productividad.