Claude /goal — un comando, la IA termina la tarea

Claude /goal: el único comando que obliga a la IA a TERMINAR la tarea de verdad

La mayoría de la gente usa Claude como ChatGPT. Haces una pregunta, recibes una respuesta, te detienes. Los usuarios avanzados usan un comando — /goal — y eso lo cambia todo.

En este post te voy a mostrar exactamente:

Qué hace /goal y en qué se diferencia de /loop y del Stop hook
4 reglas sin las que el comando es inútil (3 de la documentación oficial + 1 de la práctica)
3 prompts copy-paste probados (QA, feature, refactor)
5 casos de uso reales — desde corregir bugs durante la noche hasta migraciones de API
Por qué esto cambia económicamente cómo funciona una agencia de IA

Comenta GOAL debajo de mi carrusel en Instagram — te envío el toolkit completo (10 prompts + diagrama de workflow + cheat sheet de buenas prácticas) por DM.

Qué es /goal

/goal es un comando integrado en Claude Code (requiere v2.1.139 o superior). Defines una condición de finalización y Claude sigue trabajando automáticamente hasta que esa condición se cumpla — sin necesidad de promptear cada iteración.

Mecánica según la documentación oficial de Anthropic:

Escribes /goal más una condición (hasta 4.000 caracteres)
Después de cada turn, un modelo pequeño y rápido (por defecto Haiku) comprueba si la condición se cumple
Si no — Claude empieza otro turn con la razón "por qué aún no" como guía
Si sí — el goal se borra, queda registrado como achieved en el transcript
Mientras está activo, un indicador ◎ /goal active muestra la duración

El evaluador no llama a tools. Sólo juzga lo que Claude ya ha mostrado en la conversación. La condición tiene que ser algo que el propio output de Claude pueda demostrar.

Lo que la comunidad de desarrolladores llama "Ralph loop" — un patrón donde la IA verifica su propio trabajo en vez de declarar "todo bien". Anthropic lo lanzó como comando oficial.

En qué se diferencia /goal de /loop y del Stop hook

Hay tres formas de mantener la sesión activa entre prompts. Elige según qué debe iniciar el siguiente turn:

Comando	El siguiente turn empieza cuando	Se detiene cuando
`/goal`	Termina el turn anterior	Un modelo confirma la condición
`/loop`	Pasa un intervalo de tiempo	Tú lo paras o Claude decide que está hecho
Stop hook	Termina el turn anterior	Tu script o prompt lo decide

/goal es un shortcut con scope de sesión — activo sólo en la sesión actual. El Stop hook vive en tu archivo de settings y aplica a cada sesión dentro de su scope.

Combina /goal con Auto mode — que aprueba las llamadas a tools dentro de un turn. Auto mode elimina los prompts por cada tool, /goal elimina los prompts por cada turn. Juntos = autonomía total.

Consigue el toolkit completo — diagrama de workflow + 10 prompts + cheat sheet. Deja tu email abajo, te enviamos el PDF.

4 reglas sin las que /goal no funciona

Aquí está la trampa. La calidad del comando = la calidad del output. La documentación oficial lista 3 elementos de una buena condición. En la práctica añado un cuarto — presupuesto de tiempo. Sin los cuatro el comando se atasca, toma atajos o se detiene antes de tiempo.

Regla 1 — Estado final medible

❌ "Arregla el código" ✅ "Todos los tests en test/auth pasan + lint limpio"

De la documentación: "un estado final medible — un resultado de test, un exit code de build, un conteo de archivos, una cola vacía". Algo con respuesta binaria: sí o no.

Regla 2 — Check explícito (cómo demostrarlo)

❌ "Haz que funcione mejor" ✅ "npm test exit 0, coverage > 90%, lint limpio"

De la documentación: "un check explícito: cómo Claude debe demostrarlo, como 'npm test exits 0' o 'git status is clean'". Un comando o estado de archivo concreto que verificar.

Regla 3 — Constraints

❌ "Refactoriza la API" ✅ "Refactoriza la API a v2. NO BORRAR tests. Máx 15 archivos cambiados. Performance ±5%."

De la documentación: "constraints que importan: cualquier cosa que no debe cambiar en el camino". Sin esto Claude puede "tomar atajos" — borrar tests molestos.

Regla 4 — Presupuesto de tiempo (de la práctica, NO de la documentación)

❌ Sin límite de tiempo — la sesión puede arrastrarse horas ✅ Añade o detente después de 20 turns o o detente después de 60 minutos a la condición

De la documentación: "Para limitar cuánto dura un goal, incluye una cláusula de turn o tiempo en la condición". Claude reporta progreso contra esa cláusula y el evaluador lo ve.

3 prompts copy-paste

Copia, adapta a tu proyecto, ejecuta en Claude Code con Auto mode activo (Shift + Tab cicla en CLI: default → acceptEdits → plan → auto).

Prompt 1 — QA / corrección autónoma de bugs

/goal todos los tests en test/auth pasan y el paso de lint está limpio, o detente después de 20 turns

El mínimo. Brillante para "déjalo durante la noche, revisa por la mañana". Caso práctico: después de un merge grande los tests de auth fallan — lanzas /goal, te vas a dormir. Por la mañana Claude muestra qué arregló + la razón de cada iteración en el transcript.

Prompt 2 — implementación de feature con verificación

/goal implementa dark mode siguiendo el spec de Figma, todos los componentes actualizados,
coverage de tests >90%, sin errores de consola, impacto de performance <5ms al cargar,
no modificar contratos de API existentes, o detente después de 30 turns

Claude no se limita a construir la feature — tiene que probar con tests que funciona. Obtienes feature + cobertura de tests + benchmark de performance en 1 sesión.

Prompt 3 — refactor / migración

/goal migra todas las llamadas API al nuevo cliente v2, actualiza el manejo de errores,
todos los tests existentes pasan, añade 3 tests de integración nuevos, sin nuevos errores de TypeScript,
no borrar ningún test existente, máx 25 archivos cambiados, o detente después de 40 turns

El caso más duro — una migración grande. Con /goal Claude lo hace sistemáticamente y comprueba el progreso después de cada cambio.

Comandos operativos

Comprobar status

Escribe /goal sin argumentos para ver:

Condición actual
Duración
Número de turns evaluados
Gasto de tokens
La razón más reciente del evaluador

Limpiar goal

/goal clear

Alias: stop, off, reset, none, cancel. Ejecutar /clear (nueva conversación) también elimina cualquier goal activo.

Resumir sesiones

Una sesión resumida con --resume o --continue restaura el goal activo. Sin embargo: el contador de turns, el timer y la baseline de gasto de tokens se resetean. Un goal ya achieved o cleared no se restaura.

Modo no interactivo

claude -p "/goal CHANGELOG.md tiene una entrada para cada PR fusionado esta semana"

Funciona en modo headless y a través de Remote Control.

5 casos de uso reales

1. QA autónomo / bug fixing

El clásico. "Arreglar tests" suele comerse 2-3 horas. Con /goal — lanza antes de dormir, listo por la mañana. Una sesión de Claude de 8h > 30 min de tu revisión.

2. Refactor / migración grande

Migración de design system, upgrade de librería, cambios de patrón a través del codebase. Tradicionalmente 2-3 días de trabajo. Con /goal + constraints claras — barrida completa en 1 sesión.

3. Implementación de feature con prueba

Construir feature + probarla con tests. Sin /goal obtienes "funciona" declarado por Claude. Con /goal obtienes los tests que lo confirman — porque el evaluador los lee del transcript.

4. Limpieza de tech debt con quality gates

Burn-down del backlog. Configura /goal a "arregla N items del backlog, cada uno tiene que pasar el test X, no introducir warnings nuevos". Claude cierra tickets metódicamente.

5. Sesiones autónomas largas

Lanza /goal con un scope grande antes de comer o de dormir (mejor en Auto mode), márchate. Revisa el output y la entrada de achieved en el transcript más tarde.

Requisitos (de la documentación oficial)

/goal no funcionará si:

La versión de Claude Code es < v2.1.139
No has aceptado el diálogo de workspace trust (el evaluador forma parte del sistema de hooks)
disableAllHooks está activado en cualquier nivel de settings
allowManagedHooksOnly está activado en managed settings

Auto mode (que permite que /goal funcione sin prompts de permisos) requiere:

Plan Max, Team, Enterprise, o API (NO Pro)
No funciona en Bedrock, Vertex, Foundry
CLI/JetBrains: cicla con Shift + Tab (default → acceptEdits → plan → auto)
VS Code: activa "Allow dangerously skip permissions" en los settings de la extensión
Desktop: selector de modo al lado del botón de enviar

En todos los casos, si /goal no va a funcionar — el comando te dice por qué en vez de quedarse callado.

Por qué esto cambia la economía de una agencia de IA

El prompteo estándar de Claude — incluso en Claude Code — suele significar "mid-task drift" y paradas prematuras. Que arreglas a lo largo de 3-5 sesiones.

/goal ancla a Claude a criterios de éxito persistentes. Claude se comporta como un senior engineer de $200/h — uno que termina el trabajo en vez de decir "creo que va bien, avísame si necesitas algo más".

Consecuencia práctica para una agencia de IA:

Antes: 5 sesiones × 30 min = 2,5h de tu tiempo por tarea
Con /goal: 1 sesión × 5 min de setup + autónomo en background = ~5 min de tu tiempo

Eso es una mejora de productividad de 20-30× para una tarea típica de refactor / feature.

Económicamente: en vez de cobrar proyectos como "horas + horas extra de rescate" — cobras estrategia + entregable verificado. Horas facturadas → outcome entregado.

El coste del evaluador suele ser insignificante comparado con el gasto del turn principal (Haiku por defecto). Los tokens del evaluador se facturan en un modelo pequeño separado.

Errores más comunes (y cómo arreglarlos)

Error 1 — goals vagos → output vago

"Hazlo mejor" → Claude improvisa. No converge, el evaluador no tiene nada que juzgar.

Fix: APLICA SIEMPRE las 4 reglas. La condición tiene que ser algo que el propio output de Claude pueda demostrar en la conversación.

Error 2 — sin constraints → Claude toma atajos

Sin "no borrar tests" Claude puede eliminar tests molestos sólo para pasar el check.

Fix: Lista explícitamente lo que NO hacer. "No borres X, no modifiques Y, mantén Z intacto, máx N archivos cambiados".

Error 3 — la condición requiere cosas no presentes en el transcript

El evaluador no llama a tools. No lee archivos por su cuenta. Sólo juzga lo que ya se dijo en la conversación.

Fix: Cada condición DEBE incluir un "muestra prueba" explícito que Claude tenga que mostrar en el transcript. Ej.: "ejecuta npm test y muestra 0 failures en el output".

Error 4 — Auto mode apagado → Claude pide permiso para cada cambio

Sin Auto mode Claude pide aprobación para cada operación de terminal. El loop nunca se cierra porque espera tu OK.

Fix: Activa Auto mode (Shift + Tab cicla por los modos en CLI). Requiere plan Max/Team/Enterprise/API.

Error 5 — sin presupuesto de tiempo → el goal se arrastra horas

Sin o detente después de N turns un goal puede arrastrarse si la condición es imposible de cumplir.

Fix: Añade siempre o detente después de 20 turns (o una cláusula de tiempo) como red de seguridad.

Qué viene después

El comando /goal es una de las bases que los power users de Claude Code usan a diario. El workflow completo — combinado con /loop, Stop hooks y Auto mode — es ingeniería autónoma que la mayoría de agencias aún no han implementado.

Si estás construyendo un producto / aplicación / sistema en 2026 — o usando Claude en una agencia — /goal debería ser lo primero que aprendas después de los prompts básicos.

Comenta GOAL en mi Instagram (@prospere.ai_) debajo del carrusel de /goal — te envío el toolkit completo:

10 prompts probados de /goal (PL + EN) — listos para copy-paste, por caso de uso
Diagrama de workflow /goal + /loop + Stop hooks + Auto mode
Cheat sheet de las 4 reglas de buenas prácticas
Bonus: economía de agencia con /goal — case study

O deja tu email abajo — te enviamos el PDF + una serie deep-dive de 5 días (autonomous overnight runs, common pitfalls, cómo debuggear /goal cuando no converge).

Fuente oficial: code.claude.com/docs/en/goal (Anthropic, verificado 2026-05-21).

Bartek — prospere.ai · linkedin.com/in/bartlomiej-golebiowski