Hace tres meses, eliminé en masa catorce skills de mi configuración de Claude Code. No las archivé. Las eliminé. Eran skills en las que había invertido tiempo real construyendo, probando e iterando. Skills de las que estaba orgulloso.
Estaban empeorando mi trabajo.
No de forma dramática — eso habría sido fácil de detectar. De forma sutil. Una skill de generación de contenido que estaba anulando las capacidades nativas mejoradas de escritura de Claude. Una skill de mensajes de commit que producía resultados rígidos y formulaicos cuando el modelo había aprendido a escribirlos mejor por sí solo. Una skill de revisión de código tan prescriptiva que Claude estaba marcando casillas en lugar de pensar realmente sobre la calidad del código.
La eliminación masiva me enseñó algo que no había leído en ninguna documentación: construir skills es la parte fácil. Construir skills que sigan siendo útiles, que compongan bien entre sí, que realmente mejoren tu flujo de trabajo seis meses después — eso es una disciplina completamente diferente. Y es una disciplina que tuve que aprender por las malas.
Hasta ahora he construido y mantenido más de treinta skills activas en cuatro sitios web de diferentes marcas, un pipeline de creación de contenido, un flujo de trabajo de auditoría de seguridad y mi entorno de desarrollo diario. Algunas de esas skills llevan funcionando casi un año. Otras duraron una semana antes de darme cuenta de que estaban resolviendo el problema equivocado.
Lo que sigue no es un tutorial sobre cómo crear tu primera skill. Si necesitas eso, la documentación oficial de Anthropic y su curso Skilljar sobre Agent Skills te ayudarán a empezar. Esto trata sobre lo que sucede después de tus primeras diez skills — los patrones que emergen, los errores que se repiten y las decisiones arquitectónicas que separan las skills que usarás durante años de las que eliminarás en un mes.
Esta es la pregunta que lo cambió todo para mí: ¿qué tipo de skill estoy construyendo realmente?
Por qué la mayoría de las skills mueren jóvenes — y un cambio mental que lo soluciona
Antes pensaba que una skill era una skill era una skill. Escribes algunas instrucciones en markdown, tal vez agregas un script o dos, lo colocas en .claude/skills/ y sigues adelante. Ese enfoque funcionaba bien cuando tenía tres skills. Cuando llegué a quince, mi configuración era un desastre.
Las skills entraban en conflicto entre sí. Algunas cargaban contexto irrelevante el 90% del tiempo. Otras eran tan genéricas que apenas mejoraban la salida de Claude. Una skill — mi "calidad de código" original — estaba contradeciendo mi skill de "prácticas de testing" de maneras que no noté durante semanas.
El punto de inflexión llegó cuando empecé a categorizar mis skills por lo que realmente hacen, no por su temática. Después de catalogar todo en mi configuración y estudiar cómo los equipos internos de Anthropic organizan sus propias skills (han compartido parte de esto públicamente), noté que cada skill útil encaja claramente en una de aproximadamente nueve categorías. ¿Las skills confusas y difíciles de mantener? Siempre eran las que intentaban abarcar múltiples categorías a la vez.
Esta es la taxonomía que ahora uso antes de construir cualquier cosa nueva.
Skills de referencia de bibliotecas y API explican cómo usar correctamente una herramienta, SDK o biblioteca interna específica. Mi skill Aria encaja perfectamente aquí — codifica directrices de marca, reglas de voz, requisitos SEO y patrones de arquitectura de contenido para cuatro sitios web diferentes. Sin ella, Claude escribe publicaciones competentes que no suenan nada como mi marca.
Skills de verificación de producto describen cómo probar o verificar que la salida es realmente correcta. Se combinan con Playwright, tmux o scripts personalizados. Invertí muy poco aquí durante meses. Más sobre esto después.
Skills de obtención y análisis de datos se conectan a tus stacks de datos y monitoreo — UIDs de datasource de Grafana, IDs de dashboard, patrones de consulta comunes. Claude deja de adivinar nombres de columnas y empieza a escribir consultas que realmente funcionan.
Skills de automatización de procesos de negocio y equipo automatizan flujos de trabajo repetitivos. Mi skill standup-post agrega actividad de GitHub, actualizaciones de tickets y mensajes de Slack en una actualización diaria formateada. Instrucciones simples, valor acumulativo.
Skills de scaffolding y plantillas de código generan código repetitivo para patrones específicos de tu codebase. Una skill de Laravel para "nueva migración" con las convenciones y trampas de tu equipo ahorra treinta minutos cada vez.
Skills de calidad y revisión de código aplican estándares. Mi configuración de revisión adversarial genera un sub-agente para criticar código, implementa correcciones e itera hasta que los hallazgos se degradan a nimiedades.
Skills de CI/CD y despliegue ayudan a obtener, enviar y desplegar. Mi skill babysit-pr monitorea PRs, reintenta CI inestable, resuelve conflictos de merge y habilita auto-merge.
Skills de runbook toman un síntoma y recorren una investigación multi-herramienta para producir un informe estructurado. Minas de oro para rotaciones de guardia.
Skills de operaciones de infraestructura manejan mantenimiento rutinario con barandillas — flujos de trabajo de dependencias, investigación de costos, limpieza de recursos huérfanos con confirmación obligatoria antes de acciones destructivas.
En el momento en que empecé a preguntar "¿a qué categoría pertenece esto?" antes de escribir una sola línea de markdown, mis skills se volvieron más precisas. Si una skill intenta ser tanto un verificador de calidad de código COMO una plantilla de scaffolding, la divido en dos. Si no encaja claramente en ninguna categoría, cuestiono si debería existir.
Pero categorizar skills es solo el punto de partida. El verdadero arte está en cómo las escribes.
La sección de gotchas vale más que el resto de la skill combinada
Voy a hacer una afirmación que puede sonar extrema: la parte más valiosa de cualquier skill es su sección de gotchas. No las instrucciones. No los ejemplos. No la configuración. Los gotchas.
He aquí por qué. Claude ya sabe mucho. Sabe cómo escribir Python, cómo estructurar un componente React, cómo construir una REST API. Cuando escribes una skill que explica el uso básico de algo que Claude ya entiende, estás desperdiciando tokens y restringiendo la flexibilidad del modelo. Pero cuando documentas los modos de fallo específicos — los casos extremos que Claude encuentra repetidamente, las suposiciones que hace que son incorrectas en tu contexto específico, los bugs sutiles que solo aparecen en producción — ahí es donde las skills demuestran su valor.
Mi skill de contenido Aria tiene una sección de "Frases Prohibidas" con más de cincuenta elementos. Cosas como "En el mundo acelerado de hoy" y "Vamos a sumergirnos" y "Además" — frases que señalan instantáneamente contenido generado por IA. No escribí esa lista de una sola vez. La construí durante tres meses detectando a Claude recaer en lenguaje de IA, agregando cada infractor a la lista de gotchas, y observando cómo la calidad de salida mejoraba con cada adición.
El mismo patrón con mi skill de migraciones de Laravel. ¿La sintaxis real de migración? Claude la domina. Pero los gotchas — "nunca uses ->change() en una columna que tiene un índice en MySQL 5.7", "siempre agrega ->after('column_name') para mantener el orden de columnas", "nuestra base de datos de staging usa una colación diferente a producción" — esas entradas previenen bugs que de otra forma tomarían horas en depurar.
La conclusión práctica: empieza cada nueva skill con un conjunto mínimo de instrucciones y una sección de gotchas vacía. Usa la skill durante una semana. Cada vez que Claude haga algo incorrecto o inesperado, agrégalo a gotchas. Después de un mes, tu sección de gotchas será la parte más refinada y probada en batalla de la skill. También será la parte que te ahorre más tiempo.
Ahora reviso mis secciones de gotchas mensualmente. Algunas entradas se promueven a las instrucciones principales porque son tan fundamentales. Otras se eliminan porque Claude ha mejorado y ya no comete ese error de forma nativa. Este ciclo de mantenimiento es aburrido pero es la diferencia entre una skill que se mantiene afilada y una que se deteriora lentamente.
Ese hábito de revisión mensual lleva directamente a otra lección que tardé vergonzosamente en aprender.
Las skills son carpetas, no archivos — y eso lo cambia todo
Un concepto erróneo que mantuve durante demasiado tiempo: una skill es "solo un archivo markdown". Técnicamente, un archivo SKILL.md es todo lo que necesitas. Pero en el momento en que tratas las skills como carpetas — con scripts, archivos de referencia, plantillas y datos — su poder se multiplica.
Esta es la estructura de mi skill de contenido Aria tal como existe hoy:
aria/
SKILL.md # Core instructions, loaded on trigger
aria-system-prompt.md # Full brand guidelines, loaded on demand
references/
banned-phrases.md # AI detection trigger phrases
footer-templates.md # Brand-specific CTA footers
headline-formulas.md # Proven header structures by brand
assets/
post-template.md # Skeleton for new blog posts
scripts/
word-count.sh # Validates 3,000-5,000 word requirement
El archivo SKILL.md se mantiene por debajo de 500 líneas. Contiene la identidad central, la filosofía de escritura y punteros a archivos de referencia. Cuando Claude está generando una publicación para mejba.me, lee las secciones específicas de la marca desde el prompt del sistema. Cuando necesita verificar un titular contra fórmulas probadas, consulta references/headline-formulas.md. La lista de frases prohibidas vive en su propio archivo porque cambia frecuentemente y no quiero que las ediciones contaminen mis instrucciones principales.
Esto es divulgación progresiva en acción. Claude no carga todo de una vez. El frontmatter YAML — nombre y descripción — entra al prompt al inicio de la sesión. Son aproximadamente 100 tokens. El cuerpo del SKILL.md se carga cuando Claude determina que la skill es relevante. Los archivos de referencia se cargan solo cuando SKILL.md dirige explícitamente a Claude a leerlos.
¿Por qué importa esto? Porque la gestión de la ventana de contexto es una restricción real. Cada token de instrucciones de skill es un token que no puede usarse para la tarea real. Si volcara todo mi sistema Aria — directrices de marca para cuatro sitios web, cincuenta frases prohibidas, plantillas de footer, fórmulas de titulares, el blueprint completo de arquitectura de contenido — en un solo archivo SKILL.md, serían miles de tokens cargados para cada conversación, incluso las que solo piden a Claude corregir un error tipográfico.
La estructura de carpetas también facilita dramáticamente el mantenimiento. Cuando necesito actualizar frases prohibidas, edito un archivo. Cuando agrego una nueva marca, actualizo el prompt del sistema sin tocar la lógica central de la skill. Cuando un compañero quiere entender qué hace la skill, lee SKILL.md. Cuando quiere entender las directrices profundas de marca, lee los archivos de referencia.
Un patrón que he empezado a usar recientemente: incluir archivos de plantilla en assets/ que Claude copia y rellena en lugar de generar desde cero. Mi plantilla de publicación de blog incluye el bloque de metadatos, los marcadores de estructura de fases y el footer obligatorio. Claude no tiene que recordar el formato exacto — simplemente copia la plantilla y rellena los espacios. Menos errores de formato, salida más consistente.
Si prefieres que alguien construya este tipo de arquitectura de skills para tus propios flujos de trabajo, acepto configuraciones e integraciones personalizadas de Claude Code. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.
Hay una sutileza aquí que casi me paso por alto — y tiene que ver con lo que NO pones en la skill.
Lo que aprendí sobre no encorsetar a Claude
Mis skills de primera generación eran dictadoras. Cada paso prescrito. Cada formato de salida bloqueado. Cada decisión tomada de antemano.
Los resultados eran consistentes. También eran mediocres.
El problema de sobre-especificar una skill es que pierdes la capacidad de Claude para adaptarse. Esencialmente estás convirtiendo un motor de razonamiento inteligente en un rellenador de plantillas. Y los rellenadores de plantillas no manejan casos extremos. No te sorprenden con un enfoque mejor que el que planeaste. No detectan errores en tus propias instrucciones.
Aprendí esta lección con mi skill de revisión de código. La versión uno era una lista de verificación de veinte pasos: verificar importaciones sin usar, verificar manejo de errores, confirmar cobertura de tests, validar convenciones de nombres... Claude recorría metódicamente cada elemento y producía una revisión perfectamente formateada. Pero las revisiones pasaban por alto lo que realmente importaba — preocupaciones arquitectónicas, implicaciones de rendimiento, vulnerabilidades de seguridad que no encajaban en ningún elemento de la lista.
La versión dos redujo la lista a cinco principios y una sección de gotchas. En lugar de "verificar importaciones sin usar", decía "prioriza los hallazgos por impacto real en la fiabilidad de producción". En lugar de prescribir el formato de salida, decía "estructura tu revisión para ayudar al autor a entender el por qué detrás de cada hallazgo".
Las revisiones mejoraron dramáticamente. Claude empezó a detectar cosas que la lista nunca cubría — condiciones de carrera, violaciones de contratos de API, bugs sutiles de gestión de estado. Estaba pensando sobre el código en lugar de marcar casillas.
El principio que ahora sigo: dale a Claude la información que necesita y la flexibilidad para adaptarse a la situación. Dile lo que importa, no exactamente qué hacer. Incluye tus gotchas y restricciones, pero deja espacio para que el modelo aplique su propio juicio.
Hay una forma concreta de probar si has sobre-especificado: ejecuta la misma tarea tres veces con tu skill. Si las salidas son casi idénticas en estructura y contenido, tu skill probablemente es demasiado rígida. Si son consistentes en calidad pero variadas en enfoque, has encontrado el punto óptimo.
Este principio de flexibilidad también aplica a los disparadores de skills — y ahí es donde el campo de descripción se vuelve crítico.
El campo de descripción es marketing para el modelo, no para humanos
Cuando Claude Code inicia una sesión, construye un listado de cada skill disponible con su descripción. Este listado es lo que Claude escanea para decidir "¿hay una skill para esta petición?". El campo de descripción no es un resumen para lectores humanos. Es una especificación de disparador para el modelo.
Cometí este error con mi primer lote de skills. Mi skill de mensajes de commit tenía una descripción como: "Ayuda a escribir mejores mensajes de commit". Vaga. Genérica. Claude la activaba para todo lo remotamente relacionado con git, incluyendo momentos en que solo quería verificar un log o diff.
La descripción revisada: "Usar cuando el usuario pida crear un commit, escribir un mensaje de commit, o diga /commit. No activar para git log, git diff, git status u otras operaciones de git de solo lectura".
Una diferencia abismal. Claude ahora activa la skill precisamente cuando la necesito y no interfiere cuando no.
Algunos patrones que he encontrado que funcionan bien para las descripciones:
Disparadores positivos — qué debería activar la skill: "Usar cuando el usuario pida crear una publicación de blog, escribir un artículo, generar contenido, o mencione cualquiera de estas marcas: mejba.me, ramlit.com, colorpark.io, xcybersecurity.io".
Disparadores negativos — qué NO debería activarla: "No activar para revisiones de código, corrección de bugs o documentación técnica".
Condiciones de contexto — cuándo aplica la skill: "Solo relevante cuando se trabaja en repositorios que usan Laravel 11+ con Livewire".
Acertar con esto previene un problema que afecta a colecciones grandes de skills: conflictos de disparadores. Cuando dos skills reclaman manejar "tareas de escritura", Claude tiene que adivinar cuál quieres. Descripciones específicas y bien delimitadas eliminan las adivinanzas.
Esto se vuelve aún más importante cuando empiezas a componer skills juntas, que es donde aparece el verdadero poder.
Composición de skills: donde entra el efecto multiplicador
Las skills individuales son útiles. Las skills que se referencian y construyen unas sobre otras son transformadoras.
Mi pipeline de contenido funciona así: la skill Aria maneja la generación de contenido. Referencia una skill de SEO toolkit para investigación y optimización de palabras clave. La skill de SEO, a su vez, referencia una skill de análisis de datos que puede extraer datos de tráfico y métricas de Search Console. Cuando pido a Claude "crear una publicación para mejba.me sobre networking en Docker", estas tres skills se coordinan automáticamente.
La composición no se gestiona mediante algún sistema de dependencias — Claude Code aún no tiene gestión nativa de dependencias para skills. En su lugar, referencio otras skills por nombre en mis archivos SKILL.md: "Para análisis SEO, invoca la skill seo-toolkit". Claude lee esta instrucción e invoca la skill referenciada si está instalada.
Esto funciona sorprendentemente bien en la práctica. Pero hay una trampa: referencias circulares. Si la skill A dice "verifica con la skill B" y la skill B dice "confirma con la skill A", Claude entra en un bucle. Me pasó una vez con mis skills de revisión de código y testing — la skill de revisión decía "verifica que existan tests" y la skill de testing decía "revisa los hallazgos de la revisión de código". La solución fue hacer la dependencia direccional: la revisión de código puede invocar prácticas de testing, pero no al revés.
Otro patrón de composición que ha dado frutos: usar una skill "orquestadora" simple que conoce todas tus demás skills y enruta tareas a la correcta. Mi skill de flujo de trabajo de desarrollo no hace ningún trabajo real por sí misma — solo sabe que el scaffolding de código va a la skill de scaffolding, las revisiones van a la skill de revisión, y los despliegues van a la skill de CI/CD. Es un dispatcher, y me evita tener que recordar qué skill maneja qué.
El patrón de orquestador también hace trivial la incorporación de nuevos miembros al equipo. Instalan una skill, y automáticamente se enruta a todo lo demás que necesitan. Lo que nos lleva a la pregunta de cómo compartir skills entre un equipo en primer lugar.
Cómo distribuyo skills sin crear caos
Compartir skills suena sencillo. Las registras en tu repositorio bajo .claude/skills/ y todos las obtienen. Listo.
Excepto que no está listo. Porque cada skill registrada en el repositorio añade al contexto que Claude carga para cada miembro del equipo, la necesiten o no. Un equipo de cinco con diez skills cada uno significa cincuenta skills en contexto. Eso es mucho ruido.
El enfoque con el que me he quedado usa dos niveles.
Nivel uno: skills a nivel de repositorio van en .claude/skills/ y se registran en el repositorio. Estas son skills que todo contribuidor necesita — aplicación de estilo de código, convenciones de testing, procedimientos de despliegue. Si tocas este codebase, necesitas estas skills. Punto. Mantengo esta lista intencionalmente pequeña: tres a cinco skills por repositorio, máximo.
Nivel dos: skills personales y específicas de rol se distribuyen como plugins a través de un directorio compartido. Mis skills de contenido, mis herramientas SEO, mis referencias de sistema de diseño — estas se instalan por usuario. Los desarrolladores del equipo no necesitan mi skill de contenido Aria. Yo no necesito su skill de migración de base de datos. Cada uno instala lo que es relevante para su trabajo.
Para equipos de más de diez personas, recomendaría construir un marketplace interno de plugins — un repositorio compartido de GitHub donde la gente pueda explorar skills disponibles, leer descripciones e instalar lo que necesitan. Los equipos internos de Anthropic hacen algo similar: las skills empiezan en un directorio sandbox, la gente las comparte a través de Slack, y una vez que una skill tiene tracción, el propietario envía un PR para moverla al marketplace oficial.
El paso de curación importa más de lo que pensarías. Sin control, las colecciones de skills se inflan rápido. La gente crea skills para cada molestia menor, y en unos meses tienes cuarenta skills donde diez bastarían. Antes de agregar cualquier cosa a un marketplace compartido, pregunto: "¿Al menos tres personas de este equipo usarían esta skill al menos una vez por semana?". Si la respuesta es no, se queda como personal.
Una lección más de distribución que aprendí por las malas — que también resulta ser una de las características más poderosas que la mayoría desconoce.
Los hooks bajo demanda cambiaron mi forma de pensar sobre la seguridad
Las skills pueden registrar hooks que solo se activan cuando se invoca la skill, durando lo que dure la sesión. Esto es diferente de los hooks globales que se ejecutan todo el tiempo. Los hooks bajo demanda son barandillas contextuales.
Mi skill /careful es el mejor ejemplo. Cuando estoy a punto de trabajar en infraestructura de producción, la invoco. La skill registra hooks PreToolUse que bloquean rm -rf, DROP TABLE, force-push y kubectl delete. Estos hooks interceptan cada comando Bash que Claude intenta ejecutar y rechazan cualquier cosa que coincida con los patrones peligrosos.
No quiero que estos hooks se ejecuten todo el tiempo — serían enloquecedores durante el desarrollo normal. Pero cuando estoy tocando bases de datos de producción o clusters de Kubernetes en vivo, son innegociables. La skill me da un interruptor: máxima seguridad cuando la necesito, cero sobrecarga cuando no.
Otro hook bajo demanda que uso: /freeze, que bloquea cualquier operación de Edit o Write fuera de un directorio específico. Cuando estoy depurando un problema de producción, quiero que Claude lea y analice libremente pero no modifique nada accidentalmente. La skill freeze bloquea el sistema de archivos mientras mantiene el acceso de lectura abierto.
El sistema de hooks también permite medición. Ejecuto un hook PreToolUse que registra cada invocación de skill — qué skill, cuándo se activó, en qué contexto se ejecutó. Después de un mes de datos, puedo ver qué skills son populares, cuáles se activan poco (lo que significa que sus descripciones necesitan trabajo) y cuáles se activan demasiado (lo que significa que su alcance es demasiado amplio).
Este tipo de instrumentación suena excesivo hasta que estás gestionando treinta skills e intentando averiguar por qué tu sesión de Claude Code es más lenta de lo que debería. Los datos de registro te dicen exactamente a dónde va el presupuesto de contexto.
Hablando de presupuestos de contexto — hay un patrón de memoria que desearía haber empezado a usar desde el primer día.
Enseñando a tus skills a recordar
Algunas de mis skills más efectivas mantienen estado entre sesiones. No a través de ninguna base de datos sofisticada — a través de archivos de texto plano.
Mi skill standup-post mantiene un archivo standups.log. Cada vez que genera un standup, agrega la salida. A la mañana siguiente, Claude lee su propia historia y sabe exactamente qué ha cambiado desde ayer. Los standups pasaron de resúmenes genéricos a informes de delta precisos: "Se fusionó el PR de refactorización de auth que estaba bloqueando desde el martes. Se abrieron tres tickets nuevos, todos triados al sprint actual".
Mi skill de pipeline de contenido rastrea qué temas he cubierto, qué palabras clave he apuntado y qué enlaces internos he colocado. Cuando pido una nueva publicación, Claude verifica el registro y evita duplicar ángulos que ya he publicado. También puede sugerir enlaces internos a contenido existente porque sabe lo que ya está disponible.
La implementación es extremadamente simple. Un archivo JSON o un log de solo adición en un directorio estable. Claude Code proporciona ${CLAUDE_PLUGIN_DATA} como una carpeta estable por plugin específicamente para este propósito — los datos almacenados aquí persisten incluso cuando actualizas la skill.
// ${CLAUDE_PLUGIN_DATA}/content-history.json
{
"posts": [
{
"date": "2026-03-10",
"brand": "mejba.me",
"slug": "opus-4-6-hands-on-review",
"primary_keyword": "Claude Opus 4.6 review",
"internal_links": ["claude-sonnet-5-agentic-coding", "claude-agent-teams-guide"]
}
],
"keywords_used": ["Claude Opus 4.6", "agentic coding", "agent teams"],
"next_suggested": ["Claude Code skills deep dive", "hook development patterns"]
}
Una advertencia: no almacenes datos de memoria dentro del directorio de la skill misma. Cuando actualizas una skill, el directorio puede sobrescribirse. Perdí dos meses de historial de standups aprendiendo esta lección. Siempre usa una ruta externa estable.
El patrón de memoria también abre algo poderoso — skills que mejoran por sí solas con el tiempo. Cada vez que Claude encuentra un nuevo caso extremo y lo agrego a la sección de gotchas, eso es mejora manual. Pero una skill que registra sus propios fallos y los presenta para revisión, eso se acerca a la auto-mejora. No he automatizado completamente este ciclo todavía, pero la infraestructura de registro lo hace posible.
Bien — eso cubre los principios. ¿Cómo se ve esto realmente cuando lo juntas todo?
Cómo es mi flujo de trabajo real en marzo de 2026
Aquí va un lunes por la mañana típico. Abro Claude Code e inicio una sesión. Tres skills a nivel de repositorio se cargan automáticamente desde .claude/skills/: aplicación de estilo de código, convenciones de testing y nuestra lista de verificación de despliegue. Mis plugins personales también se cargan: Aria (contenido), SEO toolkit, convenciones de commit, revisión de código, flujo de trabajo TDD y algunas skills de utilidad.
Sobrecarga total de contexto al inicio de sesión: aproximadamente 600 tokens para todas las descripciones de skills. Los cuerpos reales de las skills aún no se han cargado — están esperando ser relevantes.
Escribo: "Crea una publicación para mejba.me sobre mejores prácticas de networking en Docker".
Claude escanea las descripciones de skills, identifica Aria como relevante, carga el cuerpo del SKILL.md. Las instrucciones de Aria le dicen a Claude que verifique el registro de historial de contenido, que vive en ${CLAUDE_PLUGIN_DATA}. Claude lee el historial, confirma que no he cubierto este ángulo específico antes e identifica dos publicaciones existentes que deberían enlazarse internamente.
La skill Aria referencia el SEO toolkit. Claude carga esa skill también, ejecuta análisis de palabras clave y determina palabras clave primarias y secundarias. Ambas skills están ahora activas, trabajando juntas.
Claude genera el paquete de contenido completo — metadatos, artículo de 3.500 palabras, footer apropiado para la marca. El script de conteo de palabras en aria/scripts/ valida la longitud. Si tiene menos de 3.000 o más de 5.000 palabras, Claude ajusta. El registro de historial de contenido se actualiza con los detalles de la nueva publicación.
Tiempo total: aproximadamente ocho minutos. El mismo trabajo sin skills — explicar directrices de marca, requisitos SEO, arquitectura de contenido, frases prohibidas, formato de footer, estrategia de enlaces internos — tomaría cuarenta minutos de ingeniería de prompts antes de que Claude empiece a escribir siquiera.
Eso no es un truco de productividad. Es un cambio fundamental en cómo trabajo con IA.
Los tres errores que sigo viendo (y que aún cometo a veces)
Después de ayudar a una docena de desarrolladores a configurar sus propios sistemas de skills, los mismos tres errores aparecen una y otra vez.
Error uno: construir skills para cosas que Claude ya hace bien. Si estás escribiendo una skill que le dice a Claude cómo escribir un bucle for o estructurar una respuesta JSON, estás desperdiciando esfuerzo. Las skills deberían codificar conocimiento que Claude no tiene — tus convenciones específicas, tus APIs internas, los modos de fallo de tu equipo. Prueba esto ejecutando la tarea sin la skill primero. Si la salida ya es el 80% de lo que quieres, probablemente no necesitas una skill. Necesitas una frase en tu archivo CLAUDE.md.
Error dos: nunca actualizar las skills después de crearlas. Las skills no son artefactos de una sola escritura. Claude mejora con cada actualización del modelo. Tu codebase evoluciona. Las convenciones de tu equipo cambian. Una skill que era perfecta hace tres meses podría ser activamente perjudicial hoy. Programo una "auditoría de skills" mensual — treinta minutos donde reviso cada skill, podo gotchas obsoletos y pruebo si la skill todavía mejora la salida en comparación con ejecutar sin ella.
Error tres: hacer las skills demasiado amplias. Una skill de "asistente de desarrollo" que cubre estilo de código, testing, despliegue y documentación son cuatro skills con un abrigo largo pretendiendo ser una. Divídela. Cada skill debería tener un propósito único y claro que puedas expresar en una frase. Si necesitas la palabra "y" para describir lo que hace una skill, probablemente son dos skills.
Hay un cuarto error que es más sutil y difícil de detectar: no invertir en skills de verificación. Pasé meses construyendo skills de generación — skills que ayudan a Claude a crear cosas. Pero apenas invertí en skills que ayudan a Claude a verificar su propia salida. Las skills de verificación son aburridas de construir pero detectan errores antes de que lleguen a producción. Un driver de flujo de registro que prueba el recorrido completo del usuario. Un verificador de checkout que ejercita tarjetas de prueba de Stripe. Un smoke test de despliegue que confirma que los health checks pasan. Estas skills no producen salidas impresionantes. Previenen fallos embarazosos. Si pudiera volver atrás y redistribuir mi tiempo de construcción de skills, la verificación recibiría el 40% del presupuesto en lugar del 10% que realmente recibió.
Lo que viene para las skills (y hacia dónde estoy construyendo)
El ecosistema de skills a marzo de 2026 está madurando rápidamente. El marketplace oficial de skills de Anthropic ha visto un crecimiento explosivo — solo la skill de frontend-design tiene más de 277.000 instalaciones. Plataformas comunitarias como skills.sh proporcionan directorios buscables organizados por categoría, autor y cantidad de instalaciones. El comando npx skills add ha hecho la instalación trivialmente fácil.
Pero la verdadera evolución está en cómo las skills componen y se comunican. Ahora mismo, la composición de skills se maneja a través de referencias por nombre en markdown — "invoca la skill X". Funciona, pero es manual y frágil. Espero gestión nativa de dependencias dentro del próximo año, donde el frontmatter de una skill pueda declarar prerequisitos que se auto-cargan.
También estoy observando de cerca la intersección de skills y hooks. Los hooks bajo demanda que se activan por skill ya son poderosos. El siguiente paso son hooks que se coordinen entre skills — una skill de revisión de código que automáticamente active una skill de testing, que active una verificación de preparación para despliegue, todo en un pipeline verificado. Ahora mismo lo conecto manualmente. Pronto será declarativo.
La frontera más interesante son las skills que aprenden — no a través de entrenamiento, sino a través de registro estructurado y auto-reflexión. Tengo un prototipo funcionando con mi pipeline de contenido donde Claude revisa su registro de historial semanalmente, identifica patrones en las ediciones que hice, y propone adiciones a la lista de frases prohibidas. Aún no estamos en auto-mejora autónoma. Pero los bloques de construcción están todos ahí.
Las skills que más importarán dentro de un año no son las más llamativas. Son las que silenciosamente mejoran tu trabajo diario y se vuelven un poco más afiladas cada mes porque alguien se tomó treinta minutos para revisar los gotchas.
Empieza ahí. Construye una skill esta semana para la tarea que más repites. Mantén las instrucciones mínimas y la sección de gotchas vacía. Úsala durante un mes. Agrega cada fallo a gotchas. Al final del mes, tendrás algo genuinamente útil. Y entenderás, de una forma que ninguna documentación puede enseñar, por qué las skills son el punto de extensión más poderoso de Claude Code.
¿Cuál es ese flujo de trabajo que repites todos los días y que todavía requiere prompting manual? Esa es tu primera skill. Ve y constrúyela.
Preguntas frecuentes
¿Cuántas skills de Claude Code debería tener instaladas a la vez?
Mantén las skills a nivel de repositorio entre tres y cinco por repositorio y las skills personales por debajo de quince en total. Más allá de eso, las descripciones de skills consumen contexto significativo y los conflictos de disparadores se vuelven más difíciles de gestionar. La calidad y la especificidad superan a la cantidad — siempre.
¿Cuál es la diferencia entre una skill de Claude Code y un archivo CLAUDE.md?
CLAUDE.md se carga en cada conversación de un proyecto y cubre contexto general del codebase. Las skills se cargan solo cuando se activan por peticiones relevantes, pueden incluir scripts y archivos de referencia, y soportan hooks. Usa CLAUDE.md para datos universales del proyecto; usa skills para flujos de trabajo específicos.
¿Con qué frecuencia debería actualizar mis skills de Claude Code?
Las revisiones mensuales funcionan bien para la mayoría de los equipos. Verifica cada skill contra las capacidades nativas actuales de Claude, poda gotchas obsoletos y prueba si la skill todavía mejora la salida de forma medible en comparación con ejecutar sin ella. Las actualizaciones del modelo pueden hacer que las skills de mejora de capacidades queden obsoletas rápidamente.
¿Pueden las skills de Claude Code llamar a otras skills?
Sí, a través de referencias por nombre en las instrucciones de tu SKILL.md. Escribe "invoca la skill [nombre-de-skill] para este paso" y Claude la activará si está instalada. La gestión nativa de dependencias aún no está incorporada, así que mantén las referencias direccionales para evitar bucles circulares.
¿Dónde debería almacenar los datos que mis skills generan entre sesiones?
Usa la variable de entorno ${CLAUDE_PLUGIN_DATA}, que proporciona un directorio estable por plugin que persiste a través de actualizaciones de skills. Nunca almacenes datos persistentes dentro de la carpeta de la skill misma — puede ser sobrescrita durante actualizaciones.
Let's Work Together
Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.
- Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise solutions): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (security services): xcybersecurity.io
