Cuando trabajas con asistentes de IA como Claude Code, llega un momento en que tus habilidades (skills) dejan de ser un truco personal y se convierten en una herramienta que tu equipo necesita. Al principio lo resuelves como cualquier desarrollador: comprimes la carpeta, la envías por Slack o la compartes en un repositorio compartido. Pero pronto te das cuenta de que ese ZIP es un problema disfrazado de solución. No hay versiones, no hay trazabilidad, y cada copia manual se convierte en un fork silencioso que nadie sabe actualizar. En Q2BSTUDIO, donde desarrollamos aplicaciones a medida para empresas que necesitan precisión y escalabilidad, sabemos que la gestión del conocimiento técnico no puede basarse en archivos sueltos. La respuesta no es un repositorio compartido más, sino un marketplace de plugins con identidad, versiones y un catálogo central. En este artículo te explico cómo crear el tuyo en quince minutos usando agkit, una herramienta que elimina la fricción de mantener un ecosistema de skills profesional.
El problema de fondo no es técnico, es conceptual. Cuando tienes un skill que convierte tu staged diff en un commit convencional, y lo usas doce veces al día, lo natural es querer compartirlo. Pero al hacerlo, introduces un vector de desactualización. Cada persona que lo recibe trabaja sobre una copia, sin vínculo con el origen ni forma de saber si tiene la última versión. Un repositorio compartido con catorce skills mezcladas es como un cajón de sastre: puedes clonarlo, pero luego tienes que seleccionar a mano lo que necesitas, y en ese mismo momento has creado un fork. Si otro equipo publica un skill excelente, te ves obligado a copiarlo o a pedirle a tu equipo que clone un segundo repositorio. La solución pasa por dos elementos que la industria ya tiene claros: el plugin como unidad y el marketplace como catálogo.
El plugin no es simplemente una carpeta con archivos; es una unidad con identidad. Tiene un nombre, una versión, un autor y una descripción. Se instala, actualiza y desinstala como un todo. Claude Code y GitHub Copilot ya modelan las extensiones así. Lo que falta es la infraestructura para crear y mantener ese modelo sin esfuerzo. Y ahí entra agkit, una herramienta que no reinventa nada, sino que hace que lo obvio sea barato de implementar. Piensa en ella como el ng de Angular para marketplaces de plugins de agentes: un comando crea un repositorio listo para publicar, y unos cuantos más cubren el ciclo de vida completo. En Q2BSTUDIO, cuando abordamos proyectos de inteligencia artificial o automatización, aplicamos exactamente este principio: la simplicidad de la herramienta no debe ocultar la complejidad del dominio, sino allanarla.
El proceso comienza con un scaffold. Con Node.js 22 o superior, ejecutas npx agkit init dev-toolkit y respondes unas preguntas básicas: nombre, propietario, descripción y remote de git. En segundos tienes un directorio con un catálogo en .claude-plugin/marketplace.json, una carpeta plugins/ vacía, un README con sección de instalación ya rellena, un AGENTS.md para contexto del agente, e incluso un flujo de CI. El catálogo es un JSON plano con schema, lo que permite autocompletado en el editor y validación desde el primer commit. No hay build, no hay compilación: el agente lo lee tal cual. Esto significa que puedes servir a Claude Code, Copilot, Codex y Cursor desde el mismo repositorio, porque todos ellos entienden ese formato nativo. En Q2BSTUDIO, cuando integramos servicios cloud AWS o Azure, valoramos especialmente que una misma infraestructura pueda atender múltiples entornos sin duplicar esfuerzos. Aquí ocurre exactamente eso: un catálogo, cuatro agentes.
Una vez que tienes el esqueleto, añades tu primer skill con agkit add skill commit-crafter. La herramienta te ofrece varias plantillas: skill, command, agent, hook y MCP. La plantilla genera dos archivos (un SKILL.md y un manifest) y registra el plugin en el catálogo. El SKILL.md viene con instrucciones de relleno; lo importante es que el description del front matter es lo que Claude lee para decidir si cargar el skill, así que conviene redactarlo con precisión. Sustituyes el esqueleto por el contenido real de tu skill: la lógica para detectar cambios staged, elegir el tipo de commit y generar el mensaje. El manifest plugin.json es la fuente de verdad; si luego lo editas a mano, solo necesitas agkit sync para que el catálogo, el README y el AGENTS.md se actualicen automáticamente. Esto evita la deriva de información, un problema habitual en proyectos de Business Intelligence y Power BI donde varios paneles dependen de la misma fuente de datos.
Aquí viene el punto que realmente diferencia un marketplace de un cajón desastre: puedes referenciar plugins que viven en repositorios ajenos sin copiar ni una línea. Con agkit add octo-org/changelog-skill changelog --ref v1.2.0, tu catálogo gana una entrada que apunta a ese repositorio externo con un tag fijo. Tu equipo no descarga el código de ese plugin; lo obtiene directamente desde la fuente original en el momento de la instalación. No tienes que mantener una copia, no tienes que rastrear actualizaciones. Si quieres mover la referencia a una versión posterior, usas agkit add ... --ref v1.3.0. Si necesitas apropiarte del código y modificarlo, usas la bandera --vendor para que lo clone dentro de tu carpeta plugins/. La regla es simple: referencia por defecto, clona solo cuando quieras poseer. En Q2BSTUDIO, aplicamos esa misma filosofía cuando trabajamos con librerías de terceros en proyectos de ciberseguridad: integramos lo que está probado sin crear una bifurcación innecesaria, pero nos reservamos el derecho de forkear cuando el control del código es crítico.
Antes de publicar, validas con agkit validate. La herramienta comprueba la validez JSON, nombres en kebab-case, ausencia de nombres reservados, resolución de fuentes, existencia de manifests y consistencia de versiones. Si tienes el CLI de Claude Code instalado, también lanza la validación nativa del agente. El flujo de CI que se generó al inicio ya incluye este comando, así que cualquier pull request con un catálogo roto no pasará. Publicar es simplemente hacer git push. No necesitas un registro central ni un token de publicación. Tu equipo puede añadir tu marketplace con /plugin marketplace add jane/dev-toolkit e instalar cualquier plugin con /plugin install commit-crafter@dev-toolkit. Si además copias el examples/team-settings.json generado al directorio de configuración de Claude, el marketplace se añade automáticamente cuando los miembros del equipo confían en el repositorio. Es decir, cero pasos manuales para los desarrolladores. Esto recuerda a cómo en Q2BSTUDIO facilitamos la adopción de automatización de procesos: la orquestación debe ser invisible para el usuario final.
El verdadero cambio de paradigma llega con el versionado. Un skill no es una carpeta estática; es un producto que evoluciona. Mejoras tu commit-crafter para que detecte cambios breaking, haces commit con un mensaje convencional (feat(commit-crafter): detect breaking changes and add a BREAKING CHANGE footer), y luego ejecutas agkit bump commit-crafter --tag. La herramienta analiza los commits que tocan ese directorio desde el último tag, aplica las reglas de conventional commits (feat = minor, fix = patch, feat! = major), escribe el changelog, actualiza la versión en el manifest y en el catálogo, sincroniza el README y el AGENTS.md, y hace un commit con el tag correspondiente. Todo en un solo comando. No tienes que tocar manualmente ninguna versión ni ningún changelog. Y como cada plugin tiene su propio tag (commit-crafter@0.2.0), los releases de un skill no contaminan los de otro. Cuando tu compañero ejecuta /plugin update, obtiene exactamente esa versión. Esto es lo que significa tratar los skills como software que se distribuye, no como archivos que se comparten. En Q2BSTUDIO, cuando desarrollamos aplicaciones a medida, aplicamos el mismo rigor semántico: cada módulo tiene su propio ciclo de vida y su propio versionado independiente.
Hay un detalle que no debes pasar por alto: no puedes hacer bump sobre un plugin remoto referenciado (como el changelog del ejemplo). Su versión la controla el autor original. Para moverlo, vuelves a pinchar con agkit add ... --ref nueva-versión. Esto es correcto, porque evita que tu catálogo se convierta en un gestor de versiones upstream. Tú eres el curador, no el mantenedor. Y si algún día decides que quieres modificar ese plugin, lo añades con --vendor y a partir de ese momento es tuyo, con todo lo que eso conlleva. Esta distinción entre referencia y copia es la misma que aplicamos en proyectos de cloud híbrido: sabes qué servicios consumes como SaaS y cuáles gestionas tú. La claridad de límites evita dolores de cabeza.
Para cerrar el ciclo, pensemos en el ecosistema completo. Un marketplace así puede servir a Claude Code, Copilot, Codex y Cursor desde un solo repositorio, sin duplicar contenido de plugins. La clave está en que el catálogo es el único artefacto fuente; todo lo demás (README, AGENTS.md, registros para Codex y Cursor) se deriva de él mediante agkit build o agkit sync. Esto garantiza que no haya deriva: lo que ves en el catálogo es lo que se instala. Y si tu equipo usa forjas distintas (GitLab, Bitbucket, Gitea, self-hosted), agkit se adapta porque la distribución es simplemente git. La herramienta no impone GitHub como único canal, algo que en Q2BSTUDIO valoramos al gestionar entornos multicloud donde cada cliente tiene su propia política de repositorios.
Al final, el cambio de mentalidad es sutil pero profundo. Dejas de ver tus skills como archivos que comprimes y envías, y empiezas a verlos como plugins que publicas, versionas y actualizas. No necesitas una plataforma externa ni una cuenta especial; con un repositorio git y agkit tienes todo lo necesario. El ZIP era una solución rápida que se convertía en deuda técnica. El marketplace es una inversión de quince minutos que paga dividendos cada vez que alguien instala, actualiza o descubre un skill. Y cuando ese alguien te pregunta '¿me pasas ese skill?', ya no respondes con un adjunto, sino con una línea de terminal: /plugin install commit-crafter@dev-toolkit. Tu equipo se lo agradecerá, y tú dejarás de ser el administrador informal de un cajón desastre para convertirte en el editor de un catálogo que evoluciona con orden. Como siempre decimos en Q2BSTUDIO, la tecnología bien estructurada no solo resuelve problemas: elimina la fricción para que el equipo pueda centrarse en lo que realmente importa.
