/goal en Claude Code: dale una meta y dejá que itere solo

20 turnos de Claude requieren 20 prompts tuyos. Uno por cada vuelta.

Si querés que migre un módulo, que rompa un archivo grande, que vacíe un backlog de issues — escribís el prompt, Claude trabaja, te devuelve algo, vos lo leés, le decís "seguí", y repetís. La conversación avanza, pero el costo de mantenerla viva sos vos.

/goal cambia esa ecuación. Le decís UNA condición de éxito al principio, y Claude itera turno tras turno hasta cumplirla. Sin tu intervención entre vuelta y vuelta.

Llegó en Claude Code 2.1.139 (release del 11 de mayo). Está documentado oficialmente, pero la mayoría no lo está usando todavía. Vale la pena entenderlo a fondo porque cambia la forma de delegarle trabajo agéntico a Claude.

---

Qué es /goal en una frase

Un slash command que define una condición de éxito persistente. Claude la evalúa después de cada turno, y si no está cumplida, arranca el siguiente turno solo. El loop se corta cuando la condición se cumple, vos cancelás, o se acaba el budget que pusiste.

No es un agente nuevo. No es un modelo nuevo. Es un Stop hook administrado por el harness que mantiene a Claude trabajando sin necesidad de que vos digas "seguí" cada vez.

---

Sintaxis exacta

/goal [condition|clear]

Tres modos:

• /goal (sin argumento) → muestra el estado actual del goal activo o la última conseguida
• /goal <condición> → setea una nueva condición (máximo 4000 caracteres) y arranca un turno inmediatamente usándola como directiva
• /goal clear (o stop, off, reset, none, cancel) → cancela el goal activo

Cuando hay un goal corriendo, ves un indicador en la UI:

◎ /goal active · 4 turns · 12,431 tokens · 3m 21s

Te muestra cuántos turnos lleva, cuántos tokens consumió y cuánto tiempo pasó. Eso es lo único que sabés en tiempo real: el resto es Claude trabajando solo.

/goal funciona en los tres modos de Claude Code:

• Interactivo (el que usás todos los días)
• Headless (claude -p "prompt")
• Remote Control (cuando lo manejás desde otra máquina)

Y sobrevive a --resume y --continue: si reanudás una sesión, la condición se preserva (el timer y el contador de turnos se resetean, pero el goal sigue activo).

---

El loop invisible: cómo funciona realmente

Acá está la parte que importa entender.

Cuando seteás un goal, Claude no entra en un "modo agéntico" especial. Lo que pasa es que el harness instala un evaluator que corre como Stop hook al final de cada turno. Ese evaluator es un modelo chico y rápido (Haiku por default) que:

1. Lee la conversación entera del turno que acaba de terminar
2. Evalúa si la condición que definiste está cumplida
3. No corre tools. Solo lee y razona.
4. Devuelve sí/no al harness

Si dice "no cumplida", el harness arranca el siguiente turno automáticamente, sin esperar input tuyo. Si dice "cumplida", el loop termina y vos volvés a tener el control.

Tres consecuencias importantes:

• El evaluator no puede ejecutar nada. No corre npm test por su cuenta. Vos tenés que hacer que el modelo principal (Sonnet, Opus) ejecute lo que sirve como prueba. El evaluator solo lee si esa prueba pasó.
• El costo del evaluator es bajo (Haiku, contexto acotado al turno), pero no es cero. En sesiones largas se nota.
• El criterio de éxito tiene que ser leíble desde la conversación. Si tu condición es "los tests pasan", el modelo principal tiene que correr los tests y mostrar el output. Si no, el evaluator no tiene nada que leer.

---

Los 4 casos de uso oficiales

Estos vienen directo de la doc de Anthropic. Son los escenarios donde /goal brilla:

1. Migrar un módulo a una API nueva hasta que los tests pasen

/goal Migrar src/auth/ del SDK v3 al v4. Done cuando
`npm test test/auth` exit code es 0. No tocar otros módulos.

2. Implementar un design doc hasta cumplir criterios

/goal Implementar lo que dice docs/checkout-v2.md. Done cuando
todos los acceptance criteria de la sección "Phase 1" están
chequeados en el archivo. Si algo es ambiguo, preguntá antes de
asumir.

3. Romper un archivo grande hasta budget de tamaño

/goal Refactorear src/api/handlers.ts. Done cuando ningún archivo
de src/api/ pase de 200 líneas. Mantener todos los exports
intactos. or stop after 15 turns.

4. Vaciar un backlog de issues

/goal Cerrar todos los issues con label "good-first-issue" del
repo. Done cuando `gh issue list --label good-first-issue` devuelve
vacío. Cada issue debe tener un PR asociado antes de cerrarse.

El patrón en los cuatro: end state medible + forma de chequearlo + constraint.

---

La receta de una condición que funciona

Tres ingredientes. Si falta uno, el goal se rompe.

1. End state medible

No "el código está bueno". No "todo anda". Algo que se pueda verificar: un test result, un exit code, un file count, un campo de un JSON, un linter que pasa.

Mal: /goal Hacer que el código esté más prolijo Bien: /goal Reducir warnings de ESLint a 0 en src/

2. Stated check

Cómo Claude prueba si llegó. Esto es lo que ejecuta el modelo principal en cada turno para que el evaluator tenga algo que leer.

Check: `npm run lint src/` exit code 0
Check: `wc -l src/api/*.ts | sort -n` ninguno sobre 200
Check: archivo CHANGELOG.md tiene una entrada con la versión 2.0

3. Constraint

Qué NO debe cambiar mientras Claude itera. Sin esto, Claude puede tomar atajos peligrosos para cerrar el goal: borrar tests, deshabilitar reglas del linter, comentar código.

Constraint: no tocar package.json
Constraint: no deshabilitar tests
Constraint: no modificar archivos fuera de src/auth/

Tip operacional: sumá un budget al final.

... or stop after 20 turns.

Si tu condición es difusa o el código es más pesado de lo que pensabas, el budget te salva de quemar tokens en un loop infinito. Cuando se cumple el límite, Claude para y te avisa con el estado actual.

---

Limitaciones que importan

/goal no funciona si tu configuración tiene alguna de estas opciones activas:

• disableAllHooks: true
• allowManagedHooksOnly: true

Tiene sentido: el evaluator de /goal es un hook administrado. Si bloqueás todos los hooks o solo permitís los tuyos, el evaluator no puede correr.

Si trabajás en un entorno con restricciones de hooks (empresa, compliance, sandbox endurecido), /goal no está disponible. Punto.

Las otras limitaciones a tener en cuenta:

• No es asincrónico. Mientras /goal está corriendo, esa sesión está ocupada. No podés hacer otra cosa en ese mismo Claude. Para paralelo, usá claude --bg o Agent View.
• El evaluator puede equivocarse. Es un modelo chico que solo lee texto. Si tu output es ambiguo, puede decir "cumplida" cuando no lo está, o al revés. Por eso un stated check mecánico (exit code) gana siempre a uno semántico ("el código está bien").
• No funciona con disableAllHooks (ya dicho, pero vale repetirlo porque es la causa más común de "che, no me arranca").

---

Cuándo /goal es la herramienta correcta

Sirve cuando se cumplen las tres:

• Tarea repetitiva con criterio de éxito objetivo
• Vos no querés sentarte a darle "seguí" cada turno
• El trabajo es lo suficientemente pesado para varios turnos (si es 1-2 turnos, no vale la pena el setup)

No sirve cuando:

• La tarea requiere decisiones de producto en cada paso (volvé al modo conversación normal)
• No tenés un criterio de éxito medible (refinálo antes, después usá /goal)
• Necesitás output incremental para revisión humana entre turnos

/goal es para delegar el "loop". No para delegar el "criterio".

---

FAQ

¿Reemplaza a los agents o subagents? No. Los subagents corren en su propio contexto y devuelven un resultado. /goal mantiene UN agente trabajando en la misma sesión hasta cumplir una condición. Son herramientas complementarias.

¿Cuántos tokens consume? Depende. El evaluator suma poco por turno (Haiku, contexto acotado). El modelo principal sigue cobrando como siempre. La métrica que importa es turnos × tokens por turno: por eso el indicador ◎ /goal active te muestra el total acumulado.

¿Puedo cambiar el modelo del evaluator? No expuesto en la doc actual. Anthropic eligió Haiku como default por velocidad y costo. Si necesitás algo más fino, podés escribir la condición de forma que el chequeo sea binario (exit code, file count) y minimizar lo que tiene que evaluar el modelo.

¿Funciona con cualquier modelo principal? Sí. /goal es independiente del modelo que estés usando para el trabajo (Sonnet, Opus, Haiku). Solo cambia cómo se cortan los turnos.

¿Qué pasa si Claude entra en loop? El evaluator lo va a marcar como "no cumplida" turno tras turno. Por eso el budget (or stop after N turns) es clave. Sin budget, podés quemar horas-token en un loop.

---

El punto

Antes de /goal, delegarle a Claude una tarea de N turnos requería tu presencia para mantenerla viva. Vos eras el clock del loop.

Ahora le pasás la condición de éxito, definís el budget, y Claude itera solo. Lo que cambia no es lo que Claude puede hacer — es cuánto tenés que estar vos en el medio.

Si todavía tenés sesiones donde te encontrás escribiendo "seguí", "ok continuá", "dale, terminá esto" cada 30 segundos, probablemente esas sesiones son candidatas para /goal.

La pregunta no es "puedo usar /goal acá". Es "qué tarea recurrente estoy haciendo a mano que tiene criterio de éxito medible".

Empezá por esa.

Si querés contexto sobre los otros mecanismos que Claude Code te da para configurar cómo trabaja, armé un artículo sobre los 4 lugares para inyectar contexto (CLAUDE.md, Skills, MCPs, Hooks). /goal es la pieza nueva que se suma a ese stack.