Claude Skills No Son Plugins ni Prompts. Son un Formato de Fichero — y Eso lo Cambia Todo

La Feature de IA Más Hypeada de 2025 es un Fichero Markdown en una Carpeta

Claude Skills — anunciadas el 16 de octubre de 2025 junto a Claude 3.5 Haiku — contienen cero código compilado, no necesitan arquitectura de plugins, y toda su "magia de IA" se reduce a un campo YAML description que el modelo lee para decidir cuándo actuar.

*Si entendéis lo que eso significa de verdad, vuestros workflows de IA se vuelven mil veces más mantenibles — y dejáis de copiar-pegar las mismas instrucciones en cada prompt. *

El relato convencional tras el anuncio fue tratar las Skills como "plugins", como "tools", o como un rebranding de las custom instructions. El relato asume que el valor vive en el modelo.

Error. El valor vive en el fichero. Y la jugada maestra es procedural, no de modelo.

El Error: Tratarlas Como Prompts de Sistema con Botón de Guardar

Si usas Claude Code y has creado una skill que es básicamente "actúa como un senior de producto", estás repitiendo el error del monolito.

❌ La skill monolítica tipo "persona": "Eres un desarrollador senior experto en TypeScript"

Eso es un system prompt disfrazado. No se auto-invoca, no se versiona con sentido, y no resuelve ningún problema real.

✅ La micro-skill atómica: "Revisa este blog post y comprueba que el tono coincide con la guía de estilo: sin anglicismos, sin hipérbole de IA, con datos concretos"

Eso es un procedimiento. Algo que se ejecuta, se revisa con un diff, y se mejora con un pull request.

Qué No Es una Skill (Y Dónde Confundís Todo el Mundo)

Hay tres malentendidos que veo en cada agencia con la que hablo:

1. No contienen código ni cambios de modelo. El mecanismo entero es un fichero Markdown cuyo campo description actúa como gancho de recuperación. Claude lee ese description, lo compara semánticamente con tu tarea, y decide si activa la skill. Sin código de orquestación. Sin runtime especial.

2. No compiten con los servidores MCP — los completan. MCP responde a "¿qué herramientas existen?". Las Skills responden a "¿cómo hacemos bien esta tarea?". Están diseñados para combinarse, no para elegir uno. Si elegís "skills OR MCP", os estáis perdiendo el punto: el diseño asume "skills AND MCP".

3. Convierten la ingeniería de prompts en ingeniería de software. Como las skills viven en directorios, se versionan con git, se revisan, se diffean y se distribuyen como código. Es la primera vez que un comportamiento de un agente tiene semántica de control de versiones de primera clase.

*Ese último punto es la historia real: "mejorar la IA" pasa a significar mergear un pull request. *

## La Evidencia: Un Formato de Fichero, No un Nuevo Modelo

Mirad el contrato. Una skill se define con un único fichero Markdown con frontmatter YAML que contiene name y description, seguido de instrucciones Markdown. Eso es todo:

Fijaos en cómo está escrito el description. Actúa como un contrato de API: cuándo disparar, cuándo NO disparar, y la forma del output esperado. Esa no es una descripción bonita — es el sistema entero de recuperación.

La Instalación es Tan Aburrida Como Debería Ser

Las skills son simples directorios en disco. Las personales viven en ~/.claude/skills/ y las de proyecto en .claude/skills/.

Y las skills pueden empaquetar assets ejecutables. Fijaos en que el SKILL.md de arriba referencia scripts/check_terms.py — un helper que viaja como fichero hermano dentro de la propia carpeta de la skill:

Antrophpic ya envía al menos una skill por defecto con Claude Code — una skill de procesamiento de PDF — demostrando el formato en producción. Y el mismo fichero de skill funciona en claude.ai, iOS, Android, la API y Claude Code. Esa portabilidad es algo que los ecosistemas de plugins históricamente nunca consiguieron.

Composición: Skills = Cómo, MCP = Qué/Dónde

Aquí está el patrón que la mayoría aún no usa. Una skill puede instruir a Claude para que llame a una herramienta MCP a mitad del procedimiento.

Imaginad una skill de revisión de migraciones de esquema en Postgres. La skill aporta el procedimiento ("comprueba en este orden, con estos quality gates"). Y en mitad del procedimiento, le dice a Claude que consulte un servidor MCP de Postgres para ver el esquema real:

Ese es el patrón canónico. MCP aporta el acceso a datos en vivo; la skill aporta el procedimiento que decide cómo procesar esos datos. Elegir uno sobre el otro es no entender la arquitectura.

El Marco de 5 Pasos: Skill de Auditoría a Producción

Vamos a convertir eso en un método. Lo llamo el Marco de la Skill Versionada y así es como lo aplicáis vosotros:

1. Auditar: Buscad Vuestras Tareas Repetitivas

Listad vuestras 3-5 tareas de Claude más repetitivas que hoy re-explicáis en cada prompt: revisión de código, revisión de migraciones, estilo de contenido. Esas son vuestras candidatas a skill. Si la re-explicáis más de dos veces, merece una skill.

2. Autor: Escribid el Contrato Antes que el Contenido

Para cada candidata, escribid un SKILL.md. Pero el 80% de la calidad está en el description. Escribidlo como un contrato de API:

Condiciones explícitas de disparo ("úsalo cuando...")
Disparadores negativos explícitos ("NO lo uses para...")
La forma del output esperado

Un description vago significa que la skill nunca se dispara. Silenciosamente. Es el mismo fallo que los nombres de funciones en el tool-calling de los LLM.

3. Instalar y Verificar

Dropead la carpeta en ~/.claude/skills/ (personal) o .claude/skills/ (de proyecto). Verificad que aparece con /skills en Claude Code. Si no aparece, el frontmatter está mal — linted vuestro YAML.

4. Probar Ambos Modos de Invocación

El emparejamiento es probabilístico. Un description mal escrito significa no-invocación silenciosa. Por eso tenéis que probar dos caminos:

Dejad que la auto-invocación se dispare con una tarea realista.
Forzad /skills es-review con la misma tarea.

El gap entre los dos outputs os dice lo buena que es vuestra descripción. Si la invocación explícita es mucho mejor que la automática, el contrato falla — afinar la descripción, no el cuerpo.

5. Versionar y Componer

git init la carpeta de skills. Iterad sobre las instrucciones con git diff. Y compartid el repo con vuestro equipo.

Ahora "mejorar el comportamiento del agente" significa abrir un pull request, no copiar-pegar un prompt en Slack. El drift de prompts se puede auditar, los cambios se pueden revertir igual que un bug de código, y cada skill mantiene su política usando una estrategia idéntica a la del código.

El Futuro es Gobernanza: ¿Quién Es Dueño de la Skill?

Si los procedimientos se convierten en ficheros distribuibles, esperad marketplaces de skills y registries internos de empresa. La unidad de "mejor práctica de IA" pasa de templates de prompt en blog posts a repos de skills versionados — Anthropic ya publica skills de ejemplo en su GitHub público anthropics/skills.

La pregunta a largo plazo es gobernanza. ¿Quién es dueño de la skill? ¿Quién revisa los cambios en el comportamiento del agente? ¿Y cómo testeas un cambio en un SKILL.md antes de que llegue a tus prompts de producción?

La respuesta honesta: todavía nadie lo ha resuelto. Pero el hecho de que podamos plantearlo — que un cambio en el comportamiento de un agente sea diffable y revertible — es la novedad real.

Conclusión: Las Skills Son la Primera Primitiva Agentica con Versionado Real

El resumen, en tres frases:

No son plugins ni prompts. Son un formato de fichero: un SKILL.md cuyo description es el motor de recuperación entero.
Componen con MCP, no compiten. Skills = cómo; MCP = qué/dónde.
El git-native es la feature silenciosa. "Mejorar la IA" se convierte en mergear un pull request.

Una nota final de cautela: no hay métricas públicas creíbles sobre adopción ni sobre ganancias de calidad medibles. Evaluad las skills por demostración, no por números de vendedor.

*El hecho de que el comportamiento de un agente se haya convertido en código versionable no es un detalle de implementación. Es el punto. * Los workflows que construyáis hoy con esa mentalidad — procedimientos como contratos, auditable el cambio a un agente, revisado por pull request — no son una estrategia de prompts. Son los primeros cimientos de una disciplina que aún no tiene nombre, pero que ya está aquí: la ingeniería real de comportamiento de agentes.