El ecosistema: qué clientes soportan skills y en qué se diferencian

Hasta aquí el curso trató un skill como un artefacto aislado: un directorio con SKILL.md, sus scripts y sus referencias. Este capítulo cambia el punto de vista: qué pasa cuando ese directorio se copia a otro producto.

El formato Agent Skills fue desarrollado originalmente por Anthropic, liberado como estándar abierto y adoptado por un número creciente de productos de agentes; el estándar está abierto a contribuciones del ecosistema. Eso significa que hay un contrato compartido — el que fija specification.md — y una franja grande de comportamiento que cada cliente resuelve como quiere.

Saber dónde termina el contrato y dónde empieza la decisión de producto es lo que separa un skill que funciona en un solo cliente de uno que se puede publicar.

El showcase oficial y cómo leerlo

La página Client Showcase de agentskills.io publica los productos que soportan el formato. En el estado del repositorio consultado para este curso (commit 217be54) la lista contiene 44 entradas. De ellas, 43 declaran una URL de instrucciones de instalación — solo Piebald no la declara — y 24 declaran un repositorio de código fuente.

Antes de nada, tres advertencias sobre cómo interpretar esa lista.

No es un censo. CONTRIBUTING.md describe el alta como una solicitud: el producto debe estar públicamente disponible y ser capaz de descubrir y ejecutar skills hoy — no se listan productos que solo hayan anunciado intención de soportar Skills ni los que estén en beta privada. El alta se hace por pull request añadiendo logos en docs/images/logos/ y una entrada en el array de docs/snippets/clients.jsx; el equipo de Anthropic revisa las solicitudes de logo y puede pedir demo o captura. Puede haber implementaciones conformes que simplemente no pidieron figurar.

No es un ranking. El componente de la página baraja el orden en cada render por defecto, con un botón para ordenar alfabéticamente. La fuente no aporta ningún dato de adopción, cuota o número de usuarios.

Enlazar un repositorio no es lo mismo que ser open source. VS Code y GitHub Copilot enlazan repositorios públicos (microsoft/vscode, microsoft/vscode-copilot-chat) sin que eso convierta al producto completo en software libre. Y la ausencia del campo tampoco prueba que el producto sea propietario: solo indica que la ficha no enlaza repositorio.

Mapa por familias

La fuente publica una lista plana, sin categorías. La agrupación que sigue es una lectura propia para navegar las 44 entradas, no una taxonomía oficial. Varios productos cruzan familias — OpenCode se describe a la vez como terminal, IDE y escritorio — y en esos casos se ubica cada uno por su superficie predominante según su propia descripción.

flowchart TD
    E["Agent Skills<br/>44 clientes listados"] --> A["Agentes de terminal<br/>11"]
    E --> B["IDEs y editores<br/>10"]
    E --> C["Plataformas en la nube<br/>y orquestación · 10"]
    E --> D["Runtimes y frameworks<br/>8"]
    E --> F["Productos verticales<br/>5"]
    A --> G["Mismo SKILL.md<br/>Mismo frontmatter<br/>Mismas rutas relativas"]
    B --> G
    C --> G
    D --> G
    F --> G

Agentes de terminal

La superficie principal es la línea de comandos.

Cliente	Qué es	Documentación de skills
Gemini CLI	Agente de Gemini en la terminal.	geminicli.com/docs/cli/skills/
Claude Code	Herramienta agéntica de código en terminal, IDE, escritorio y navegador.	code.claude.com/docs/en/skills
OpenCode	Agente de código para terminal, IDE o escritorio.	opencode.ai/docs/skills/
Goose	Agente extensible que instala, ejecuta, edita y prueba con cualquier LLM.	block.github.io/goose/docs/guides/context-engineering/using-skills/
Autohand Code CLI	Agente de código autónomo de terminal con patrón ReAct y aprobación del usuario.	autohand.ai/docs/working-with-autohand-code/agent-skills.html
pi	Harness de código minimalista para terminal.	github.com/badlogic/pi-mono → packages/coding-agent/docs/skills.md
Mistral AI Vibe	Asistente de código por línea de comandos con modelos de Mistral.	github.com/mistralai/mistral-vibe
Deep Code	Asistente de código de terminal para el modelo DeepSeek, con control del esfuerzo de razonamiento, Skills y MCP.	deepcode.vegamo.cn/en/docs/configuration/agent-skills
Command Code	Agente de código con modelo neuro-simbólico que aprende el estilo del usuario por refuerzo continuo.	commandcode.ai/docs/skills
Factory	Plataforma de desarrollo AI-native que delega tareas completas a “Droids”, desde el IDE hasta CI/CD.	docs.factory.ai/cli/configuration/skills
Tabnine	Plataforma de ingeniería con IA que combina asistentes de código, flujos agénticos y contexto empresarial con control de privacidad.	docs.tabnine.com/main/getting-started/tabnine-cli/features/agent-skills

Factory y Tabnine son productos de superficie amplia, pero su documentación de skills apunta a la CLI, y por eso quedan aquí.

IDEs y editores

Viven dentro de un editor, o son el editor.

Cliente	Qué es	Documentación de skills
VS Code	Editor de código con ciclo edit-build-debug.	code.visualstudio.com/docs/copilot/customization/agent-skills
GitHub Copilot	Asistente de IA integrado en el editor que sugiere líneas y funciones.	docs.github.com/en/copilot/concepts/agents/about-agent-skills
Cursor	Editor con IA y agente de código integrado.	cursor.com/docs/context/skills
Junie	Agente de código LLM-agnóstico construido sobre la plataforma IntelliJ.	junie.jetbrains.com/docs/agent-skills.html
Roo Code	Equipo de agentes de desarrollo dentro del editor, con contexto de proyecto y codificación agéntica multi-paso.	docs.roocode.com/features/skills
TRAE	IDE adaptativo con IA.	trae.ai/blog/trae_tutorial_0115
Kiro	Herramienta que estructura la codificación con IA mediante desarrollo dirigido por specs.	kiro.dev/docs/skills/
Amp	Agente de código orientado a usar modelos frontier.	ampcode.com/manual#agent-skills
Firebender	Agente de código nativo de Android que escribe features y las prueba en el emulador.	docs.firebender.com/multi-agent/skills
Qodo	Plataforma agéntica de integridad de código: revisión, testing y escritura.	qodo.ai/blog/how-i-use-qodos-agent-skills-to-auto-fix-issues-in-pull-requests/

Plataformas en la nube y orquestación

Ejecutan o coordinan agentes en la nube, en paralelo o en workspaces aislados. Incluye los asistentes de propósito general con superficie web.

Cliente	Qué es	Documentación de skills
Claude	Asistente de IA de Anthropic para análisis, código y trabajo complejo.	platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
ChatGPT & Codex	Conjunto de agentes de OpenAI — Codex para desarrollo, ChatGPT Work para trabajo general — en escritorio, web, móvil, editor y terminal.	developers.openai.com/codex/skills/
OpenHands	Plataforma para agentes de código en la nube, escalable y model-agnostic.	docs.openhands.dev/overview/skills
Ona	Plataforma de agentes en segundo plano, orquestados y gobernados en la nube.	ona.com/docs/ona/agents-md#skills-for-repository-specific-workflows
Superconductor	Workspace multijugador para equipos y agentes de código, con sesiones compartidas y revisión guiada.	superconductor.com/docs/project/mcp-and-skills
Mux	Ejecución de agentes de código en paralelo, cada uno con workspace aislado, desde navegador o escritorio.	mux.coder.com/agent-skills
Emdash	App de escritorio agnóstica de proveedor que corre varios agentes en paralelo, cada uno en su git worktree, local o por SSH.	docs.emdash.sh/skills
Workshop	Agente de código multiplataforma con multi-LLM, sub-agentes, agentes personalizados y skills.	docs.workshop.ai/core-concepts/working-with-the-agent#create-your-own-agents
Letta	Plataforma para construir agentes con estado y memoria avanzada.	docs.letta.com/letta-code/skills/
Piebald	App de escritorio y web para desarrollo agéntico con control total de configuración, contexto y flujo.	La ficha no declara URL de instrucciones

Runtimes y frameworks

Se integran como biblioteca, runtime o framework para construir tus propios agentes. Esta familia es la más interesante para el capítulo siguiente: aquí el soporte de skills no es una feature de producto, sino una API.

Cliente	Qué es	Documentación de skills
Spring AI	Framework para incorporar funcionalidad de IA en aplicaciones Spring.	spring.io/blog/2026/01/13/spring-ai-generic-agent-skills/
fast-agent	Forma simple y extensible de interactuar con LLMs, orientada a código, evals, ACPX y desarrollo de skills.	fast-agent.ai/agents/skills/
bub	Framework Python ligero y hook-first para agentes nativos de canal.	bub.build/docs/build/skills/
nanobot	Agente personal ultraligero que corre en terminal, Telegram, Discord, Slack, WeChat y más, con MCP y skills.	nanobot.wiki/docs/0.1.5/use-nanobot/skills
ZeroClaw	Runtime de agentes personales en Rust, local y agnóstico de proveedor.	docs.zeroclawlabs.ai/master/en/tools/skills.html
VT Code	Agente de código con comprensión LLM-nativa y seguridad de shell, multi-proveedor con failover.	github.com/vinhnx/vtcode → docs/skills/SKILLS_GUIDE.md
Laravel Boost	Paquete que aporta guidelines y agent skills para que los agentes escriban Laravel idiomático.	laravel.com/docs/12.x/boost#agent-skills
Google AI Edge Gallery	App para ejecutar LLMs abiertos en dispositivos móviles.	github.com/google-ai-edge/gallery → skills/

Google AI Edge Gallery merece una nota: es la prueba de que el formato no está atado al escritorio. Un directorio con SKILL.md puede alimentar a un modelo que corre en un teléfono.

Productos verticales

Skills al servicio de un dominio concreto — datos, infraestructura, salud, automatización de escritorio — más que de “escribir código de aplicación”.

Cliente	Qué es	Documentación de skills
Databricks Genie Code	Agente autónomo para trabajo de datos dentro de Databricks.	docs.databricks.com/aws/en/assistant/skills
Snowflake Cortex Code	Agente integrado en Snowflake para ingeniería de datos, analítica, ML y construcción de agentes.	docs.snowflake.com/en/user-guide/cortex-code/extensibility#extensibility-skills
Pulumi Neo	Agente que gestiona infraestructura cloud con Pulumi desde Pulumi Cloud, CLI, GitHub y Slack, bajo las políticas y aprobaciones de la organización.	pulumi.com/docs/ai/skills/
Agentman	Plataforma agéntica de salud que automatiza flujos de ciclo de ingresos de forma testeable, trazable y auditable.	agentman.ai/agentskills
Vita	Trabajadores digitales autónomos con escritorios virtuales que ejecutan flujos de trabajo completos.	vita-ai.net/docs/features/agent-skills

Lecturas que sí se sostienen sobre los datos

• La superficie no determina el soporte. Hay skills en terminal, en IDE, en la nube, dentro de frameworks y hasta en móvil.
• El formato cruza proveedores de modelo. Anthropic (Claude, Claude Code), Google (Gemini CLI, AI Edge Gallery), OpenAI (ChatGPT & Codex), Mistral (Vibe), DeepSeek (Deep Code), ByteDance (TRAE), Microsoft y GitHub (VS Code, Copilot), Block (Goose), JetBrains (Junie).
• Los verticales de datos e infraestructura adoptaron el mismo formato para tareas que no son escribir código de aplicación: Databricks, Snowflake y Pulumi.

Lo que no puedes deducir de la lista: qué cliente implementa qué etapa del ciclo de vida. La guía oficial para implementadores describe patrones genéricos y nunca los atribuye a productos concretos. Para eso hay que ir a la documentación de cada cliente — la columna de la derecha en las tablas de arriba.

Qué fija el estándar

Todo lo que sigue está en specification.md y es idéntico en cualquier cliente conforme. Es el terreno firme sobre el que puedes construir.

• Una skill es un directorio que contiene, como mínimo, un SKILL.md.
• SKILL.md DEBE (must) contener frontmatter YAML seguido de contenido Markdown.
• Los campos del frontmatter y sus restricciones son exactamente estos seis:

Campo	Requerido	Restricción
name	Sí	1–64 caracteres; minúsculas alfanuméricas y guiones; sin guion inicial ni final; sin guiones consecutivos; DEBE coincidir con el nombre del directorio padre
description	Sí	1–1024 caracteres, no vacía; DEBERÍA (should) describir qué hace y cuándo usarla
license	No	Nombre de licencia o referencia a un archivo de licencia empaquetado
compatibility	No	1–500 caracteres si se provee; requisitos de entorno
metadata	No	Mapa de claves string a valores string
allowed-tools	No	String separada por espacios de herramientas preaprobadas. Experimental

• El cuerpo Markdown no tiene restricciones de formato: “write whatever helps agents perform the task effectively”.
• Un directorio de skill PUEDE (may) contener cualquier archivo o directorio más allá del SKILL.md requerido. scripts/, references/ y assets/ son convenciones recomendadas, no obligaciones.
• Las referencias entre archivos usan rutas relativas desde la raíz de la skill. Mantenerlas a un nivel de profundidad desde SKILL.md y evitar cadenas anidadas es una recomendación de la spec, redactada en imperativo, no un should normativo.
• La divulgación progresiva en tres niveles es el modelo de carga descrito: metadatos (~100 tokens) → instrucciones (< 5000 tokens recomendados) → recursos bajo demanda.
• La validación de referencia se hace con skills-ref validate ./my-skill.

Ojo con confundir recomendación y requisito. Los límites duros son tres: name ≤ 64 caracteres, description ≤ 1024 caracteres y compatibility ≤ 500 caracteres. Las 500 líneas de SKILL.md y los 5000 tokens del cuerpo son recomendaciones explícitas (“recommended”, “keep your main SKILL.md under 500 lines”), no restricciones validadas. El capítulo 3 desarrolla cada campo.

Qué queda a criterio del cliente

Y aquí está la otra mitad del cuadro. La guía oficial para implementadores enumera un conjunto largo de decisiones que la especificación no toma.

flowchart LR
    S["specification.md<br/>qué hay DENTRO<br/>de una skill"] --> P["Portable<br/>por construcción"]
    C["Decisión del cliente<br/>dónde viven · cómo se activan<br/>qué ve el modelo"] --> R["Riesgo de<br/>no portabilidad"]
    P --> K["Skill que corre<br/>en cualquier cliente conforme"]
    R --> K

Decisión	Opciones que la fuente reconoce como válidas
Dónde viven los directorios de skills	La spec no lo manda: solo define qué va dentro. .agents/skills/ es una convención emergente de amplia adopción, no un requisito
Ámbitos escaneados	Proyecto, usuario, organización, skills empaquetadas con el propio agente
Precedencia ante colisiones de name	Convención universal: proyecto gana sobre usuario. Dentro del mismo ámbito, first-found o last-found, a elección, siendo consistente
Estrictez de la validación	Estricta (la de la spec) o laxa: avisar y cargar igual si el nombre no coincide con el directorio o excede 64 caracteres; saltar la skill solo si falta description o el YAML es imparseable
Momento de leer el cuerpo	En el descubrimiento (activación más rápida) o en la activación (menos memoria y recoge cambios del archivo)
Formato del catálogo	XML, JSON o lista con viñetas
Ubicación del catálogo	Sección del system prompt o descripción de la herramienta de activación
Mecanismo de activación	Lectura de archivo, herramienta dedicada tipo activate_skill, o ambos
Qué recibe el modelo al activar	Archivo completo con frontmatter, o solo el cuerpo con el frontmatter eliminado
Sintaxis de activación explícita por el usuario	Libre: /skill-name, $skill-name u otra
Gating por confianza del proyecto	Opcional pero sugerido para skills provenientes de repositorios no confiables
Filtrado del catálogo	Por ajuste del usuario, por permisos o por opt-out del modelo. Regla firme: ocultar por completo, no listar y bloquear al activar
Lenguajes soportados en scripts/	Dependen de la implementación; opciones comunes: Python, Bash y JavaScript
allowed-tools	Campo experimental: el soporte puede variar entre implementaciones
Delegación a subagente	Patrón avanzado soportado solo por algunos clientes
Protección frente a compactación	Recomendada, pero es responsabilidad del harness

Dos matices que conviene fijar bien, porque son fuente habitual de afirmaciones erróneas:

.agents/skills/ no es norma. La cita literal de la guía es que “la especificación de Agent Skills no manda dónde viven los directorios de skills — solo define qué va dentro de ellos”; escanear .agents/skills/ se recomienda porque hace que las skills instaladas por otros clientes conformes sean visibles para el tuyo, y viceversa. .claude/skills/ aparece descrito como un escaneo adicional que algunas implementaciones hacen “por compatibilidad pragmática”, ya que muchas skills existentes están instaladas ahí. Ninguno de los dos es parte del estándar. El capítulo 10 entra en las rutas concretas.

El bloque <available_skills> tampoco es obligatorio. Es el formato que Anthropic usa y recomienda para modelos Claude, y el que genera skills-ref to-prompt; la propia documentación aclara que los clientes pueden formatear esa información de otra manera según el modelo que usen.

Cómo escribir un skill portable

La regla operativa se deduce de la tabla anterior: apóyate en lo que fija la especificación e ignora lo que resuelve el cliente. En la práctica, seis reglas.

1. Trata SKILL.md como el único contrato

name, description y cuerpo Markdown. Nada más está garantizado. Si tu skill necesita que exista un archivo de configuración propietario junto al SKILL.md para funcionar, ya no es portable.

2. Rutas relativas desde la raíz de la skill, siempre

Consulta [la guía de referencia](references/REFERENCE.md) para los detalles.

Ejecuta el script de extracción:
python3 scripts/extract.py --input datos.csv

Nunca rutas absolutas, nunca ~/.claude/skills/mi-skill/scripts/extract.py, nunca ../otra-skill/. La guía para implementadores instruye al modelo a resolver las rutas relativas contra el directorio de la skill — el padre de SKILL.md — y usar rutas absolutas en las llamadas a herramientas. Ese trabajo es del cliente; tú solo escribes la ruta relativa.

3. Declara el entorno en compatibility, no lo asumas

Si tu skill necesita jq, Docker o Python 3.14, dilo:

compatibility: Requires git, docker, jq, and access to the internet

Es el único canal estándar para comunicar requisitos de entorno, y el campo existe precisamente para eso. Recuerda el límite de 500 caracteres y que la mayoría de las skills no lo necesitan.

4. No dependas de allowed-tools

La especificación lo marca como experimental y advierte que el soporte PUEDE variar entre implementaciones. Úsalo como optimización si tu cliente principal lo respeta, pero el skill debe funcionar igual en un cliente que lo ignore por completo. Que un comando se autorice o no es una decisión del harness.

5. Escribe scripts para shells no interactivos

La guía de scripts marca esto como “un requisito duro del entorno de ejecución de agentes”: los agentes operan en shells no interactivos, y un script que se bloquee esperando entrada colgará indefinidamente. Acepta entrada por flags, variables de entorno o stdin, y documenta la interfaz con --help.

Además, los lenguajes soportados en scripts/ dependen de la implementación. Python, Bash y JavaScript son las opciones comunes; si eliges otra, estás acotando en qué clientes corre tu skill. El capítulo 7 cubre los patrones de scripts autocontenidos.

6. Prueba el disparo en más de un cliente

La description es el mecanismo por el que el agente decide cargar la skill, pero el catálogo llega al modelo en formatos distintos según el cliente, y el modelo mismo cambia. Una descripción afinada contra un solo modelo puede disparar peor en otro. El bucle de evaluación del capítulo 6 es reutilizable: cambia la función que detecta la invocación por la de cada cliente y vuelve a medir.

Suposiciones que hay que evitar

Suposición	Por qué falla
”El modelo verá el frontmatter cuando active la skill”	Depende del cliente: unos entregan el archivo completo, otros solo el cuerpo. Ambos enfoques funcionan. No pongas instrucciones ejecutables en el frontmatter
”Mi skill vive en .claude/skills/, así que puedo referenciar esa ruta”	La ubicación es decisión del cliente y del usuario. Referencia siempre rutas relativas
”Puedo cargar otra skill desde esta”	La especificación no define composición entre skills. Si dos flujos se necesitan, o son una sola unidad coherente o se documenta la dependencia en prosa
”El usuario la invocará con /mi-skill”	La sintaxis de activación explícita es libre. No escribas instrucciones que dependan de un prefijo concreto
”El cuerpo puede tener 3000 líneas, la spec no lo prohíbe”	No lo prohíbe, pero el agente carga el archivo entero al activar. Las 500 líneas recomendadas existen por coste de contexto, no por validación
”El nombre puede ser distinto del directorio si el cliente es tolerante”	Algunos clientes avisan y cargan igual, pero la spec dice DEBE coincidir. Un cliente estricto la rechazará
”Los recursos de references/ se leerán solos”	El cliente lista los recursos empaquetados, no los lee con avidez. Si quieres que se lean, di explícitamente cuándo: “lee references/api-errors.md si la API devuelve un status distinto de 200”

Checklist de portabilidad

mi-skill/
- SKILL.md     # name coincide con el directorio; description autosuficiente
- scripts/     # sin prompts interactivos; --help documentado
- references/  # cargados bajo condición explícita
- assets/      # plantillas y datos estáticos

• skills-ref validate ./mi-skill pasa sin errores.
• name coincide exactamente con el nombre del directorio.
• description describe qué hace y cuándo usarla, bajo 1024 caracteres.
• Ninguna ruta absoluta ni ninguna ruta que salga del directorio de la skill.
• Ningún nombre de producto en las instrucciones salvo que sea un requisito real declarado en compatibility.
• La skill funciona si el cliente ignora allowed-tools.
• Los scripts corren en un shell no interactivo y su salida es acotada.
• Cada archivo de references/ tiene una condición de carga escrita.

Dónde encaja esto con los cursos hermanos

El showcase lista clientes, no mecanismos de distribución. Cuando un skill deja de ser un directorio suelto y pasa a empaquetarse junto a servidores MCP y otras piezas, entra en juego otro estándar: el curso Agent Plugins Spec cubre ese formato de empaquetado.

Y si quieres ver cómo se ve el estándar aplicado a escala por un proveedor, el curso Google Skills recorre su catálogo oficial de más de 100 skills reales — un buen banco de pruebas para contrastar las reglas de portabilidad de este capítulo contra skills publicadas.

Un aviso final: el repositorio oficial no mantiene un directorio de skills de la comunidad y no acepta envíos de skills. No existe un marketplace oficial; lo que hay son repositorios de ejemplos y catálogos de terceros.

Resumen

• El showcase oficial lista 44 clientes en el estado consultado del repositorio. Es una lista de altas por pull request con un criterio de inclusión — producto público que descubre y ejecuta skills hoy — no un censo del ecosistema ni un ranking.
• La agrupación en cinco familias (terminal, IDE, nube, runtimes, verticales) es una ayuda de lectura: la fuente publica una lista plana y baraja su orden.
• El formato cruza proveedores de modelo, superficies y dominios: hay skills en terminal, IDE, nube, frameworks, móvil, plataformas de datos y de infraestructura.
• El estándar fija qué hay dentro de una skill: directorio con SKILL.md, seis campos de frontmatter con sus límites, cuerpo Markdown libre, rutas relativas y divulgación progresiva en tres niveles.
• El cliente decide todo lo demás: dónde viven los directorios, la precedencia entre ámbitos, la estrictez de validación, el formato del catálogo, el mecanismo de activación, si el modelo ve el frontmatter, los permisos y los lenguajes ejecutables soportados.
• .agents/skills/ es una convención emergente de interoperabilidad, no un requisito de la especificación; .claude/skills/ es compatibilidad pragmática de algunas implementaciones.
• Un skill portable se apoya solo en el contrato: rutas relativas, requisitos en compatibility, scripts no interactivos, cero dependencia de allowed-tools y ninguna suposición sobre la ubicación, la sintaxis de invocación o si el modelo verá el frontmatter.

Siguiente: Implementar soporte de skills en tu propio agente