El comando /goal de Claude Code no es un prompt, es una condición de éxito: así se escribe una que funcione

Un modelo distinto decide cuándo Claude ha terminado, no Claude mismo

La forma habitual de trabajar con un asistente de código es un vaivén: se pide un cambio, Claude lo hace, se ejecutan las pruebas a mano, se copian los errores de vuelta y se repite hasta que todo pasa. El comando /goal de Claude Code, disponible desde la versión 2.1.139, cambia ese patrón de raíz: se escribe una única condición de finalización, y tras cada turno un modelo evaluador aparte —Haiku, por defecto— lee la conversación completa y decide si esa condición ya se cumple. Si no es así, Claude sigue trabajando sin devolver el control; si lo es, el objetivo se marca como cumplido y la sesión vuelve a manos de quien la dirige.

Qué hay detrás del bucle generador-evaluador

La arquitectura separa dos papeles que normalmente recaen en el mismo modelo: uno que hace el trabajo —lee archivos, edita código, ejecuta comandos— y otro que juzga si ese trabajo ya es suficiente. El evaluador no ejecuta comandos ni lee archivos por su cuenta: solo puede valorar lo que Claude ha mostrado explícitamente en la propia conversación. Esta restricción no es un detalle técnico menor, es la pieza que determina cómo hay que escribir la condición para que la técnica funcione. /goal está disponible en modo interactivo escribiendo el comando seguido de la condición, en modo no interactivo con la opción -p para ejecutar el bucle completo de una sola vez, y a través de Remote Control; solo puede haber un objetivo activo por sesión a la vez.

La condición describe un resultado observable, no un deseo

Aquí está el matiz que marca la diferencia entre una condición que funciona y una que hace que Claude dé vueltas gastando tokens sin avanzar. La documentación oficial insiste en que la condición debe describir el estado final deseado, no el estado actual ni una intención vaga. Un ejemplo real que ofrece la propia documentación de Anthropic es /goal all tests in test/auth pass and the lint step is clean: describe algo que Claude puede demostrar ejecutando las pruebas y mostrando el resultado, y el evaluador tiene un criterio concreto contra el que comprobarlo. Otros ejemplos de condiciones bien planteadas incluyen migrar un módulo a una nueva API hasta que cada punto de llamada compile y las pruebas pasen, implementar un documento de diseño hasta que se cumplan todos los criterios de aceptación, dividir un archivo grande en módulos hasta que cada uno esté por debajo de un límite de tamaño, o recorrer una lista de incidencias etiquetadas hasta vaciarla por completo.

Frente a esto, una condición vaga como "termina de refactorizar esto cuando quede bien" no le da al evaluador nada concreto que comprobar, y eso produce uno de dos fallos: Claude sigue dando vueltas sin verificar realmente si terminó, o el evaluador da por buena una afirmación de éxito sin evidencia real detrás, porque no hay ningún criterio objetivo con el que contrastarla. La regla práctica es sencilla de aplicar: si la condición no se puede comprobar leyendo lo que Claude ya ha mostrado —el resultado de un test, un recuento de archivos, una lista vacía—, no es una buena condición para /goal.

Matices y límites que conviene tener en cuenta

El propio mecanismo de verificación tiene un límite estructural que merece mencionarse con honestidad: como el evaluador solo juzga lo que aparece en la conversación, una condición mal escrita puede dar por buena una afirmación de Claude que no está respaldada por una comprobación real, si Claude describe el resultado sin mostrar la ejecución que lo demuestra. Por eso las condiciones que piden ver un resultado ejecutable —como el resultado de una batería de pruebas— son más fiables que las que solo piden una afirmación de que algo "está hecho". Además, solo puede haber un objetivo activo por sesión, y la restauración de un objetivo interrumpido al reanudar una sesión con --continue o --resume ha ido cambiando entre versiones: antes de la 2.1.239, no se restauraba al reanudar desde el selector de sesiones, aunque sí en el resto de rutas de reanudación, así que conviene comprobar en qué versión se está trabajando antes de asumir ese comportamiento como garantizado.

Otro punto útil para comparar herramientas: /goal no es lo mismo que un hook de tipo Stop ni que el modo automático de aprobación de herramientas. El modo automático evita las confirmaciones dentro de un mismo turno, pero Claude sigue decidiendo por sí mismo cuándo detenerse; un hook Stop vive en la configuración y se aplica a todas las sesiones dentro de su ámbito; /goal añade específicamente un evaluador independiente que decide la finalización turno a turno, y está pensado como un atajo de sesión, no como una configuración persistente para todo un equipo.

Por qué importa hoy

Para cualquier flujo de trabajo con un criterio de éxito verificable —una migración de API, una batería de pruebas que debe quedar en verde, una lista de tareas que hay que vaciar— escribir la condición de /goal pensando en qué evidencia concreta puede mostrar Claude, en lugar de en qué se quiere conseguir en abstracto, es la diferencia entre delegar de verdad un trabajo largo y quedarse revisando cada turno de todos modos. La próxima vez que se use /goal, merece la pena releer la condición una vez escrita y preguntarse: ¿podría un tercero, leyendo solo la conversación, decidir con certeza si esto ya se ha cumplido? Si la respuesta no es un sí evidente, esa condición necesita reescribirse antes de lanzar el bucle.