/goal en Claude Code: modo autónomo y Agent View en 2026

Documentación de referencia de Ailoot: ailoot.ai/docs/.

¿Qué es /goal en Claude Code?#

Antes, Claude Code se detenía después de cada respuesta y esperaba tu siguiente prompt. Esto funcionaba para tareas cortas, pero se venía abajo con las largas: una migración de API, arreglar 12 pruebas fallidas, refactorizar un archivo de 800 líneas; estas tareas requieren 20–30 iteraciones y cada una te hacía volver a la terminal.

/goal resuelve este problema con una idea sencilla: separar «quien hace el trabajo» de «quien decide cuándo está terminado». El agente principal escribe código. Un evaluador independiente (el rápido modelo Haiku) lee la conversación después de cada turno y responde una pregunta: «¿Se ha cumplido la condición?». Si no, el agente inicia otro turno. Si sí, el control vuelve a ti.

La documentación oficial de Anthropic lo define así:

Miles de agentes por la noche desde un teléfono: eso no es marketing, sino la práctica actual de un ingeniero de Anthropic. Y el mecanismo que lo hace posible es la combinación de /goal + Agent View, presentada en la misma versión el 11 de mayo de 2026.

¿Por qué se necesita el modo autónomo: qué había antes y después del 11 de mayo de 2026?#

La idea de «dejar que la IA trabaje durante la noche» existía desde el otoño de 2025, cuando Cursor Composer y el modo automático de Cline ya podían ejecutarse en segundo plano. Pero antes del 11 de mayo de 2026, Claude Code necesitaba una solución manual para ello: una tarea cron que llamara a claude -p cada N minutos, o un envoltorio que vigilara el estado de git y lanzara el siguiente prompt.

Este enfoque provocaba desastres con regularidad. El 22 de mayo de 2026, un desarrollador dejó un script así en ejecución durante la noche y despertó con una factura de $6,000. La causa principal: Anthropic cambió en silencio el TTL de la caché de Claude Code de una hora a cinco minutos, sin anunciarlo. Cron llamaba a producción cada 30 minutos; la caché tenía tiempo de caducar entre ejecuciones. Cada ejecución reconstruía desde cero un historial de 800,000 tokens. Escribir datos nuevos en la caché cuesta mucho más que leerlos de una caché activa.

El desarrollador no estaba haciendo nada exótico: usaba la herramienta tal como Anthropic la anunciaba.

/goal resuelve este problema con una arquitectura integrada:

1. Proceso supervisor que mantiene la sesión fuera de tu terminal y sobrevive al cierre de la ventana y a la suspensión del portátil.
2. Evaluador Haiku: un modelo económico comprueba cada turno; los tokens del evaluador cuestan unos céntimos.
3. Límite estricto de turnos en la condición: puedes escribir explícitamente or stop after 20 turns y se garantiza que la sesión se detenga.
4. Aislamiento con worktree para las sesiones en segundo plano: los cambios van a una rama separada sin tocar tu copia de trabajo.

La diferencia frente al enfoque de «escribe tu propio script bash» es que Anthropic convierte todos estos mecanismos en funciones propias de la herramienta, en lugar de trucos de terceros.

Cómo activar /goal en 3 pasos#

Paso 1. Actualiza Claude Code a la versión 2.1.139 o posterior.

Comprueba la versión:

claude --version

Si es anterior a la 2.1.139, actualiza:

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

Las versiones publicadas entre el 12 y el 19 de mayo de 2026 corrigieron errores importantes de la primera versión. En la 2.1.140 corrigieron un bloqueo silencioso en el que disableAllHooks impedía que funcionara el evaluador. En la 2.1.143 llegaron worktree.bgIsolation: "none" y una corrección para los bucles de hooks de parada. En la 2.1.144 (19 de mayo) se añadieron --resume para sesiones en segundo plano y --json para agentes y scripts. La versión mínima es la 2.1.143.

Paso 2. Escribe /goal con una condición.

Abre una sesión normal de Claude Code e introduce el comando:

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

No hace falta enviar otro prompt después: el comando inicia el primer turno inmediatamente. La condición puede escribirse en ruso, inglés o en una mezcla; el modelo entiende ambos idiomas. El límite de longitud es de hasta 4,000 caracteres.

Paso 3. Supervisa mediante la superposición en vivo.

Después de iniciar /goal, aparece un panel en vivo en la parte inferior de la terminal:

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

Lo que muestra:

• Turnos: cuántos turnos se han completado
• Tiempo transcurrido: cuánto tiempo ha pasado desde el inicio
• Tokens: total de tokens utilizados (la cifra principal para controlar el presupuesto)
• Último: el último motivo del evaluador para responder «aún no»

Un truco útil: si el evaluador devuelve el mismo motivo tres turnos seguidos, es señal de que estás en un bucle. Entonces pulsa Ctrl+C o escribe /goal clear (sinónimos: stop, off, reset, cancel), reformula la condición y vuelve a iniciar. Esta regla aparece en las guías de la comunidad sobre /goal como la señal principal de que hay un bucle: «se queda atascado en un motivo tres veces: es un bucle, sal».

Cómo escribir una buena condición: 5 reglas + 5 ejemplos#

La documentación de Anthropic describe tres elementos necesarios para una buena condición:

Una plantilla lista para usar incluye los tres elementos en una sola línea:

\n/goal [haz el trabajo] hasta [estado final medible] sin [restricciones que deben respetarse]\n

Cinco reglas que suelen causar problemas:

Regla 1. El estado final debe poder verificarse con un comando, no según el gusto personal.

No «haz que se vea bien», sino npm test exits 0. No «mejora la UX», sino Lighthouse Performance score above 90. El evaluador solo lee la transcripción: no ejecuta comandos ni mira capturas de pantalla. Si el resultado no puede registrarse en texto, el evaluador nunca responderá «sí».

Regla 2. Las restricciones deben ser explícitas y acotadas.

Sin restricciones, Claude podría arreglar las pruebas borrándolas o comentando las aserciones fallidas. Especifica without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Regla 3. Se necesita un límite estricto de turnos.

Añade or stop after N turns a todas las condiciones. Es un salvavidas contra los bucles interminables. Sin un límite, un bucle que se ejecuta durante una hora consume más tokens que hacer la misma tarea manualmente. Reserva presupuesto para ello.

Sin un límite, un bucle que se ejecuta durante una hora consume más tokens que hacer la misma tarea manualmente. Reserva presupuesto para ello.

Regla 4. Describe QUÉ, no solo CÓMO.

Si no mencionas los elementos visuales en la condición, Claude no los creará. Si la condición solo exige «que pasen las pruebas», Claude podría comentar pruebas complejas. Describe QUÉ quieres, no solo CÓMO lo verificarás.

Regla 5. Haz que Claude muestre pruebas en el chat.

El evaluador no ejecuta comandos: solo lee lo que Claude ya ha mostrado. Si la condición exige que «npm test esté en verde» pero Claude no mostró la salida de npm test en la transcripción, el evaluador dirá «aún no» para siempre. Añade a la condición la frase «muestra la salida de <command> en la conversación».

Cinco ejemplos funcionales para tareas comunes:

1. Migración de API:
/goal every call to getUser() has been replaced with fetchUser(), npm test passes, npm run build is green, no other API names have been touched, or stop after 30 turns

2. Arreglar pruebas:
/goal all failing tests in test/auth are now green (npm test shows 0 fails in the chat), without changing assertions or deleting tests, or stop after 20 turns

3. Calidad del código (tamaño de archivo):
/goal src/legacy/UserService.ts has been split into files under 200 lines each, all imports are updated, npm run build is green, or stop after 25 turns

4. Cerrar la lista de pendientes:
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a worktree branch, open a PR. Continue until the queue is empty or 6 issues have been processed

5. Auditoría de seguridad:
/goal every npm audit vulnerability with severity >= high is fixed, all existing tests pass, no breaking API changes, or stop after 15 turns

¿Quieres hacer algo más que ejecutar /goal y montar una configuración en la que el modo autónomo funcione de verdad en tu proyecto? /goal es solo el eslabón final. Antes deben estar preparados tres pilares: un clon de IA (tu metodología en Skills y Subagents), un segundo cerebro (CLAUDE.md y una carpeta plans/) e ingeniería de contexto (Plan Mode y /compact). Los tres componentes deben pensarse en conjunto: esa combinación permite trabajar con el contexto.

5 ejemplos en los que /goal funciona de verdad#

La documentación de Anthropic presenta cuatro tipos de tareas para las que /goal resulta adecuado:

Aquí tienes cinco ejemplos con condiciones listas para usar: tómalas y adáptalas a tu proyecto.

Ejemplo 1. Migra un módulo a una API nueva.

Escenario: estás pasando de REST a GraphQL o reemplazando la antigua función getUser() por la nueva fetchUser(). La tarea es mecánica, pero afecta a 30–50 archivos.

Condición:

/goal every getUser() in src/ has been replaced with fetchUser(), all calls updated to the new interface (id instead of userId), npm test passes, no files outside src/ touched, or stop after 30 turns

Por qué funciona: el estado final puede comprobarse con grep -r getUser src/ | wc -l (debería dar 0) y npm test exits 0. La restricción protege los archivos de pruebas.

Ejemplo 2. Arregla las pruebas fallidas.

Escenario: después de actualizar una biblioteca, fallaron 15 pruebas. Sabes que la solución es mecánica: actualizar los mocks y ajustar las aserciones al formato nuevo. No quieres hacerlo a mano.

Condición:

/goal all failing tests in test/ are now green, npm test shows the results in the chat with 0 failures, without deleting tests or commenting out assertions, or stop after 25 turns

Este es otro ejemplo de una condición del mismo tipo:

\nArregla todas las pruebas fallidas hasta que npm test devuelva 0, sin cambiar ningún archivo fuera del directorio /auth\n

Ejemplo 3. Divide una clase monolítica.

Escenario: un archivo de 1,200 líneas lo contiene todo: el modelo, el servicio, las utilidades y el cliente de API. Quieres dividirlo según el principio de «un archivo, una responsabilidad», actualizar todas las importaciones y mantener las pruebas en verde.

Condición:

/goal src/legacy/UserService.ts has been split into files under 200 lines, each file handles one responsibility (model, repository, api-client, validator), all imports are updated, npm run build is green, existing tests pass, or stop after 25 turns

Ejemplo 4. Cierra la lista de incidencias durante la noche.

Escenario: tienes un repositorio de código abierto con 20 incidencias abiertas etiquetadas como good-first-issue. Quieres que Claude las procese durante la noche.

Condición:

/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a separate worktree branch worktree-issue-N, open a PR with a description. Continue until the queue is empty or 6 issues have been processed, or stop after 80 turns

El número 6 no se eligió al azar: es un límite realista para una noche con un plan Pro. Este es un caso particular, no un valor predeterminado reproducible.

Ejemplo 5. Auditoría de seguridad.

Escenario: npm audit muestra 8 vulnerabilidades de gravedad alta. Quieres que Claude las arregle sin actualizar versiones principales.

Condición:

/goal every npm audit vulnerability with severity high+ is fixed, npm audit shows 0 high in the chat, all existing tests pass, no breaking API changes, no major version bumps to packages, or stop after 15 turns

Qué NO hacer con /goal:

Croucher expresa con contundencia la regla práctica en su guía: no uses /goal en tareas en las que «terminado» signifique «se ve bien», «se siente bien», «está bien diseñado» o «es divertido». El evaluador solo lee la transcripción: no ejecuta herramientas ni puede valorar cómo funciona el resultado. Esta regla descarta el 80% de las tareas subjetivas en las que /goal entra en bucle sin producir nada útil.

Cuándo /goal hace que gastes dinero en vano: 3 antipatrones#

Antipatrón 1. Condición vaga sin un límite estricto de turnos.

El error más común es una condición como «mejora el código», «hazlo bien» u «optimízalo». Sin un límite de turnos, el agente seguirá ejecutándose hasta agotar tu cuota.

Findskill describió un caso real:

$200 durante 14 horas con una condición vaga equivale al límite semanal completo del plan Max. Te despiertas por la mañana sin cuota y sin un resultado útil.

Medida de protección: termina todas las condiciones con or stop after N turns (15 para tareas fáciles, 50 para las difíciles y 100 como máximo para ejecuciones nocturnas).

Antipatrón 2. Bucle recursivo con la caché rota.

La historia del 22 de mayo de 2026: $6,000 durante la noche porque Anthropic cambió discretamente el TTL de la caché de una hora a 5 minutos. El desarrollador no utilizaba directamente /goal, pero la lógica era la misma: un bucle autónomo con un temporizador cron de 30 minutos reconstruía desde cero un historial de 800,000 tokens cada vez.

El problema principal era que la automatización externa desconocía los cambios internos del proveedor. Lo mismo podría ocurrir con /goal si lo ejecutas durante 8 horas sin supervisión: el uso de tokens aumenta de forma no lineal y la caché de prompts no funciona como crees.

Medidas de protección:

1. No ejecutes /goal durante más de 8 horas sin comprobaciones intermedias.
2. Activa los límites de uso en Ajustes → Uso (una nueva medida de protección tras el incidente de $6,000).
3. Abre claude agents dos veces durante la noche: echa un vistazo con Space y comprueba que el recuento de turnos no crezca más rápido de lo previsto.
4. Para cadenas de modelos costosas (Opus 4.7), establece un límite de turnos más estricto: 30 como máximo.

Antipatrón 3. Creatividad con /goal.

Croucher usó /goal para crear un juego: la condición incluía determinismo, invariantes y comprobar que se pudiera completar el nivel. Se creó el juego, pasaron las pruebas y el evaluador dijo «objetivo alcanzado». El juego no tenía elementos visuales: la condición no mencionaba los gráficos.

Esto ilustra la regla general: el evaluador optimiza exactamente lo que mides. Si la condición no menciona los elementos visuales, no los habrá. Si solo menciona las pruebas, podría comentar las aserciones.

Medida de protección: no uses /goal para nada que dependa del gusto (diseño, textos, UX). Vuelve a una sesión normal o a Plan Mode: así sigues participando en las decisiones.

¿Qué es Agent View en Claude Code y cómo abrirlo?#

Si /goal es el comando «trabaja hasta terminar», Agent View es la sala de control donde puedes ver todos esos comandos a la vez. Anthropic lo describe así:

Comando para abrirla:

claude agents

Se abre una TUI: un panel de texto dentro de la terminal. La lista de sesiones está a la izquierda y el panel de vista previa, con el mensaje más reciente de la fila seleccionada, a la derecha.

Seis estados de sesión:

Atajos principales:

↑ / ↓             moverse por la lista de sesiones
Space             panel de vista previa (ver sin conectarse)
Enter / →         conectarse a una sesión (entrar en ella)
←                 desconectarse (salir sin cerrarla)
Ctrl+T            fijar (proteger la sesión para que no se detenga automáticamente)
Ctrl+X            detener la sesión; vuelve a pulsar en un plazo de 2 sec para eliminarla
Ctrl+R            cambiar el nombre
Ctrl+S            alternar la agrupación (estado ↔ directorio)

Cómo iniciar una sesión en segundo plano:

Desde Claude Code interactivo:

/bg fix the failing test test/auth/login.test.ts

O directamente desde el shell:

claude --bg "fix the failing test test/auth/login.test.ts"

O con un nombre (para que aparezca en Agent View con una etiqueta reconocible):

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

La sesión en segundo plano se añade automáticamente a Agent View: inicia con --bg, abre claude agents y la verás en la lista.

La función principal: las sesiones sobreviven a la suspensión del portátil y al cierre de la ventana:

Pero si apagas el portátil o lo reinicias manualmente, las sesiones en segundo plano terminan con el estado Failed. Las ejecuciones nocturnas con muchos agentes en segundo plano solo funcionan si el portátil permanece encendido.

Worktrees: cómo aísla Claude las sesiones paralelas#

Los worktrees resuelven el problema principal del trabajo autónomo en paralelo: ¿qué pasa si dos sesiones intentan editar src/auth.ts a la vez? Antes de la versión 2.1.139, estas sesiones podían sobrescribir literalmente los cambios de la otra. Con Agent View, Anthropic introdujo el aislamiento automático:

Cómo funciona en la práctica:

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate copy on branch worktree-split-userservice

Cada sesión trabaja en su propia copia. Cuando termina la tarea, fusionas las ramas necesarias en main.

Trampa peligrosa: borrar una sesión elimina su worktree.

Si eliminas una sesión en Agent View (pulsa Ctrl+X dos veces), su worktree desaparece. Se pierden todos los cambios sin commit. Antes de borrar una sesión en Agent View, confirma o sube los cambios.

Excluir el aislamiento (en casos poco frecuentes):

Si tienes un repositorio en el que los worktrees de git no funcionan (por ejemplo, una configuración con enlaces simbólicos o un monorepo grande con una copia lenta), puedes desactivar el aislamiento:

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

Entonces las sesiones en segundo plano editarán directamente tu copia de trabajo. Esta opción para excluir el aislamiento llegó en la versión 2.1.143, tras las quejas de equipos con monorepos grandes.

El paralelismo consume la cuota:

Eso significa que un plan Pro ($20/month) basta para 1–2 sesiones paralelas durante la noche, no diez. Si quieres ejecutar muchos agentes en paralelo, necesitas Max o Enterprise.

Cómo combinar /goal + Plan Mode + subagents en tareas largas#

Un fallo habitual es escribir directamente /goal build a new feature. No funciona porque el evaluador no sabe qué aspecto tiene una «función terminada». Necesitas un plan con casillas que el evaluador pueda verificar una por una.

Capa 1. Plan Mode crea un plan por fases.

En Plan Mode, pide a Claude que cree un plan de cambios detallado, dividido en 5–7 fases con casillas verificables. Guárdalo como plans/2026-05-24-google-oauth.md. Cada fase tiene 3–7 casillas con acciones concretas.

Capa 2. Los subagents dividen el trabajo por fases.

Si el plan se puede paralelizar (por ejemplo, las fases son independientes: un endpoint de backend + un formulario de frontend + una migración de DB), puedes iniciar cada fase en una sesión separada en segundo plano mediante claude --bg --name "<phase>". Cada sesión obtiene su propio worktree.

Capa 3. /goal ejecuta el ciclo hasta completar las casillas.

/goal all phases 1–7 in plans/2026-05-24-google-oauth.md are complete and marked [x], all tests in test/auth pass (npm test shows 0 failures), npm run build is green, or stop after 50 turns

Después de cada turno, el evaluador lee el plan, comprueba qué casillas están completas y, si queda alguna, el agente continúa.

Esta combinación depende de tres componentes:

• ingeniería de contexto: el contexto adecuado en plans/; el evaluador lo lee
• segundo cerebro: la carpeta plans/ guarda el plan entre sesiones
• clon de IA: CLAUDE.md define las reglas que sigue el agente

Sin CLAUDE.md, /goal podría sugerir una solución que rompa la arquitectura. Sin un plan en plans/, el evaluador no conoce los criterios de éxito. Sin subagents, no hay fases paralelas: todo es secuencial.

Cómo comparar /goal con Codex, Cursor y otros modos de agentes#

/goal añade una comprobación de finalización separada después de cada turno. Otros productos ofrecen modos distintos: una CLI local, una tarea alojada en nube y una sesión de editor supervisada no son unidades intercambiables. En particular, no describas todo el trabajo de Codex CLI como un contenedor en nube ni supongas un mismo modelo evaluador o método de facturación para todas sus ejecuciones.

Usa la misma instantánea del repositorio y tarea con las mismas comprobaciones de aceptación. Registra estas dimensiones para cada candidato:

Afirmar que una herramienta usa un múltiplo fijo de tokens exige esas condiciones y mediciones para el mismo resultado correcto. Un porcentaje de benchmark también necesita versión de la prueba, modelo, entorno de evaluación y ajustes de ejecución; los porcentajes de Terminal-Bench sin esos detalles no sustituyen esas pruebas. Este artículo no ofrece un benchmark independiente entre herramientas.

Elige según el trabajo necesario: ediciones supervisadas, una tarea de fondo acotada o varios turnos con una condición explícita de finalización. Prueba el modo admitido por el producto instalado en vez de suponer que todo un competidor carece de autonomía. Separa la aprobación de permisos de la continuación de tarea: aprobar automáticamente una llamada de herramienta no demuestra que se haya cumplido el objetivo.

Lista de comprobación antes de lanzar /goal: 7 puntos#

Lista de comprobación antes de cada ejecución de /goal:

1. Claude Code versión 2.1.139+: compruébala con claude --version y actualiza si es inferior. La versión mínima recomendada es la 2.1.143 (15 de mayo de 2026), que corrige los bucles de hooks de parada.

2. La condición incluye un estado final verificable: en lugar de «mejóralo», especifica npm test exits 0. Si no se te ocurre un comando bash para verificar el resultado, /goal no es adecuado para esta tarea.

3. Hay un límite estricto de turnos: todas las condiciones especifican or stop after N turns. Usa 15 para tareas fáciles, 50 para las difíciles y 100 como máximo para ejecuciones nocturnas.

4. Las restricciones son explícitas y acotadas: without modifying files outside /auth, without removing existing assertions, without bumping major versions. Sin ellas, Claude podría arreglar las pruebas borrándolas.

5. Todos los cambios importantes están confirmados o subidos: si no estás trabajando en un worktree (por ejemplo, worktree.bgIsolation: "none"), Claude edita tu copia de trabajo. Un error podría hacerte perder el trabajo sin guardar.

6. Los límites de uso están activados en Ajustes → Uso: una nueva medida de protección tras el incidente de $6,000. Establece un límite diario, por sesión y mensual.

7. Agent View claude agents está abierto en otra ventana: para las tareas largas, echa un vistazo con Space una vez cada hora. Si el número de turnos aumenta más rápido de lo esperado o el evaluador repite el mismo motivo durante tres turnos, pulsa Ctrl+C y reformula la condición.

Un punto más: nunca ejecutes /goal con --dangerously-skip-permissions en código ajeno o desconocido. Esa combinación desactiva todas las comprobaciones y permite que el agente haga lo que quiera en tu proyecto. El autor de este análisis solo lo usa en un worktree nuevo donde no hay nada que perder.

/goal es una función potente, pero no es magia. Funciona exactamente tan bien como formules la condición. Si puedes describir «terminado» con palabras que un comando pueda verificar, /goal se encargará del resto. Si no, vuelve a una sesión normal o a Plan Mode.

Puedes seguir explorando Ailoot en ailoot.ai.