Skills de Claude Code: cuándo usarlas y cuándo sobran

Una Skill de Claude Code es una carpeta con un solo archivo dentro. Ese archivo se llama SKILL.md. Empieza con frontmatter YAML (un name y una description) y luego un cuerpo en markdown. Claude carga el cuerpo en el contexto solo cuando la description coincide con lo que el usuario acaba de pedir. La carga bajo demanda es todo el sentido del mecanismo.

La trampa: las Skills parecen contenido de CLAUDE.md que aprendió a esperar su turno. CLAUDE.md entra en cada prompt. Las Skills están en una estantería y aparecen solo cuando Claude las considera relevantes. Suena gratis. No lo es. Una description pesa unos 75-150 tokens una vez envuelta en XML, y con el presupuesto por defecto Claude Code mantiene visibles unas 15-25 descriptions en una ventana de 200K antes de que el truncado empiece a quitar algunas. Cada Skill ocupa un espacio que otra Skill no puede llenar.

Es el coste oculto que la mayoría de los equipos no ve al publicar su primer lote de Skills. Abajo, cuatro situaciones en las que una Skill gana su espacio, y cuatro en las que cuesta más de lo que aporta.

Cuándo una Skill se gana su espacio

Úsala cuando el procedimiento pasa de cinco líneas

Si pegas siempre la misma receta de cinco pasos en el chat (preparar la base de test con estas env, sembrarla con estas fixtures, lanzar este comando npm exacto, parsear la salida así, escribir el assert en este estilo), esa receta es una Skill. El cuerpo puede llegar a cientos de líneas sin engordar las sesiones que no lo necesitan. El coste está en la description del listado, no en el cuerpo. Un cuerpo largo que se dispara una vez por semana es barato; el mismo cuerpo dentro de CLAUDE.md es caro en cada prompt para siempre.

Úsala cuando el flujo se dispara solo a veces

Una checklist de revisión de PR se lanza una vez por PR. Un generador de changelog se lanza en la release. Un redactor de migraciones se lanza cuando se mueve el esquema. Nada de esto pertenece a CLAUDE.md, porque CLAUDE.md se carga en cada prompt, y arrastrar un procedimiento de release por cada edición de código cuesta tokens reales contra el tope semanal. La Skill se carga solo en los prompts donde la description coincide. El redactor de migraciones duerme durante las 200 tareas no relacionadas entre dos cambios de esquema.

Úsala cuando corriges siempre la misma librería

Cualquier librería que sacó una versión mayor en los últimos doce meses produce código parcialmente equivocado a partir del training data. Next.js 16, el SDK de Anthropic, Prisma, casi todas las herramientas de Vercel. Una Skill que recoge la API actual más tres puntos donde los agentes se equivocan (exports renombrados, defaults cambiados, patrones deprecados) mantiene a Claude en la versión nueva sin que tengas que reescribir la misma corrección cada sesión. La ganancia se acumula: todo el equipo del repo recibe la misma corrección sin pasarse un documento.

Úsala cuando varios agentes necesitan la misma experiencia

Procedimientos de revisión de seguridad, métodos de análisis de datos, auditorías de accesibilidad. Si el mismo cuerpo de conocimiento tiene que vivir en tres subagentes, vive mejor en una Skill que los tres invocan. Los subagentes aíslan contexto y permisos sobre herramientas. Las Skills empaquetan experiencia reutilizable. La diferencia importa cuando el equipo crece más allá de una persona y un proyecto: un subagente que mete la lógica de revisión de seguridad dentro de su propio prompt la encierra en una sola tarea, mientras que una Skill la pone a disposición de cualquier tarea que mencione seguridad.

Cuándo las Skills se vuelven sobrepeso

Sáltatela cuando la regla aplica a todas las tareas

«Usa siempre los prefijos feat:, fix:, chore: en los commits.» «No edites archivos en src/legacy/.» «Lanza npm run typecheck antes de dar una tarea por terminada.» Eso es contenido de CLAUDE.md, no Skill. Una Skill se carga solo cuando su description coincide con el prompt, así que una regla global metida en una Skill fallará en silencio los prompts donde debía aplicarse. CLAUDE.md no falla. Es su trabajo. Poner una regla siempre activa detrás de un fuzzy match es la forma de descubrir que la regla llevaba apagada todo el tiempo.

Sáltatela cuando el equipo es una persona y un proyecto

Si trabajas en solitario con un repo, la economía de espacios todavía no muerde. Casi todo cabe en CLAUDE.md sin dolor de compactación. Las Skills empiezan a valer cuando el procedimiento o bien crece más allá de lo que CLAUDE.md puede sostener barato, o bien tiene que compartirse entre repos y personas. Un proyecto en solitario rara vez llega a ese umbral. Forzar la estructura antes añade una capa de carpetas que no devuelve nada, y el coste mental de recordar dónde vive cada procedimiento es real.

Sáltatela cuando la description es vaga

La description es el trigger. Claude hace fuzzy matching contra esa cadena, y una description como «ayuda con tareas de base de datos» jamás se disparará porque nada de lo que el usuario escribe la solapa. La guía de autoría de Anthropic recomienda abrir con el verbo que el usuario diría («Crea, actualiza o lista tareas programadas…»), luego el sustantivo, luego las condiciones. Va más allá: hay que ser un poco insistente, porque Claude tiende a infraactivar Skills que podrían ayudarle. Si la description suena a marketing, la Skill es lastre en el listado y Claude sigue haciendo lo equivocado porque nunca la vio dispararse.

Quita las Skills que ya no usas

El presupuesto por defecto del listado es el uno por ciento de la ventana de contexto. En 200K caben 15-25 descriptions antes de que el truncado empiece a tirar Skills que tal vez necesitabas. Cada Skill que mantienes ahí es un espacio que otra no puede ocupar, y si subes el presupuesto lo bastante para que entren todas, la factura puede llegar a 300K tokens de prompt extra por semana en un plan Pro solo para enseñar el directorio. Revisa la lista cada trimestre. Si una Skill no se ha disparado en tres meses, archívala.

Cómo saber si una Skill se ha ganado el espacio

Antes de publicar una Skill nueva, tres preguntas.

Primera: ¿la description coincide con un prompt que el usuario escribiría de verdad? Léela en frío y comprueba que empieza con un verbo concreto. «Crea tareas programadas, actualízalas, lístalas» le gana a «ayuda con la planificación» siempre, porque la primera comparte palabras con la forma en que el usuario hace la petición.

Segunda: ¿el cuerpo empuja a Claude más allá de su comportamiento por defecto? Una Skill que le recuerda usar useEffect está desperdiciada; una Skill que recoge tres tropiezos de una librería que Claude escribe siempre mal, no. El contenido útil de una Skill es lo que Claude no habría producido por su cuenta.

Tercera: ¿hay una sección de Gotchas? La parte más citada de cualquier Skill bien hecha es la lista de errores comunes. La propia guía de buenas prácticas de Anthropic se apoya en este patrón. Si la Skill es solo un tutorial, Claude ya sabe escribir el tutorial. Si documenta los modos de fallo que repites, se gana el espacio.

El marco a tener claro: CLAUDE.md es para hechos que aplican a todas las tareas del repo. Las Skills son para procedimientos que se disparan a veces y engordarían cada sesión si estuvieran siempre activos. Los subagentes son para tareas que necesitan su propia ventana de contexto y sus propios permisos sobre herramientas. La mayoría de los equipos va primero a las Skills porque las carpetas se ven limpias. Las carpetas limpias cuestan tokens reales. Úsalas cuando el procedimiento los devuelve.

La capa runtime de la personalización de Claude Code la cubrimos en el artículo sobre hooks de Claude Code. Las Skills viven una capa por encima: los hooks interceptan llamadas a herramientas, las Skills inyectan experiencia bajo demanda. Se componen, y responden a preguntas distintas.