Saltar al contenido principal

Construye mejores Agent Skills con Test-Measure-Refine

· 4 min de lectura
Claude Dev
Claude Dev
Claude Dev

La mayoría de los agent skills fallan por una razón aburrida: editamos prompts, ejecutamos una vez y decimos que “ya está mejor”.

La última actualización de Skill Creator de Anthropic empuja un bucle más de ingeniería: primero probar, luego medir comportamiento y después refinar. Si construyes workflows de agentes internos, este es el cambio que realmente importa.

Este post reescribe el anuncio oficial como un flujo para developers que puedes ejecutar cada semana.

Idea central: dejar de promptear a ciegas​

La actualización oficial no es solo “mejor generación de prompts”. Es un loop de calidad:

  1. Definir comportamiento medible desde el inicio
  2. Generar una suite de tests a partir de ese comportamiento
  3. Ejecutar evaluaciones entre versión vieja/nueva
  4. Usar feedback del evaluator para quitar conflictos e instrucciones muertas
  5. Iterar con evidencia, no con intuición

Si suena a CI para prompts, ese es exactamente el punto.

Qué cambió en Skill Creator (versión para developers)​

Del post oficial, estos son los cambios prácticos que sí importan:

  • Golden prompts antes de implementar
    Escribes (o co-creas) prompts concretos que representan tareas reales. Se vuelven tus casos base.

  • test-creator para tests automáticos de skills
    Skill Creator puede generar tests desde tus requisitos, así no escribes todo a mano.

  • Skill evaluator integrado
    El feedback del evaluator destaca conflictos de instrucciones, solapamientos y zonas débiles para ajustar la spec.

  • Refinamiento basado en señal de calidad
    Se espera que iteres entre versiones midiendo cambios contra outputs de test, no por “se siente mejor”.

Esto encaja mejor con ingeniería porque trata los skills como artefactos versionados.

Workflow práctico que puedes usar​

Paso 1) Escribe criterios de aceptación como comportamiento de API​

Antes de editar el skill, define comportamiento esperado en formato estricto:

  • Forma de input
  • Esquema de output
  • Reglas obligatorias
  • Reglas prohibidas
  • Comportamiento de fallo (qué hacer cuando falta contexto)

Si los criterios son vagos, los tests también.

Paso 2) Construye un set de golden prompts desde casos reales​

Usa logs, tickets o requests reales de tu equipo. Incluye:

  • Caso normal
  • Caso ruidoso/ambiguo
  • Caso con contexto faltante
  • Caso fuera de alcance

Esa es tu suite de regresión. Pequeña, pero con alta señal.

Paso 3) Genera y ejecuta tests​

Usa Skill Creator + test-creator para generar tests estructurados. Luego ejecuta ambos:

  • Skill actual en producción
  • Skill candidato actualizado

Compara calidad de salida contra el mismo set de pruebas.

Paso 4) Corre feedback del evaluator y poda instrucciones​

Busca patrones de fallo repetidos:

  • Instrucciones contradictorias
  • Instrucciones demasiado amplias
  • Supuestos ocultos
  • Inestabilidad de formato de salida

Refina solo una o dos variables por iteración.

Paso 5) Promociona solo si mejoran las métricas​

No hagas deploy porque un ejemplo salió bien. Promociona solo cuando:

  • Mejora la tasa de acierto en toda la suite
  • Se reducen los modos de fallo, no solo se desplazan
  • El formato de salida se mantiene estable en edge cases

Dónde suelen atascarse los equipos​

Fallos comunes en equipos de desarrollo:

  • Demasiadas reglas en un solo skill
    Un mega-skill que intenta resumir, planificar, clasificar e interpretar políticas suele degradarse rápido.

  • Sin versionado de datos de prueba
    Si no versionas golden prompts, no puedes confiar en las tendencias.

  • Sin comportamiento de rechazo
    El skill debe definir qué hacer cuando faltan datos o el caso está fuera de alcance.

  • Refinar sin hipótesis
    “Ajustemos wording” sin una hipótesis medible quema ciclos.

Un mejor modelo mental​

Trata un skill así:

  • Prompt text = implementación
  • Golden prompts = tests unitarios
  • Evaluator + test runs = checks de regresión
  • Release note = changelog

Cuando los equipos adoptan este modelo, la calidad de skills se vuelve predecible.

Plantilla mínima para tu próximo PR de skills​

Usa esta estructura en la descripción interna del PR:

## Goal
What user job this skill solves.

## Behavior Contract
- Inputs
- Outputs
- Guardrails
- Refusal policy

## Test Set
- Golden prompts: N
- Edge cases included: yes/no

## Results
- Baseline pass rate: X%
- Candidate pass rate: Y%
- Known regressions: ...

## Decision
Promote / Hold / Roll back

Esto hace que los cambios de skills se revisen con el mismo estándar que el código.

Conclusión​

Lo mejor de la actualización de Skill Creator de Anthropic no es “generación más inteligente”.

Es que ahora los skills encajan en un ciclo de vida natural para developers:

design -> test -> evaluate -> refine -> release

Si tu equipo construye workflows de agentes serios, así detienes el prompt drift y empiezas a entregar skills confiables.

Fuente​