comunidad bóvedagoal-claude-code

`/goal` — la meta que Claude no suelta hasta cumplirla

El 11 de mayo de 2026 Anthropic publicó /goal dentro de Claude Code: un comando que setea una condición de completitud, y Claude sigue trabajando turno tras turno hasta que un modelo evaluator confirme que la condición se cumplió. Resuelve el dolor clásico de que Claude pierde el hilo a mitad de una tarea larga — porque ahora el hilo lo sostiene el evaluador, no vos.

/goal · Anthropic · Claude Code

Seteás una condición de completitud y Claude sigue trabajando sin que le insistas en cada paso, hasta que el evaluador confirme que llegó.

Esta entrada cubre todo el camino desde cero: instalar o actualizar Claude Code, los tres requisitos duros (trust dialog del workspace, hooks habilitados, versión al día), cómo se setea / chequea / limpia / reanuda un /goal, la anatomía de una condición efectiva con los tres ingredientes del docs oficial y el límite de 4000 caracteres, el combo flagship /plan + /goal donde Plan Mode diseña el camino y /goal lo ejecuta sin perder el hilo, cinco condiciones listas para copiar (landing de waitlist, refactor de archivo gordo, limpieza de backlog, docs y migración), combinación con auto mode para ejecución totalmente desatendida, modo headless con claude -p para cron jobs y CI, cómo decide el evaluador y por qué solo lee el transcript, y buenas prácticas para que la condición sea verificable y no termine en un loop infinito.

Qué es Requisitos Primer /goal Condición efectiva /plan + /goal Ejemplos listos Auto · Headless Evaluador Buenas prácticas

Anthropic · 11 mayo 2026Built on prompt-based Stop hooksEvaluator: small fast model (Haiku default)Pro · Max · Team · Enterprise · APIHasta 4000 chars por condición

01 · concepto

Qué es /goal y por qué te importa

Te habrá pasado: estás trabajando con Claude en una migración o una página entera, le pasaste el contexto bien al principio, y a los cinco turnos ya está editando archivos que vos no le pediste, o se olvidó del archivo de tests, o se quedó esperando que vos lo guíes en cada paso. El dolor no es que Claude sea malo planeando — es que después de cada turno te devuelve el control y vos tenés que volver a empujarlo.

/goal invierte eso. Vos seteás una condición de completitud al principio (por ejemplo: todos los tests en test/auth pasan y el build sale verde) y Claude empieza a trabajar. Cuando termina cada turno, un modelo evaluator chico y rápido (Haiku por default) lee la conversación y decide: ¿se cumplió la condición? Si la respuesta es sí, el goal se limpia solo. Si es no, Claude arranca otro turno con la razón del evaluador como guía. El control no regresa a vos hasta que la meta esté lograda.

Qué sí es

· Una condición evaluada por un modelo chico al final de cada turno — yes/no + razón corta.
· Reanudación automática: si la condición no se cumple, Claude arranca otro turno sin que vos digas nada.
· Un indicador visible ◎ /goal active que te dice cuánto lleva corriendo.
· Se limpia sola apenas la meta se cumple — no hay que apagarla manual.
· Una condición hasta 4000 caracteres, suficiente para destilar un plan entero adentro.
· Persiste a claude --resume y --continue (con contador reseteado).

Qué NO es

· No corre tools por sí solo — sigue siendo Claude el que ejecuta cada acción. El evaluator solo decide cuándo parar.
· No lee archivos en vivo — solo lee lo que aparece en el transcript de la conversación.
· No es paralelismo — es secuencial, un turno detrás del otro, una sola sesión.
· No reemplaza el thinking del modelo principal: el evaluator decide si la meta se cumplió, no cómo llegar.
· No es lo mismo que /loop: /loop arranca turnos por intervalo de tiempo, /goal por condición lograda.
· No funciona si los hooks están deshabilitados — la sección de requisitos te explica por qué.

Cuatro casos reales donde /goal brilla (del docs oficial):

· Migración de API — Claude reemplaza llamadas legacy hasta que cada call site compila y los tests pasan.
· Design doc completo — implementar un documento de diseño hasta que todos los acceptance criteria se cumplen.
· Splitear un archivo gordo — partir un módulo en piezas hasta que cada una está bajo un budget de líneas.
· Limpiar un backlog — procesar issues labeled hasta que la cola queda vacía.

02 · prerequisitos

Lo que necesitás antes de tipear /goal

Antes de pedirle a Claude que mantenga una meta, hay tres requisitos duros — los tres están en la documentación oficial. Si alguno falla, /goal te avisa por qué en lugar de hacer nada silenciosamente.

Requisito 1

Trust dialog aceptado

El evaluador es parte del sistema de hooks, así que el workspace donde corrés /goal tiene que estar marcado como confiable. La primera vez que abrís Claude Code en un proyecto te lo pregunta — si dijiste sí ya estás. Si dijiste no, te lo va a volver a preguntar.

Requisito 2

Hooks habilitados

disableAllHooks no puede estar seteado en ningún settings file, y allowManagedHooksOnly no puede estar seteado en managed settings. Si tu sysadmin desactivó hooks por política, /goal va a estar bloqueado por diseño.

Requisito 3

Claude Code al día

La doc oficial no marca una versión mínima específica — /goal es feature reciente. Si tu Claude Code es de antes de mayo 2026, actualizá. La verificación es claude --version y después comparás con el releases del paquete.

Verificar versión de Claude Code

claude --version

Actualizar Claude Code (npm)

npm install -g @anthropic-ai/claude-code@latest

Instalar Claude Code desde cero (npm)

npm install -g @anthropic-ai/claude-code

¿No tenés Claude Code instalado? Bajá la app desde claude.com/claude-code o instalalo por terminal con npm desde el paquete oficial en npm. La guía completa paso a paso vive en /community/instalar-claude-code — si nunca usaste la terminal, empezá ahí antes de seguir con /goal.

Red de seguridad: si después de actualizar /goal te tira un comando no reconocido, corré claude --help en tu versión. La sintaxis exacta de los flags puede ajustarse entre releases, pero --help siempre lista lo que tu versión soporta. Si dice que /goal no existe, todavía no tenés la versión que la incluye.

03 · primer goal

Cómo se setea, se chequea, se limpia y se reanuda

El mismo comando /goal hace tres cosas distintas según lo que le pases al lado. Setea, chequea o limpia. No hay que recordar tres comandos — solo cambia el argumento.

Setear

Tipear /goal <condición> arranca un turno inmediato usando la condición como directiva. No hace falta enviar un prompt aparte — el goal SÍ es tu prompt. Si ya había un goal activo, el nuevo lo reemplaza.

Chequear estado

Tipear /goal solo (sin argumento) te muestra el estado: condición actual, cuánto lleva corriendo, cuántos turnos evaluados, gasto en tokens, y la última razón que devolvió el evaluador. Si no hay goal activo pero hubo uno completado en la sesión, muestra ese resumen también.

Limpiar

Tipear /goal clear remueve el goal antes de que se cumpla. Los aliases stop, off, reset, none y cancel también funcionan. Tipear /clear para empezar conversación nueva también lo limpia.

Reanudar

Si un goal estaba activo cuando cerraste sesión, claude --resume o --continue lo restaura. La condición sobrevive pero el contador de turnos, el timer y el baseline de tokens vuelven a cero. Un goal ya completado o limpiado NO se restaura — eso es esperado.

Setear un goal con condición

/goal todos los tests en test/auth pasan y npm run lint exit 0

Ver el estado del goal activo

/goal

Limpiar el goal antes de cumplirse

/goal clear

Reanudar sesión con goal activo

claude --resume

Buscá el indicador: mientras un goal está activo, Claude Code muestra ◎ /goal active en la barra inferior con el tiempo corrido. Si no lo ves, el goal no está corriendo — tipeá /goal para ver por qué. Cada vez que el evaluador devuelve no, su razón aparece arriba del próximo turno como guía, así que podés leer en vivo qué le falta a la condición para cumplirse.

04 · anatomía

Cómo escribir una condición que el evaluador pueda juzgar

Una buena condición tiene tres partes — están en el docs oficial. Si te falta una, el evaluador queda atrapado entre sí y no, y Claude sigue trabajando sin saber qué le pide la meta exactamente. Si te faltan dos, el goal nunca se cumple y consume turnos hasta que vos lo cortás.

Un estado medible único

Tiene que ser algo verificable: resultado de tests, exit code de un build, cantidad de archivos, una cola vacía. Si no podés contestarlo con sí o no después de leer la conversación, no sirve.

todos los tests en test/auth pasan

Un chequeo declarado

Decile a Claude cómo lo va a probar. El evaluator solo lee el transcript — si Claude no corre el comando explícito, no hay evidencia para juzgar.

npm test exit 0 y la salida queda en el transcript

Restricciones que importan

Lo que NO debe pasar en el camino. Sirve para evitar atajos creativos del modelo (borrar el test que falla, mockear la API en lugar de arreglarla).

ningún archivo dentro de test/ se modifica

Límites duros del input

· La condición puede tener hasta 4000 caracteres — suficiente para pegar un plan entero adentro.
· Para evitar runs infinitos, agregá una cláusula de tope: or stop after N turns. Claude reporta progreso contra ese tope cada turno y el evaluador lo lee.
· La condición es el prompt del primer turno — no hace falta mandar otro mensaje después de tipear /goal.

Tres ejemplos del docs oficial (en inglés porque así están publicados)

Tests + lint clean

Del docs oficial. Una sola cláusula, dos chequeos, exit code implícito.

/goal all tests in test/auth pass and the lint step is clean

Changelog actualizado

El ejemplo del docs para correr /goal en modo headless con claude -p.

/goal CHANGELOG.md has an entry for every PR merged this week

Migración con bound de turnos

Cómo agregar un techo de turnos para que el goal no corra eterno si algo externo cambia.

/goal every call site of legacyApi compiles and tests pass, or stop after 30 turns

La honestidad importante: el evaluador NO corre tools. No lee archivos, no chequea procesos, no consulta la red. Solo lee la conversación. Si tu condición dice "npm test pasa", Claude tiene que correr npm test y dejar el output en el transcript — si no, el evaluador no tiene cómo juzgarlo. Escribí condiciones que pidan explícitamente que la evidencia aparezca: "corré npm test y mostrá la salida", "corré git status al final", "listá los archivos modificados".

05 · combo flagship

/plan + /goal — el combo que cambia todo

Sección flagship

/goal solo es bueno. /plan solo es bueno. Pero el combo de los dos te da algo distinto: ejecución autónoma estructurada. /plan diseña el camino antes de tocar código — discute archivos, restricciones, orden — y te lo devuelve para que lo aprobés. /goal toma ese plan ya validado y lo ejecuta hasta cumplirse, sin que vos tengás que re-explicar a mitad de camino lo que ya quedó claro en el plan.

Si tirás /goal solo sin plan previo, Claude inventa el plan en el primer turno — y ahí está la varianza. Puede agarrar bien o agarrar mal, depende de cómo escribiste el prompt. Con /plan primero, eliminás esa varianza: el plan ya está discutido, las decisiones de arquitectura ya están tomadas, y el goal solo verifica que el plan se ejecutó completo.

1
Activar Plan Mode
Apretás Shift+Tab hasta llegar al modo Plan dentro de Claude Code (o /plan si está disponible). El indicador del modo aparece en la parte inferior de la sesión.
2
Explicar lo que querés con contexto
Le pasás todo: archivos involucrados, restricciones, criterios de éxito, qué NO debe romper. Cuanto más concreto el contexto, más concreto el plan.
3
Recibir el plan estructurado
Claude devuelve un plan paso a paso antes de tocar código — qué archivos va a editar, en qué orden, qué tests van a verificar cada cambio. Lo revisás y aprobás.
4
Convertir el plan en condición de /goal
Salís de Plan Mode. Tomás el plan aprobado y lo reescribís como condición verificable detrás de /goal. El plan dice 'yo quiero X, Y, Z'; la condición dice 'está logrado cuando A=true, B=true, C=true y npm run build exit 0'.

Cómo se traduce un plan en condición

El plan habla en lenguaje humano: "yo quiero X, Y, Z". La condición habla en lenguaje verificable: "está logrado cuando A=true, B=true, C=true". Si el plan dice "agregar OG image custom", la condición dice "/opengraph-image devuelve image/png". Si el plan dice "capturar emails", la condición dice "POST a /api/waitlist responde 200 con json ok:true". Si el plan dice "no romper nada", la condición dice "npm test exit 0 y git status muestra solo cambios dentro de src/app/waitlist/". Cada deseo del plan se vuelve una cláusula chequeable del goal.

El combo completo · /plan diseña, /goal ejecuta

Ejemplo end-to-end: un landing de waitlist con email capture, OG image custom y deploy a Vercel. Primero el plan, después el /goal con las cláusulas verificables que destilás del plan.

# Paso 1 — En Plan Mode (Shift+Tab → Plan Mode)

Necesito un landing nuevo en la ruta /waitlist que:
- Capture emails y los persista en /api/waitlist (POST → 200 con json { ok: true })
- Tenga OG image custom en /opengraph-image cuando se comparta en redes
- Esté deployed en Vercel con preview URL accesible
- npm run build pasa sin errores

Archivos involucrados (asumo):
- src/app/waitlist/page.tsx (la página)
- src/app/api/waitlist/route.ts (el endpoint)
- src/app/waitlist/opengraph-image.tsx (la OG)

Restricciones:
- No tocar src/app/layout.tsx ni src/middleware.ts
- Mantener Tailwind v4 + el design system existente
- Email validation server-side, no solo client

Devolveme el plan paso a paso antes de tocar código.

---

# Paso 2 — Salir de Plan Mode, pegar este /goal con las cláusulas verificables

/goal la ruta /waitlist responde 200 y muestra el form, /api/waitlist con POST { email: "test@x.com" } responde { ok: true }, /opengraph-image existe y devuelve image/png, npm run build exit 0 sin warnings nuevos, git status muestra solo cambios dentro de src/app/waitlist y src/app/api/waitlist, o stop after 25 turns

¿Querés profundizar Plan Mode primero? La guía completa de Plan Mode vive en /community/plan-claude — el modo arquitecto de Claude Code, qué hace, cómo se activa y por qué deberías usarlo antes de cada tarea grande. Si nunca usaste Plan Mode, leelo antes de combinar con /goal — el combo asume que ya sabés cómo funciona el modo plan solo.

06 · ejemplos listos

Cinco condiciones para copiar y empezar a usar hoy

Estos cinco /goal te sirven como esqueleto. Copialos, reemplazá los nombres concretos (rutas, archivos, label de issues) por los tuyos, y ya tenés un goal verificable. Todos llevan una cláusula or stop after N turns como red de seguridad — sin ella, un goal mal pensado puede correr indefinidamente.

Landing de waitlist (full-stack)

Captura emails, persiste a un endpoint propio, genera OG image y deploya. Un goal de 4 cláusulas verificables que se cumple cuando el build pasa verde.

/goal el landing en /waitlist está accesible y muestra el form, /api/waitlist con POST { email } persiste y responde 200, /opengraph-image devuelve image/png, npm run build exit 0, y git diff toca solo archivos dentro de src/app/waitlist o src/app/api/waitlist, o stop after 25 turns

Refactor · splitear archivo gordo

Forzá que un archivo se rompa en módulos bajo un budget de líneas, pero sin romper imports ni tests. La cláusula de tests es la que evita los atajos.

/goal el archivo src/legacy.ts está spliteado en módulos dentro de src/legacy/, cada módulo tiene menos de 200 líneas, todos los imports antiguos siguen resolviendo a las funciones equivalentes, npm test exit 0, y git status no muestra cambios fuera de src/legacy, o stop after 30 turns

Limpieza de backlog · issues con label bug

Convertí una cola de issues en PRs o explicaciones documentadas. Útil para una tarde de catch-up cuando se acumularon reports y querés cerrar el ciclo.

/goal cada issue abierto con label "bug" tiene un PR vinculado en estado mergeable o un comentario nuevo del bot explicando por qué se cierra sin fix, gh pr list --label bug devuelve todos los PRs abiertos en el transcript, y ningún issue nuevo se abrió, o stop after 40 turns

Documentación · JSDoc completo en src/api

Llená la cobertura de docs sin tocar la lógica. Buen ejemplo de goal con restricción explícita de 'no cambies la implementación, solo los comentarios'.

/goal cada función exportada en src/api/ tiene JSDoc completo con @param, @returns y @example, npm run lint exit 0, y git diff --stat muestra cero cambios en líneas de código ejecutable (solo comentarios), o stop after 35 turns

Migración · reemplazar legacyClient por modernClient

Goal clásico de migración API. La cláusula 'git diff no toca tests/legacy' previene que el modelo 'pase los tests' borrándolos.

/goal cada call site de legacyClient en src/ está reemplazado por modernClient con los mismos argumentos equivalentes, npm test exit 0, grep -r "legacyClient" src/ devuelve 0 hits en el transcript, y git diff no toca archivos dentro de tests/legacy/, o stop after 30 turns

Cómo usarlos: dentro de Claude Code, después de abrir sesión en el proyecto correspondiente, pegá la línea completa empezando por /goal. Eso arranca el primer turno con la condición como directiva. Si querés correrlos en modo headless (script o cron job), envolvelos en claude -p "..." — la próxima sección cubre eso en detalle. Si la tarea se vuelve recurrente, empacala como una skill para no tener que reescribir el prompt cada vez.

07 · ejecución desatendida

Combinar /goal con auto mode y modo headless

/goal te quita el trabajo de empujar a Claude turno a turno. Pero entre turnos, Claude todavía tiene que pedirte permiso para cada tool call (leer un archivo, correr un comando, escribir). Si querés ejecución totalmente desatendida — sin tocar la terminal hasta que termine — hay dos compañeros que pegan bien: auto mode y modo headless.

Auto mode + /goal

Ejecución continua dentro de la sesión interactiva

Auto mode aprueba las tool calls dentro de cada turno sin preguntarte. /goal arranca el próximo turno cuando termina el actual. Los dos juntos te dan ejecución totalmente desatendida turno tras turno y tool tras tool — vos solo mirás. La doc oficial los marca como complementarios.

Riesgo: auto mode aprueba todo. Si tu goal puede tocar archivos sensibles o correr comandos destructivos, leé auto mode config primero — define qué bloquear.

Headless + /goal

Una sola invocación, corre hasta cumplirse

claude -p "/goal <condición>" corre el loop completo en una sola invocación, sin sesión interactiva. Útil para cron jobs (auditorías nocturnas, limpiezas semanales) y CI (cualquier check que se pueda escribir como condición). Ctrl+C interrumpe.

Vive también en Agent View — podés lanzar un goal headless en background y verlo desde el panel de sesiones.

Auto mode encendido antes del goal

/auto on

Correr /goal en modo headless (script / cron)

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

/goal vs /loop vs Stop hook custom — del docs oficial

Approach	Próximo turno arranca cuando…	Se detiene cuando…
/goal	Cuando el turno anterior termina	Cuando un modelo confirma que la condición se cumple
/loop	Cuando pasa un intervalo de tiempo	Cuando vos lo parás o Claude decide que el trabajo está hecho
Stop hook custom	Cuando el turno anterior termina	Cuando tu script o prompt propio decide que sí

¿Cuándo usar cuál? /goal cuando la meta tiene un final claro (tests pasan, build verde, queue vacía). /loop cuando querés re-correr algo en intervalos sin un end state (chequeos periódicos, polling de una API externa). Stop hook custom cuando necesitás que la decisión de seguir o parar la tome un script tuyo en lugar de un modelo. Las tres viven en scheduled tasks en la doc oficial. Si querés correr tareas que viven independientes de tu sesión, también está la opción de cloud routines y desktop scheduled tasks ahí mismo.

Modo headless detallado vive en la página de headless.

08 · cómo decide

Cómo funciona el evaluador (lo que importa saber)

Atrás de /goal hay un mecanismo simple: cada vez que Claude termina un turno, el sistema le pasa al evaluador la condición + toda la conversación y le pregunta una cosa: ¿se cumplió o no? El evaluador devuelve sí o no más una razón corta. Si la respuesta es no, esa razón se le pasa a Claude como guía para el próximo turno. Si es sí, el goal se limpia y queda registrada la condición lograda en el transcript.

Input

Condición + transcript completo

Todo lo que Claude haya surfaceado en la conversación hasta este turno. No mira archivos en disco, no consulta APIs, no corre tools.

Output

yes / no + razón corta

Yes limpia el goal y registra la entry "achieved". No le pasa la razón al próximo turno como guía y arranca otra iteración.

Model

Small fast model (Haiku default)

El modelo configurado como "small fast model" en tu provider. Por default es Haiku. Cambialo en model config si querés otro.

Billing

Los tokens del evaluador se cuentan contra el small fast model configurado en tu provider. Según la doc oficial, son despreciables comparados con el gasto del modelo principal de cada turno. No pienses en el costo del evaluador como un freno — pensá en el costo de cada turno principal y bound el goal con or stop after N turns para no sorprenderte.

Implementación interna

/goal es un wrapper alrededor de un prompt-based Stop hook scopeado a la sesión. Si necesitás lógica más sofisticada (decisiones por script, conditions encadenadas, decisiones que dependen de estado externo), podés escribir tu propio Stop hook en lugar de usar /goal — la doc cubre cómo hacerlo.

Lo más importante de toda esta sección: el evaluador NO ejecuta tools. NO lee archivos en disco. NO consulta nada externo. Solo lee lo que ya está en la conversación. Por eso tus condiciones tienen que pedir explícitamente que la evidencia aparezca en el transcript — si Claude no corrió el test, no listó los archivos, no mostró el git status, el evaluador queda ciego. Esta es la causa #1 de goals que "nunca se cumplen" — la evidencia no estaba en la conversación.

09 · buenas prácticas

Cinco cosas que sí + cinco que no, antes de dejar /goal corriendo solo

Haz

01Combiná /plan + /goal para tareas complejas. El plan elimina la varianza del primer turno; el goal evita que se pierda el hilo en el quinto.
02Incluí siempre una cláusula 'o stop after N turns' al final de la condición. Te protege de un loop infinito cuando algo externo cambia y la meta se vuelve inalcanzable.
03Pedile a Claude que surface la evidencia explícitamente (npm test, git status, gh pr list). El evaluator solo lee el transcript — si no aparece, no puede juzgarlo.
04Usá auto mode + /goal cuando confíes en el sandbox del proyecto. Auto mode aprueba las tools, /goal aprueba los turnos — juntos te dan ejecución desatendida real.
05Empezá con condiciones chicas y verificables antes de ir grande. Probá /goal con 'README.md tiene una sección Install' antes de pedirle una migración completa.

Evita

01Tirar /goal sin contexto previo. Sin /plan ni un brief detallado, Claude inventa el plan en el primer turno y puede divergir antes de que el evaluator entienda qué pasa.
02Condiciones vagas tipo 'el feature funciona bien' o 'la app es rápida'. El evaluator no puede juzgar adjetivos — solo hechos verificables.
03Lanzar /goal con efectos irreversibles (deploy a producción, drop de tabla, git push -f) sin un --dry-run o un staging intermedio. Si el goal va por mal camino, los efectos quedan.
04Asumir que el evaluator lee tus archivos en vivo. No lo hace — solo lee la conversación. Si Claude no corrió 'cat archivo.ts' o 'npm test', el evaluator no sabe qué hay.
05Dejar runs largos sin bound. Sin 'or stop after N turns', un goal mal escrito puede gastarte tokens hasta que vos te des cuenta horas después.

Si lo vas a reusar: un /goal recurrente (la auditoría diaria, el chequeo semanal de un repo, el catch-up nocturno) merece ser empacado como skill. Una vez que la condición está afinada y funciona dos o tres veces seguidas, guardala en ~/.claude/skills/<nombre>/SKILL.md para invocarla con /<nombre> sin reescribir el prompt. La habilidad aprende (guía completa en /community/aprende-skill) puede ayudarte a detectar cuando un goal se está volviendo recurrente y proponerte empacarlo.

Guía de la comunidad

Esta entrada destila la documentación oficial de /goal en Claude Code y le agrega el patrón flagship del combo /plan + /goal que la comunidad de tododeia viene puliendo. Es parte de la bóveda de tododeia, una colección libre de recursos para quienes usan Claude todos los días. La fuente oficial vive en code.claude.com/docs/en/goal.

Documentación oficial · /goal

La página de Anthropic con la spec completa: cómo se setea, cómo decide el evaluator, cómo resume con --continue.

Prompt-based Stop hooks

/goal es un wrapper de un Stop hook session-scoped. Esta página explica el sistema de hooks debajo si querés escribir uno propio.

Auto mode config

Auto mode + /goal es la combinación que te da ejecución totalmente desatendida. Lee acá cuándo activarlo y cuál es su risk model.

Headless mode (claude -p)

Cómo correr Claude Code sin sesión interactiva — útil para cron jobs, scripts y CI donde el /goal corre solo hasta cumplirse.

Plan Mode

El compañero natural del combo flagship

Instalar Claude Code

El prerequisito desde cero

Agent View

Múltiples sesiones en paralelo

¿Por dónde empezar si todavía no usás Claude Code?

Arrancá por la guía de instalación — 5 minutos en terminal o descargá la app de escritorio. Una vez instalado, corré claude --version y después tipeá /goal solo (sin argumento) para chequear si la feature está disponible en tu versión. Si te dice que no la conoce, actualizá. Empezá con una condición chiquita y verificable (por ejemplo: "README.md tiene una sección Install con al menos un comando") antes de pedirle una migración completa — vas a entender cómo se siente el indicador, cómo se lee la razón del evaluador y cómo es el ritmo de los turnos.

¿Para quién no aplica esta página?

Si tu uso típico de Claude es exploratorio — "ayudame a pensar X", "qué opinás de esta idea", conversaciones de una pregunta — /goal no encaja. La feature brilla cuando hay un end state verificable: tests, build, queue vacía, archivo dentro de un budget. Para chequeos periódicos sin end state usá /loop en lugar. Para decisiones de seguir/parar que dependan de tu propia lógica (un script externo, una decisión de negocio), un Stop hook custom encaja mejor que /goal.