Para saber si una skill mejora de verdad una tarea, compara el mismo trabajo con el mismo prompt y entorno, primero sin ella y después con ella; repite las ejecuciones y puntúa por separado la corrección, el enrutamiento, la eficiencia y la seguridad. Este método sirve si estás creando una skill o decidiendo si merece seguir en el contexto del agente.

Una skill reúne instrucciones específicas para una tarea, a menudo en un archivo SKILL.md. Para evaluarla, prepara una tarea repetible, sus criterios de éxito, la skill y un entorno de prueba aislado. Mantén también separados los archivos de evaluación y las respuestas correctas.

Prepara la prueba antes de ejecutarla

Elige una tarea que puedas repetir y define de antemano qué cuenta como una respuesta correcta. Usa el mismo prompt, los mismos datos y las mismas herramientas en las dos condiciones: agente base, sin la skill, y agente con la skill. Si cambias varias cosas a la vez, no podrás atribuir el resultado a las instrucciones.

Comprueba también cómo se activa la skill. En los sistemas que enrutan tareas mediante una cabecera YAML, el nombre y la descripción breves pueden determinar si el agente la selecciona antes de cargar el resto del archivo. Una descripción demasiado parecida a la de otra skill puede desviar la selección; si no se activa, el contenido de sus instrucciones no llega a ponerse a prueba.

Ejecuta la misma prueba con y sin la skill

Diagrama conceptual de dos ejecuciones de una misma tarea, una sin skill y otra con ella, que conducen a evaluaciones separadas.
  1. Escoge una tarea frecuente y fija su criterio de éxito. Guarda el prompt y los datos que necesita para que ambas condiciones reciban la misma solicitud. Evalúa si resuelve la tarea, no solo si la respuesta suena convincente.
  2. Comprueba que el agente selecciona la skill adecuada. Revisa su nombre y descripción en la cabecera YAML y prueba solicitudes que deberían activarla. Si el resultado no cambia, averigua primero si la skill llegó a ejecutarse: la causa podría ser el enrutamiento o que el agente base ya resuelva esa tarea.
  3. Aísla el entorno. Ejecuta las pruebas en un entorno limpio y equivalente. Las credenciales locales, el historial de comandos, las variables de entorno y la carga del procesador pueden alterar la conducta o contaminar la línea base.
  4. Compara las dos condiciones con ejecuciones repetidas. Usa el mismo prompt y el mismo entorno: una serie sin la skill y otra con ella. Fija de antemano cuántas repeticiones harás y aplícalas a ambas series. Google Cloud, en un artículo publicado el 3 de noviembre de 2026, describe Pass@3 como ejemplo, no como una regla para todas las pruebas. Sus autores informaron que más de un tercio de las tareas de su estudio de recuperación cambió de puntuación entre ejecuciones consecutivas con el mismo código y prompt. El artículo de Google Cloud sobre evaluación de skills no fecha por separado esos experimentos.
  5. Puntúa cada resultado por separado. Registra la corrección de la respuesta y si se eligió la skill adecuada; mide aparte el uso de recursos y las comprobaciones de seguridad. El artículo de Google Cloud enumera cinco dimensiones de SkillEvaluator: corrección, capacidad de descubrimiento, eficiencia, eficacia y seguridad. Una mejora de eficiencia no debería compensar un fallo de corrección o seguridad.
  6. Mantén el verificador separado del agente. Guarda los casos de prueba, las respuestas correctas y los scripts de calificación en un entorno verificador; según el método descrito por Google Cloud, se montan después de que el contenedor del agente termina. La compañía relata cuatro formas de manipular una evaluación de recuperación, entre ellas leer el archivo con la respuesta correcta y eludir comprobaciones. También describe controles para detectar lecturas de tokens de cuentas de servicio de Kubernetes o consultas a metadatos de la nube, y para ocultar tokens OAuth activos en los registros guardados.

Añade un caso límite, no solo tareas rutinarias

Una prueba rutinaria puede pasar por alto errores convincentes ante una excepción. Un comentarista de Reddit propone comparar una solicitud de soporte normal con otra que incluye una excepción antigua de atención durante el fin de semana, válida para otro cliente. Comprueba si el agente encuentra las condiciones actuales y pide una decisión cuando los registros chocan. Es un caso de prueba propuesto, no un resultado medido.

Para que una skill sea fácil de mantener, sus instrucciones pueden centrarse en un hábito operativo concreto. Entre los ejemplos de Google Cloud está consultar la ayuda del subcomando exacto antes de cambiar el estado de un sistema. Copiar tablas de referencia extensas, en cambio, no produjo mucha mejora de eficiencia en las pruebas que describen sus autores.

Decide qué hacer con el resultado

Si las dos condiciones rinden igual, no concluyas de inmediato que la skill sobra: comprueba el enrutamiento y considera si el agente base ya dominaba esa tarea. Si la skill mejora la corrección, pero introduce un fallo de seguridad, la ganancia de rendimiento no lo compensa. Consérvala cuando la mejora en los resultados que te importan justifique el contexto y el mantenimiento que añade.