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:
```markdown
---
name: es-review
description: Revisa artículos técnicos en español (España). Úsalo cuando el escrito
tenga palabras/registro de LATAM, anglicismos innecesarios, o hipérbole de IA.
NO lo uses para código o para textos en inglés. Salida esperada: lista de
errores con la sugerencia de corrección en cada línea.
---
Revisión de estilo en español de España
1. Comprueba que todo "vosotros" se conjuga correctamente.
2. Marca anglicismos traducibles (order → pedido, insights → conclusiones).
3. Señala hipérbole de IA: "game-changer", "revolucionario", "la magia".
4. Si existe scripts/check_terms.py, ejecútalo y añade sus resultados.
```
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/`.
```bash
mkdir -p ~/.claude/skills/es-review
vim ~/.claude/skills/es-review/SKILL.md
escribe el fichero de arriba, guarda y sal
```
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:
```bash
mkdir -p ~/.claude/skills/es-review/scripts
scripts/check_terms.py: detector de anglicismos y frases prohibidas
se ejecuta como parte de la revisión
```
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:
```markdown
---
name: schema-migration-review
description: Revisa migraciones SQL de esquema. Úsalo cuando haya un fichero
.sql de migración en el PR. NO lo uses para consultas ad-hoc.
---
1. Consulta la tabla de migraciones via la herramienta MCP `postgres`.
2. Compara la migración nueva con el esquema vigente.
3. Marca: columnas NOT NULL sin default, renombrados sin uso, índices duplicados.
4. Exige un rollback explícito para cada cambio destructivo.
```
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.
```bash
cd ~/.claude/skills
git init
git add es-review/
git commit -m "feat: skill de revision de estilo es-ES"
tras una iteracion de prompt-tuning:
git diff es-review/SKILL.md
git push origin main
```
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:
1. No son plugins ni prompts. Son un formato de fichero: un SKILL.md cuyo `description` es el motor de recuperación entero.
2. Componen con MCP, no compiten. Skills = cómo; MCP = qué/dónde.
3. 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.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF