Claude Skills 2026: cuándo crear una propia y cuándo no

TL;DR: Las Claude Skills dejaron de ser prompts bonitos para convertirse en bloques reutilizables y versionables. Crea una skill propia cuando una tarea cumple tres condiciones: la repites 3 o más veces por semana, exige consistencia entre sesiones y la compartes con tu equipo. Si no, basta con un prompt en sesión o una entrada en CLAUDE.md. Esta guía explica los criterios, la estructura mínima de un SKILL.md y qué cambia entre el tutorial y producción real.

Por qué ahora hablamos de skills, no de prompts

A abril de 2026, el repositorio awesome-claude-skills de ComposioHQ supera las 56.000 estrellas y la spec abierta en agentskills.io ya está soportada por más de 26 herramientas (Claude Code, Cursor, Codex, Gemini CLI). El patrón se consolidó: una skill es una carpeta con un SKILL.md que cualquier agente compatible puede descubrir y cargar bajo demanda.

El problema de fondo es viejo: cada sesión empieza desde cero. Cada vez que abres una conversación nueva, repites los mismos 400 palabras de contexto sobre tu stack, tus convenciones y cómo quieres que el agente formatee las salidas. La skill es la carpeta donde ese contexto vive una sola vez y se invoca cuando la tarea coincide.

El cambio interesante para el desarrollador no es la novedad técnica. Es que ahora hay catálogos curados, formato estándar y un patrón de mantenimiento que aguanta varias semanas sin romperse. Eso convierte la skill en una decisión de ingeniería, no en un experimento.

¿Qué es exactamente una Claude Skill?

Una Claude Skill es un paquete de instrucciones reutilizables, definidas en un archivo SKILL.md, que el agente carga solo cuando una tarea coincide con su descripción. Vive en una carpeta del filesystem, contiene metadatos en YAML y un cuerpo en Markdown, y puede incluir scripts o referencias secundarias.

La pieza que la hace escalar es la progressive disclosure, el mismo patrón que documenta Anthropic en su blog de ingeniería. Funciona en tres niveles:

• Nivel 1 (siempre cargado): nombre y descripción del frontmatter YAML, alrededor de 100 tokens por skill.
• Nivel 2 (cargado bajo demanda): el cuerpo de SKILL.md, cuando el modelo decide que la skill aplica.
• Nivel 3 (cargado solo si hace falta): archivos auxiliares en references/, scripts/ o assets/.

Esa arquitectura es la razón práctica para preferir una skill sobre un bloque pegado en CLAUDE.md: lo que no se usa, no consume contexto. Si tienes una guía de configuración avanzada que solo aplica a 1 de cada 20 sesiones, en CLAUDE.md ocupa tokens siempre. Como skill, ocupa 100 hasta que la necesitas.

Cuándo merece la pena crear una skill propia

Esta es la pregunta clave al integrar skills en un flujo diario. La respuesta corta: solo cuando una tarea cumple al menos tres de estas cuatro condiciones.

Criterio	Umbral práctico	Por qué importa
Frecuencia	3+ veces por semana	Por debajo, el coste de mantener la skill supera el ahorro
Consistencia	La salida sigue un formato fijo	Si cada vez la quieres distinta, mejor un prompt
Composición	La tarea encadena 3+ pasos	Una sola instrucción rara vez justifica una skill
Compartido	La usa más de una persona o proyecto	El versionado en Git solo paga cuando hay reuso

Si tu tarea solo cumple una o dos condiciones, opciones más livianas funcionan mejor: una entrada en CLAUDE.md del proyecto, un slash command, o un prompt guardado en notas. La gestión de skills tiene un coste real: nombrarlas, mantenerlas y evitar que choquen entre sí cuando tienes 15 instaladas.

Estructura mínima de un SKILL.md

La spec oficial define dos campos obligatorios en el frontmatter: name (máx 64 caracteres, minúsculas, números y guiones) y description (máx 1024 caracteres). El cuerpo se recomienda mantener por debajo de 500 líneas; si crece más, mueve detalle a archivos referenciados.

Ejemplo real de una skill para revisar mensajes de commit antes de pushear, generándolos en formato conventional commits a partir del diff staged:

---
name: commit-message-helper
description: Genera mensajes de commit en formato conventional commits analizando el diff staged. Se activa cuando el usuario pide ayuda para escribir un commit o revisar cambios stageados antes de pushear.
---

# Commit Message Helper

## Pasos
1. Ejecuta `git diff --cached` para leer el diff staged.
2. Detecta el tipo: feat, fix, refactor, docs, test, chore.
3. Identifica el scope a partir de la ruta de los archivos modificados.
4. Redacta el subject en imperativo, máximo 72 caracteres.
5. Si hay más de 3 archivos tocados, añade body con bullet points.

## Restricciones
- No uses "Co-Authored-By".
- Mensajes en inglés salvo que el repo indique otra cosa.
- Si el diff está vacío, avisa y no inventes.

El detalle clave está en la descripción del frontmatter: define cuándo debe activarse, no qué hace. El modelo solo ve esa descripción al elegir si carga la skill, así que ambigüedad ahí significa que se activará cuando no toca o no se activará cuando sí.

Repos curados: por qué importan más que un prompt viral

El ecosistema curado es la señal de que esto pasó de moda a infraestructura. Tres referencias prácticas a abril de 2026:

• anthropics/skills: el repo oficial. Skills mantenidas por Anthropic, útiles como plantilla y para tareas de documentación o diseño.
• ComposioHQ/awesome-claude-skills: lista curada con más de 56.000 estrellas, agrupada por categoría (testing, devops, content, code review).
• awesomeskills.dev: directorio web con review de seguridad por skill (qué scripts ejecuta, si hace llamadas externas, si lee credenciales).

La diferencia frente a un prompt suelto en redes es el ciclo de mantenimiento. Una skill en un repo público recibe issues, pull requests y se actualiza cuando cambia la versión del modelo. Un prompt viral suele estar atado a un caso concreto y se rompe en silencio.

El patrón recomendado: empieza copiando una skill curada que se aproxime a tu caso, ajústala 10 minutos y comprométela en tu propio repo. Eso te da reuso sin reinventar y te enseña la estructura sin caer en la página en blanco.

Skills 2.0 y el eval loop integrado

Desde abril de 2026, Skills 2.0 incluye un eval loop opcional: un test automático que ejecuta la skill sobre entradas de muestra y compara las salidas antes de aprobar la versión. Funciona como un test unitario para tu prompt.

El valor real aparece cuando actualizas el modelo subyacente o tocas el cuerpo de la skill. Una skill de generación de README puede empezar a producir Markdown distinto al pasar de una versión del modelo a otra; el eval lo detecta antes de que llegue a tu PR.

Para la mayoría de skills personales no hace falta. Pero si una skill empieza a ser usada por más de dos personas o entra en un workflow de CI, añade al menos 3 casos de muestra. Es la diferencia entre un script que funciona en tu portátil y uno que aguanta producción, parecido a lo que aplica el principio de separación de responsabilidades en arquitectura de software.

En Producción

El tutorial muestra una skill bonita; producción pide unas cuantas reglas más:

• Token budget: 10 skills bien escritas suman alrededor de 1.000 tokens en frontmatter. 30 skills mal descritas pueden duplicar eso. Si ves al modelo confundir skills, el problema casi siempre está en descripciones genéricas, no en cantidad.
• Scope (user vs project): skills generales (commits, formato de PR) van a nivel usuario en ~/.claude/skills/. Skills específicas del proyecto van en .claude/skills/ dentro del repo. Mezclar ambos lleva a sobrescritura silenciosa.
• Coste de mantenimiento: cuenta unos 10-15 minutos al mes por skill activa para revisar que sigue dando salida correcta tras cambios de modelo. Con 20 skills, son 4 horas al mes; pasa de cierto número y compensa más usar menos skills más generales.
• Seguridad: antes de instalar una skill de tercero, revisa si ejecuta scripts (scripts/), si hace llamadas de red o si lee credenciales. El mismo principio defensivo aplicado a paquetes MCP aplica a skills externas.
• Versionado: commitea las skills propias en el repo del proyecto o en un repo dedicado. Como son archivos planos, git diff sobre SKILL.md funciona sin más, similar a gestionar esquemas con Prisma donde el archivo es la fuente de verdad.

Errores comunes y depuración

• Error: la skill no se activa nunca → Causa: descripción genérica tipo "ayuda con código" → Solución: incluye verbos y casos concretos: "se activa cuando el usuario pide refactorizar funciones de Python con type hints".
• Error: la skill se activa cuando no toca → Causa: nombre o descripción demasiado amplios → Solución: añade exclusiones explícitas en la descripción ("no usar para revisar tests").
• Error: el cuerpo crece a 800+ líneas y el modelo ignora partes → Causa: sobrepasaste el budget recomendado → Solución: mueve detalle a references/detalle.md y referéncialo desde el cuerpo.
• Error: dos skills se pisan → Causa: descripciones que solapan → Solución: renombra y especifica el caso ("commit-message-helper-monorepo" vs "commit-message-helper").

Preguntas frecuentes

¿Las Claude Skills sustituyen a los servidores MCP?

No. Skills aportan instrucciones y workflows reutilizables; MCP aporta herramientas activas como acceso a APIs o bases de datos. Pueden combinarse: una skill puede invocar un servidor MCP en su cuerpo. Si necesitas leer una base de datos en vivo, es trabajo de MCP, no de una skill.

¿Las skills se cargan siempre todas en contexto?

No. Solo el frontmatter (nombre y descripción) está siempre presente, alrededor de 100 tokens por skill. El cuerpo solo se carga cuando el modelo decide que la skill aplica al turno actual. Por eso una descripción precisa importa más que un cuerpo largo.

¿Puedo compartir skills entre Claude Code y Cursor?

Sí, con cambios mínimos. La spec abierta en agentskills.io define un formato compatible con más de 26 herramientas a abril de 2026, incluidos Cursor, Codex y Gemini CLI. Las skills textuales se mueven sin tocar nada; las que ejecutan scripts pueden requerir adaptar rutas.

Cierre

El cambio real de las skills no es técnico, es de mentalidad. Hemos pasado de tratar los prompts como mensajes desechables a tratarlos como código: con nombre, versión, mantenimiento y reuso. La regla práctica útil: si una tarea no se repite al menos tres veces por semana ni la comparte nadie más, no merece skill. Si cumple ambas, vale más invertir 20 minutos en escribirla bien que reteclear el contexto cada vez.

El siguiente paso natural es entender cómo las skills se combinan con subagentes y memoria persistente para sesiones largas. Si has empezado a usar skills en tu flujo, cuéntalo en Twitter @sergiomarquezp_: qué tarea fue la primera que migraste y qué tal está aguantando.