La respuesta corta

Los skills reutilizables de agente están más cerca de ser portables que casi cualquier otra función de IA que hayas usado, pero no son plug-and-play. Los Claude Skills se organizan como carpetas planas con un archivo SKILL.md en la raíz: metadatos en YAML más instrucciones en markdown, opcionalmente con scripts y documentos de referencia adjuntos. Como en esencia son archivos en disco, cualquier asistente con acceso a filesystem y un intérprete de código puede leerlos. En la práctica, cómo se comporte depende de cuánto se apoye el skill en suposiciones específicas de Claude.

Para un fundador independiente, la pregunta práctica no es “¿el formato es igual en todas partes?”, sino “si construyo mi flujo como un skill hoy, cuánto rewrite tendré que hacer si cambio de asistente en seis meses?”. Aquí va cómo pensarlo.

Cómo funcionan realmente los Claude Skills

Un Claude Skill es un directorio. El archivo mínimo obligatorio es SKILL.md, que empieza con frontmatter en YAML seguido de un cuerpo en markdown.

El frontmatter tiene dos campos obligatorios:

  • name: un identificador en minúsculas con guiones, que coincide con el nombre de la carpeta padre
  • description: una explicación corta de qué hace el skill y cuándo usarlo

Hay varios campos opcionales que también pueden ir en el frontmatter: un license, una nota de compatibility describiendo requisitos del entorno, un mapa metadata arbitrario y un campo experimental allowed-tools que lista qué herramientas puede invocar el skill.

Claude carga los skills por etapas, lo que Anthropic llama progressive disclosure. Al iniciar una sesión, el modelo solo ve name y description de cada skill disponible — aproximadamente 100 tokens por skill. Es suficiente para que Claude detecte cuándo un skill podría ser relevante. Si la tarea coincide, se carga el cuerpo completo de SKILL.md. Para skills más complejos, el cuerpo puede enlazar a archivos adicionales dentro de la carpeta del skill — documentos de referencia, plantillas, scripts — y el modelo los lee solo cuando los necesita.

Por qué importa para la portabilidad: el formato es intencionalmente minimalista. No hay un binario propietario, ni un artefacto compilado, ni un runtime oculto. Puedes abrir la carpeta de un skill en cualquier editor de texto y leerlo.

Qué significa “portable” hoy, en términos reales

Anthropic publicó el formato de Agent Skills como un estándar abierto en agentskills.io, con una especificación pública. Es la señal más clara de que la compañía pretende que los skills sobrevivan a cualquier proveedor.

El formato en sí es directo:

  • Un directorio
  • Un SKILL.md con frontmatter en YAML y markdown
  • Subcarpetas opcionales como scripts/, references/, assets/
  • Cualquier archivo extra que quieras incluir

Entonces, si copias esa carpeta al entorno de otro asistente — uno que pueda leer archivos, ejecutar scripts y seguir instrucciones en markdown — la estructura será reconocible. Una definición de trabajo razonable de portable en este espacio es: la carpeta del skill se puede soltar en el directorio de skills de otro asistente y producir un comportamiento útil, con a lo sumo ediciones menores en las instrucciones.

Lo que aún no está estandarizado es todo lo que rodea al skill:

  • Cómo descubre cada asistente los skills instalados
  • Cómo decide que un skill es relevante
  • Qué herramientas puede invocar el skill
  • Dónde se ejecutan los scripts y con qué permisos

Ahí vive la fricción real de portabilidad.

Dónde se esconde el lock-in dentro de un skill

Incluso cuando el formato de archivo es abierto, los skills pueden encerrarte silenciosamente con un asistente concreto. Atento a estos patrones.

1. Referencias hardcodeadas a herramientas de un proveedor. Un skill que dice “usa la herramienta PDF de Claude” o asume un esquema específico de function calling solo funcionará donde esas herramientas existan. Mejor escribir instrucciones que describan el resultado deseado y luego verificar si el asistente de destino tiene la capacidad equivalente.

2. Dependencia del entorno VM. Los Claude Skills están diseñados para correr dentro de la máquina virtual de Claude, con acceso a filesystem e intérprete de código. Si tu skill asume “puedo leer cualquier archivo al que el usuario tenga acceso”, esa suposición puede no transferirse a un asistente hospedado con un entorno sandboxed.

3. El campo allowed-tools. Este campo experimental, específico de Claude, lista las herramientas preaprobadas que el skill puede usar. Otros asistentes pueden no parsearlo, o pueden interpretar los permisos de herramientas de forma distinta. Skills que dependen mucho de permisos de herramientas específicas necesitarán reescribirse en la plataforma de destino.

4. El wording de descubrimiento. El campo description es lo que cada asistente lee para decidir si carga el skill. Distintos asistentes pueden parsear esa descripción de forma distinta, pesarla distinto, o usar lógica de matching diferente. Una descripción ajustada al comportamiento de matching de Claude puede dispararse demasiado, demasiado poco, o no dispararse en absoluto en otro asistente.

5. Scripts en un solo lenguaje. Los skills a menudo vienen con scripts en Python. Está bien si tu asistente de destino también soporta ejecución de Python. Si no, tendrás que portar los scripts o aceptar funcionalidad reducida.

6. Suposiciones sobre el tamaño del contexto. El diseño de progressive disclosure de Claude asume una ventana de contexto generosa. Un asistente con límites más estrechos puede cargar el skill completo de una vez y comportarse distinto, o no cargar documentos de referencia grandes.

Ninguno de estos es un deal-breaker por sí solo. El riesgo aparece cuando se acumulan — un skill que asume la VM de Claude, una herramienta específica, ejecución de Python y un wording de descubrimiento ajustado se comportará de forma muy distinta en otro lugar.

Una vista desde la trinchera del fundador

Si eres fundador independiente o un equipo pequeño, el costo real del lock-in no son las licencias — es reconstruir tus flujos. Un skill que automatiza el borrador de facturas, el triaje de emails de onboarding de clientes o el reporte semanal es valioso precisamente porque corre de forma confiable cada semana. Si cambiar de asistente significa reescribir ese flujo desde cero, vas a dudar en cambiar incluso cuando un competidor ofrezca mejor precio o capacidad.

Ese es el ángulo para evaluar la portabilidad: no “¿se va a copiar el archivo?”, sino “si decido irme, cuántas horas de rewrite estoy firmando?”.

Para la mayoría de fundadores, hoy la respuesta es: un skill bien escrito se porta con ediciones menores. Uno mal escrito — que se apoya mucho en funciones específicas de Claude, con wording de descubrimiento vago y scripts muy acoplados — necesitará un rework sustantivo.

Checklist para escribir skills que envejezcan bien

Usa esto cuando te sientes a escribir un skill nuevo, o cuando audites los que ya tienes.

Mantén la descripción portable. Escribe la description de modo que describa la tarea y las condiciones de disparo en lenguaje claro, sin frases específicas de un asistente. Busca un wording que siga teniendo sentido si un equipo distinto, usando otro asistente, lo lee en frío.

Evita nombres de herramientas específicas del proveedor en el cuerpo. Donde sea posible, describe qué debe hacer el skill, no a qué función nombrada llamar. Si un paso realmente requiere una capacidad específica — digamos, “generar un PDF” — verifica que el asistente de destino tenga un equivalente antes de comprometerte.

Empaqueta scripts con moderación y prefiere el runtime más común. Python es hoy la suposición más segura entre asistentes. Si necesitas usar otro lenguaje, anótalo en el campo compatibility para no sorprenderte en el futuro.

Apóyate en progressive disclosure. Pon las instrucciones núcleo en SKILL.md y enlaza hacia documentos de referencia más largos. No es solo una buena práctica de Claude — es buen diseño para cualquier asistente que pueda tener presupuestos de contexto más ajustados.

Usa el campo compatibility. La especificación del formato soporta una nota de compatibility describiendo requisitos de entorno, productos objetivo, paquetes del sistema y acceso de red. Llénalo. Tú en el futuro, o un compañero, te lo agradecerá.

Mantén los skills pequeños y enfocados. La guía de Anthropic favorece “micro-skills” que se encadenan en lugar de un único skill monolítico. Skills más pequeños son más fáciles de portar, de debuggear y de retirar.

Documenta tus suposiciones. Dentro del cuerpo del skill o en un README adjunto, anota qué funciones del asistente dependes. Si asumes acceso a filesystem, dilo. Si asumes un intérprete de código, dilo.

Prueba en un segundo asistente antes de depender del skill. Si la portabilidad te importa, la única prueba real es soltar la carpeta en el entorno de otro asistente y ver qué pasa. Hazlo temprano, no después de seis meses apoyándote en él.

Versiona tus skills. Usa un bloque metadata en el frontmatter para registrar autor y versión. Los skills evolucionan; trackear qué versión está en uso ahorra confusiones después.

Trata la spec como algo en movimiento. El estándar de Agent Skills está publicado abiertamente, pero todavía es joven. Nombres de campos, campos opcionales como allowed-tools y el comportamiento de descubrimiento pueden cambiar. Construye con la suposición de que vas a revisar la spec periódicamente.

Preguntas frecuentes

¿Los Claude Skills y los skills de ChatGPT son lo mismo?

Comparten el espíritu — instrucciones reutilizables y específicas por tarea — pero las implementaciones concretas difieren. Los Claude Skills usan el formato abierto de Agent Skills con un SKILL.md y una estructura de carpetas. La función equivalente en ChatGPT, a menudo llamada Custom GPTs o GPT actions, usa un enfoque de configuración distinto. El estándar abierto compartido en agentskills.io es lo más cercano a un formato común que existe hoy.

¿Mi Claude Skill funcionará en ChatGPT sin cambios?

Probablemente no sin cambios. La estructura de archivos puede transferirse, pero el wording de descubrimiento, el acceso a herramientas y el entorno de ejecución difieren. Esperá editar la description y revisar cualquier referencia a herramientas específicas de proveedor antes de que se comporte igual en otra plataforma.

¿El formato de Agent Skills es estable?

La especificación está publicada abiertamente y Anthropic ha manifestado la intención de que los skills sean portables entre productos. Dicho esto, el estándar es joven y campos específicos — sobre todo los experimentales como allowed-tools — pueden evolucionar.

¿Cuál es el skill más chico que puedo escribir?

Un archivo SKILL.md con solo name y description en el frontmatter, más un cuerpo corto en markdown. Es suficiente para probar si el wording de descubrimiento dispara correctamente antes de invertir en scripts y documentos de referencia.

¿Vale la pena pensar en portabilidad si solo uso un asistente?

Sí, modestamente. Los hábitos que hacen portable a un skill — descripciones claras, wording neutral de proveedor, suposiciones documentadas, alcance pequeño y enfocado — también hacen que los skills sean más fáciles de mantener, de debuggear y de pasar a un colaborador. La disciplina de portabilidad cuesta poco y rinde incluso si nunca cambias.

Qué hacer a continuación

Si estás empezando desde cero, el experimento más barato es escribir un skill pequeño — elegí una tarea recurrente que hoy hacés a mano — y probarlo primero en Claude. Después copiá la carpeta al entorno de un segundo asistente y mirá qué pasa. La fricción que aparezca en esa segunda copia es la fricción que enfrentarías a escala más adelante.

Si ya tenés una biblioteca de skills, auditá el más pesado contra la checklist de arriba. Las respuestas te van a decir si tu flujo actual sobreviviría un cambio de plataforma, y qué arreglar primero.

Fuentes