Cómo Pruebo las Claude Skills Antes de que Rompan Mi Flujo de Trabajo
Eliminé una skill el martes pasado que había funcionado perfectamente durante seis semanas.
No porque dejara de funcionar. Porque Claude se volvió más inteligente. La skill estaba empeorando activamente mis resultados — anulando comportamientos que el modelo ya había aprendido a hacer de forma nativa. Solo me di cuenta porque finalmente ejecuté una prueba A/B adecuada en lugar de confiar en mi intuición.
Ese momento cambió cómo pienso sobre cada skill personalizada que construyo. Y si estás creando skills para Claude Code basándote en corazonadas — enviándolas a producción después de una sola prueba exitosa — probablemente estés sentado sobre la misma bomba de tiempo que yo tenía.
Esto es lo que nadie te dice sobre las Claude Skills: tienen fecha de expiración. Y Anthropic acaba de lanzar una herramienta que te ayuda a descubrir exactamente cuándo llega esa fecha.
La Skill que Me Engañó Durante Seis Semanas
Había construido una skill de procesamiento de PDF en enero. Nada sofisticado — le indicaba a Claude cómo extraer datos estructurados de facturas, manejar diseños multipágina y generar JSON limpio. Cuando la probé por primera vez, los resultados fueron dramáticamente mejores que Claude sin modificaciones. Victoria fácil. A producción.
Seis semanas después, estoy investigando por qué mi pipeline de facturas es más lento de lo que recordaba. El uso de tokens había aumentado gradualmente. Los resultados estaban bien, pero algo no cuadraba. No pude identificarlo hasta que hice algo que debería haber hecho semanas antes.
Ejecuté los mismos prompts sin la skill.
Los resultados eran casi idénticos. En algunos casos, mejores. Claude había aprendido a manejar PDFs de manera más efectiva a través de actualizaciones del modelo, y mi skill ahora añadía overhead innecesario — instrucciones extra que el modelo ya estaba siguiendo, restricciones rígidas que impedían que usara sus capacidades nativas mejoradas.
Esa es la trampa. Las skills no anuncian cuando se convierten en peso muerto. Simplemente se quedan ahí silenciosamente, consumiendo tokens y restringiendo un modelo que las ha superado.
Esta revelación me llevó por un camino que terminó en el Skill Creator de Anthropic — y honestamente, desearía haberlo encontrado antes.
Dos Tipos de Skills (y Por Qué la Diferencia Importa Más de lo que Crees)
Antes de guiarte por el flujo de trabajo del Skill Creator, hay un modelo mental que reformuló completamente cómo abordo el desarrollo de skills. Cada Claude Skill cae en uno de dos grupos, y entender en cuál está la tuya determina todo sobre cómo la construyes, pruebas y mantienes.
Skills de mejora de capacidades llenan vacíos donde el modelo actualmente tiene dificultades. Mi skill de PDF era una de estas. También lo son skills para manejar la generación de PowerPoint, patrones de concurrencia en Swift o formateo complejo de documentos. Estas skills tienen una fecha natural de retiro — el modelo mejora con cada actualización, y eventualmente tu skill se convierte en rueditas de entrenamiento en una bicicleta que el ciclista ya domina.
Skills de codificación de flujos de trabajo capturan tus procesos específicos, preferencias y reglas de negocio. Piensa en checklists de revisión de NDA, flujos de revisión de código específicos de tu empresa, plantillas de informes semanales que extraen datos de Jira y PostHog, triaje de reclamaciones de seguros con reglas internas de cumplimiento. Estas skills codifican tu conocimiento, no capacidades generales. El modelo no va a aprender espontáneamente los requisitos de cumplimiento de tu empresa a través de una actualización de entrenamiento.
Esto es lo que la mayoría de la gente pasa por alto: la estrategia de pruebas es completamente diferente para cada tipo.
Para skills de mejora de capacidades, la pregunta crítica es "¿esto todavía mejora los resultados comparado con no usar ninguna skill?" Necesitas comparaciones de referencia. Pruebas A/B. Benchmarks cuantitativos. Porque en el momento en que la respuesta cambia a "no", la skill necesita retirarse.
Para skills de codificación de flujos de trabajo, la pregunta crítica cambia a "¿se activa de manera confiable y se ejecuta correctamente?" Te importa menos si supera a Claude sin modificaciones y más si se activa cuando debe, sigue tu proceso específico y no se activa con prompts no relacionados.
Yo estaba tratando todas mis skills como del segundo tipo — verificando si funcionaban, nunca verificando si todavía eran necesarias. El Skill Creator corrige ese punto ciego.
Instalando el Skill Creator (Dos Minutos, Cero Drama)
Poner en marcha el Skill Creator es sencillo. Puedes obtenerlo directamente del repositorio de skills de Anthropic y colocarlo en tu directorio ~/.claude/skills/.
mkdir -p ~/.claude/skills/skill-creator
cd ~/.claude/skills/skill-creator
# Descargar el archivo principal de la skill
gh api repos/anthropics/skills/contents/skills/skill-creator/SKILL.md \
--jq '.content' | base64 -d > SKILL.md
# Obtener los directorios de soporte (agents, scripts, references, etc.)
# O clonar todo el repositorio y copiar la carpeta skill-creator
La skill viene con varias piezas de soporte:
- agents/ — Agentes de calificación, comparación y análisis para evaluación automatizada
- scripts/ — Herramientas Python para benchmarking, generación de reportes y optimización de descripciones
- eval-viewer/ — Interfaz de revisión basada en HTML para examinar resultados de pruebas
- references/ — Documentación de esquemas para las estructuras de datos de evaluación
Una vez instalada, Claude Code la detecta automáticamente. La verás listada cuando verifiques tus skills disponibles. Sin configuración, sin dependencias que gestionar — simplemente funciona.
Pero instalarla es la parte fácil. El verdadero valor está en el flujo de trabajo que habilita, y ahí es donde las cosas se ponen genuinamente interesantes.
El Flujo de Trabajo de Pruebas que Cambió Cómo Lanzo Skills
El ciclo de evaluación del Skill Creator se basa en una premisa simple: no confíes en tu intuición sobre si una skill funciona. Demuéstralo.
Este es el proceso que ahora sigo para cada skill que construyo o mantengo. Toma unos 30 minutos para una ronda exhaustiva, y me ha salvado de lanzar skills defectuosas más veces de las que me siento cómodo admitiendo.
Paso 1: Escribe prompts de prueba realistas.
No ejemplos genéricos de juguete. Prompts reales. El tipo de solicitudes desordenadas y cargadas de contexto que los usuarios reales envían. El Skill Creator te empuja naturalmente hacia esto — quiere prompts con rutas de archivos, contexto personal, nombres de empresas, valores específicos de columnas. El tipo de cosa que alguien realmente escribe a las 2 PM un miércoles cuando necesita que algo se haga.
{
"skill_name": "seo-audit",
"evals": [
{
"id": 1,
"prompt": "ok so my boss just sent me this site ramlit.com and wants a full SEO audit before our board meeting Thursday. Focus on technical stuff and whatever Google cares about now with the AI overview changes",
"expected_output": "Comprehensive SEO audit covering technical, content, and GEO factors"
}
]
}
Prompts de prueba malos: "Haz una auditoría SEO." "Revisa esta URL." "Analiza la página."
Los buenos prompts de prueba parecen que alguien interrumpió su flujo de trabajo para escribir algo rápidamente. Abreviaciones, pistas de contexto, señales de urgencia. Eso es lo que tu skill realmente enfrenta en producción.
Paso 2: Ejecuta pruebas A/B en paralelo.
Aquí es donde el Skill Creator realmente brilla. Para cada prompt de prueba, lanza dos ejecuciones de subagentes simultáneamente — una con tu skill cargada, otra sin ella. Mismo prompt, mismas condiciones, diferente disponibilidad de skill.
La ejecución con skill obtiene tu SKILL.md cargado en el contexto. La ejecución sin skill opera solo con las capacidades nativas de Claude. Ambas guardan sus salidas en directorios organizados del workspace.
Paso 3: Califica los resultados mientras las ejecuciones están en progreso.
Esta es una buena optimización del flujo de trabajo — mientras las pruebas se ejecutan en segundo plano, redactas tus criterios de evaluación. ¿Qué cosas específicas deberían ser verdaderas sobre un buen resultado? El Skill Creator las llama "assertions" (afirmaciones), y son verificaciones objetivamente comprobables.
Para mi skill de auditoría SEO, las assertions podrían verse así: "El resultado incluye análisis de Core Web Vitals", "El resultado menciona la accesibilidad para crawlers de IA", "El resultado proporciona recomendaciones accionables, no solo observaciones."
Paso 4: Revisa todo en el visor de evaluación.
El Skill Creator genera una interfaz de revisión en HTML — no un muro de texto de terminal, sino un visor real basado en navegador con pestañas para comparación cualitativa de resultados y benchmarks cuantitativos. Ves cada caso de prueba lado a lado, con skill versus sin skill, y puedes dejar comentarios en cada uno.
Esta es la parte que detectó el problema de mi skill de PDF. Cuando vi los resultados con skill y sin skill uno al lado del otro, la diferencia era... nada significativo. La skill añadía 22% más tokens para resultados aproximadamente equivalentes.
Paso 5: Itera basándote en evidencia, no en sentimientos.
Después de revisar, alimentas tus comentarios de vuelta al Skill Creator. Lee tus comentarios, analiza los datos cuantitativos y te ayuda a reescribir la skill para abordar problemas específicos. Luego ejecutas todo el ciclo de nuevo.
El ciclo continúa hasta que los comentarios son todos positivos, no estás haciendo progreso significativo, o estás satisfecho con los resultados. Para la mayoría de las skills, encuentro que dos a tres iteraciones es el punto óptimo.
Los Números de Benchmark que Realmente Importan
El Skill Creator genera un reporte de benchmark después de cada iteración, y saber a qué números prestar atención — y cuáles ignorar — es la mitad de la batalla.
Aquí hay un ejemplo real del benchmarking de una de mis skills:
| Métrica | Con Skill | Sin Skill | Delta |
|---|---|---|---|
| Tasa de Aprobación de Assertions | 87.5% | 74.0% | +13.5% |
| Tiempo Promedio de Completado | 18.2s | 23.4s | -22% más rápido |
| Uso Promedio de Tokens | 12,400 | 10,800 | +14.8% |
La mejora en la tasa de aprobación es el número principal. Si tu skill no está mejorando significativamente las tasas de aprobación en tus assertions, no está justificando su existencia.
Pero mira ese aumento en el uso de tokens. Mi skill usa 14.8% más tokens. ¿Vale eso una mejora del 13.5% en la calidad del resultado? Para una skill que ejecuto 50 veces por semana, probablemente sí. ¿Para algo que uso una vez al mes? La matemática cambia.
El delta del tiempo de completado también es interesante. Mi skill en realidad hizo que Claude fuera más rápido a pesar de usar más tokens. Eso sucede cuando una skill le da a Claude una dirección más clara — menos tiempo explorando caminos sin salida, más tiempo ejecutando el enfoque correcto.
El agente analizador profundiza más allá de estos agregados. Busca assertions no discriminantes (las que pasan independientemente de la presencia de la skill — lo que significa que están probando capacidades base, no valor añadido por la skill), resultados de alta varianza (posibles pruebas inconsistentes) y patrones entre casos de prueba que las estadísticas resumidas podrían ocultar.
El Truco de Optimización de Descripción que la Mayoría Ignora
Algo que aprendí por las malas: puedes construir una skill perfecta que nunca se activa porque su descripción no coincide con cómo la gente realmente pide ayuda.
El Skill Creator incluye un pipeline de optimización de descripción que funciona como un mini ciclo de entrenamiento de machine learning. Es genuinamente ingenioso.
Empiezas creando 20 consultas de evaluación — la mitad que debería activar tu skill, la mitad que no debería. La idea clave: las consultas de "no debería activarse" necesitan ser casi-aciertos, no prompts obviamente no relacionados. Una prueba negativa de "escribe una función fibonacci" para una skill de SEO no prueba nada. Una prueba negativa de "verifica si mi sitio carga rápido en móvil" prueba si tu skill de SEO correctamente cede ante una herramienta específica de rendimiento.
El optimizador divide tus consultas en conjuntos de entrenamiento y prueba, evalúa la precisión de activación de la descripción actual, luego reescribe iterativamente la descripción para mejorar el puntaje. Ejecuta cada consulta múltiples veces para tener en cuenta la varianza y selecciona la mejor descripción basándose en el rendimiento del conjunto de prueba retenido — no del rendimiento de entrenamiento — para evitar el sobreajuste.
Después de ejecutar esto en mi skill de SEO, la confiabilidad de activación saltó de aproximadamente 72% a 94%. ¿La corrección principal? Mi descripción original decía "usar para análisis SEO." La versión optimizada mencionaba síntomas específicos: "auditoría de sitio", "rankings de búsqueda", "Core Web Vitals", "schema markup", "E-E-A-T." Habla el lenguaje que los usuarios realmente usan.
# Antes de la optimización
description: Use when performing SEO analysis on websites
# Después de la optimización
description: Use when analyzing website SEO health, checking search rankings,
auditing technical SEO (Core Web Vitals, crawlability, indexability),
reviewing schema markup, assessing E-E-A-T compliance, or optimizing
for AI search visibility. Triggers on site audits, page analysis,
and structured data validation.
Esa diferencia — entre cómo piensas sobre tu skill y cómo los usuarios piden usarla — es donde se esconden la mayoría de los fallos de activación.
Cuándo Retirar una Skill (La Conversación que Nadie Quiere Tener)
La jubilación de mi skill de PDF no fue un caso aislado. Desde entonces he ejecutado comparaciones de referencia en todas mis skills de mejora de capacidades, y dos más están en la lista de eliminación.
Aquí está mi framework de retiro. Es simple, y lo ejecuto después de cada actualización importante del modelo:
Ejecuta tu suite de pruebas estándar con la skill desactivada. Si los resultados sin skill puntúan dentro del 5% de los resultados con skill en tus assertions, la skill está funcionando por inercia. Añade complejidad sin añadir valor.
Verifica tu overhead de tokens. Incluso una skill que mejora marginalmente los resultados podría no valer los tokens extra si la mejora es pequeña. Calcula el costo mensual en tokens de la skill en todo tu uso y pregúntate si pagarías esa cantidad por la mejora que estás viendo.
Mira las transcripciones, no solo los resultados. A veces una skill hace que Claude tome un camino más largo y tortuoso para llegar al mismo destino. Si ves que el modelo gasta tiempo en pasos que tu skill exige pero que no contribuyen a la calidad del resultado, esas instrucciones son peso muerto.
Prueba con prompts NUEVOS, no tu conjunto de pruebas original. Tus prompts de prueba originales podrían estar accidentalmente sintonizados con las fortalezas de la skill. Lanza cinco prompts frescos y realistas y ve si la ventaja de la skill se mantiene en casos para los que no fue optimizada.
Sé que retirar una skill se siente como admitir que el tiempo invertido en construirla fue desperdiciado. No lo fue. La skill cumplió su propósito durante una ventana en la que el modelo necesitaba esa guía. Pero aferrarte a skills que el modelo ha superado es como mantener las rueditas de entrenamiento después de que ya aprendiste a andar en bicicleta. No ayuda, y podría hacerte más lento.
Construyendo Tu Primera Skill con el Creator (Un Recorrido Real)
Suficiente teoría. Déjame guiarte paso a paso en la construcción de una skill real usando el Skill Creator.
Recientemente necesitaba una skill para generar informes semanales de ingeniería — extrayendo contexto de múltiples fuentes, formateando consistentemente y alcanzando un tono específico que mi equipo espera. Skill clásica de codificación de flujo de trabajo.
La fase de entrevista: El Skill Creator comenzó preguntando qué debería hacer la skill, cuándo debería activarse y cuál debería ser el formato de salida. Describí la estructura del informe semanal, las fuentes de datos (logs de Git, tickets de Jira, registros de despliegue) y el tono (conciso, orientado a métricas, sin relleno).
El borrador: Basándose en mis respuestas, generó un SKILL.md con secciones claras — plantilla de salida, instrucciones de recopilación de datos, directrices de tono y reglas de formato. El primer borrador estaba un 80% correcto. El 20% restante fue la parte interesante.
Creación de casos de prueba: El Skill Creator propuso tres prompts de prueba:
- "Genera mi informe semanal de ingeniería para el standup del equipo mañana"
- "ok necesito escribir lo que entregamos esta semana, enfócate en la migración de auth"
- "informe semanal pero esta semana fue principalmente correcciones de bugs y deuda técnica, no hay mucho que mostrar"
Cada uno aborda un escenario diferente — solicitud estándar, solicitud enfocada y la temida semana de "nada impresionante pasó". El tercero es crítico porque prueba si la skill puede hacer que una semana tranquila suene sustancial sin fabricar logros.
Los resultados A/B: Los resultados con skill acertaron el formato cada vez. Los resultados sin skill eran decentes pero inconsistentes — a veces incluían las secciones correctas, a veces omitían las métricas de despliegue, una vez ignoraron completamente las directrices de tono y escribieron algo que parecía un comunicado de prensa.
La iteración: Basándome en mis comentarios de que el caso de prueba de "semana tranquila" todavía se sentía demasiado inflado, el Skill Creator ajustó la skill para abordar explícitamente las semanas de baja actividad: "Cuando los logros de la semana son principalmente mantenimiento, correcciones de bugs o deuda técnica, preséntelos con un encuadre honesto. La reducción de deuda técnica es valiosa — dilo directamente en lugar de inflar trabajo rutinario en narrativas dramáticas."
Dos iteraciones, unos 25 minutos en total, y tenía una skill que consistentemente produce informes que mi equipo realmente encuentra útiles.
Lo que Desearía Haber Sabido Hace Seis Meses
Si pudiera volver atrás y darme un consejo sobre las Claude Skills, no sería sobre escribir mejores prompts u optimizar descripciones. Sería esto: trata las skills como código, no como configuración.
El código se prueba. El código se versiona. El código se revisa. El código se retira cuando algo mejor aparece.
Las skills merecen la misma disciplina. El Skill Creator no solo hace que construir skills sea más fácil — hace posible tratar el desarrollo de skills con el rigor que merece. Pruebas A/B automatizadas, benchmarks cuantitativos, optimización de activación, ciclos de retroalimentación estructurados. Estos no son lujos opcionales. Para cualquier skill en la que confíes regularmente, son la diferencia entre una herramienta que genuinamente ayuda y una superstición que nunca te molestaste en verificar.
Los ingenieros y equipos que obtienen las mayores ganancias de productividad con Claude no son los que tienen más skills. Son los que saben — con evidencia — cuáles skills justifican su existencia.
Comienza con tu skill más utilizada. Ejecuta una comparación de referencia. Podrías sorprenderte con lo que encuentres. Yo ciertamente lo hice.
¿Y esa skill de PDF que eliminé? Reconstruí una versión más ligera que maneja solo los casos extremos específicos con los que Claude todavía tiene dificultades — diseños de facturas multicolumna con tablas anidadas. Es un tercio del tamaño original, se activa solo cuando esos patrones específicos aparecen, y realmente mejora los resultados en un 31% en su enfoque estrecho.
A veces la mejor skill no es la más completa. Es la que sabe exactamente cuándo aparecer — y cuándo quedarse al margen.
Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (desarrollos personalizados e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
