Por qué esto importa
Cuando creas un skill o los agrupas en un plugin, básicamente estás creando un pequeño producto que otras personas usarán. Y como cualquier cosa que le entregarías a un colega — una plantilla, un modelo de hoja de cálculo, una lista de verificación — vale la pena probarlo antes de que salga de tu escritorio.
Cuando usas un skill que creaste, sabes cómo resolver cualquier problema o falla. Sabes exactamente qué pedirle, qué archivos darle, y cómo se supone que debe verse la respuesta. Un compañero de equipo no tiene nada de eso. Podría formular la solicitud de manera un poco diferente, darle entradas ligeramente distintas, o encontrarse con un caso límite — una situación inusual pero real, como una solicitud que está justo fuera de lo que el skill fue diseñado para manejar. Ahí es donde los skills tienden a tropezar, y la persona que lo usa no sabrá por qué.
Probar un skill con evals — abreviatura de evaluaciones — es cómo detectas esos tropiezos antes de que alguien más lo haga. No dejes que la palabra te intimide. Un eval es solo una prueba: entra una solicitud realista, observas lo que sale, y le dices a Claude qué corregir. Sin código, sin scripts de prueba — solo tu criterio sobre si el resultado es lo suficientemente bueno para poner tu nombre en él.
Cómo funciona el sistema de evals
Cuando creas un skill con skill-creator — el asistente integrado de Claude para crear skills — te guía a través de los evals como parte del proceso. Así es como se ve eso en la práctica.
Skill-creator genera dos o más prompts realistas que alguien podría usar con tu skill. Para cada prompt, produce un par de resultados:
- Uno donde Claude usa tu skill
- Uno donde Claude responde el mismo prompt sin tu skill
Ese segundo es el punto de comparación. Está ahí para que puedas ver, lado a lado, qué diferencia está realmente haciendo tu skill — no solo "¿está bien este resultado?", sino "¿es este resultado mejor que lo que Claude habría hecho por su cuenta?".
Revisa cada par y da retroalimentación en lenguaje sencillo, directamente en la página de revisión. Mientras lees cada par, en realidad solo estás respondiendo dos preguntas:
- ¿Es la versión con el skill la que usaría? Si es así, genial — anota qué la hizo mejor para que el skill siga haciendo eso.
- Si no, ¿qué falta o está mal? Sé específico. "El tono es demasiado formal" o "se saltó el resumen ejecutivo" le da a Claude algo sobre lo cual actuar; "esto no está del todo bien" no lo hace.
Una vez que envías tu retroalimentación, Claude revisa el skill por ti según lo que dijiste.
Itera sobre el skill
Tu retroalimentación es la solución. Una vez que la envías, Claude actualiza el skill — reescribiendo las instrucciones, ajustando los ejemplos, afinando lo que solicita — y puedes ejecutar los mismos prompts de nuevo para ver si el cambio se mantuvo.
Cambia una cosa a la vez. Si la primera ronda mostró que el skill era demasiado extenso y le faltaba una sección, elige la que importa más, corrígela, vuelve a ejecutar, y luego regresa para otra revisión. Podrás notar qué fue lo que realmente marcó la diferencia. Si aún no estás satisfecho con los resultados después de la revisión, ejecútalo de nuevo — es un ciclo, no una puerta de una sola vez. La mayoría de los skills están listos después de una o dos rondas. El estándar para lanzar un skill — a ti mismo, a un compañero de equipo — no son evals perfectos. Es que los casos que te importan pasen significativamente mejor que la línea base, y que hayas identificado los casos que aún no manejas.
¿Y si los resultados ya se ven excelentes en el primer intento? Has terminado. Los evals no son un obstáculo que hay que superar — están ahí para cuando necesitas confianza, no ceremonia.
Pruébalo ahora
Recorre una revisión simulada de evals a continuación — tres prompts, cada uno con un resultado con-skill y sin-skill lado a lado.
Para cada par: elige la versión que realmente enviarías, y escribe una línea de retroalimentación que le darías a Claude. Ese es todo el ciclo.
Qué sigue
En la siguiente lección, pasarás de "esto funciona para mí" a "esto funciona para el equipo" — los patrones y decisiones que convierten los flujos de trabajo personales en infraestructura compartida.