/goal se está convirtiendo en un comando importante dentro de las herramientas de programación con IA.

No se trata de hacer que el modelo escriba unas cuantas líneas más de código. Resuelve un problema más práctico: cuando una tarea tiene condiciones claras de finalización, ¿puede el Agent seguir avanzando hasta cumplirlas, en lugar de detenerse después de cada turno y esperar a que el usuario escriba “continúa”?

Codex CLI ya añadió un /goal experimental en su documentación oficial. Claude Code también publicó su propia documentación de /goal, y lo describe como una capacidad de automatización que puede seguir trabajando durante varios turnos. El nombre es el mismo, pero la orientación del producto no es exactamente igual.

Qué problema resuelve /goal

Una conversación normal de programación con IA suele funcionar turno por turno:

1. El usuario plantea una tarea.
2. El Agent analiza, modifica código y ejecuta pruebas.
3. El Agent informa el resultado.
4. El usuario decide el siguiente paso.

Ese flujo funciona bien para tareas cortas. Pero cuando se trata de migraciones, refactors, correcciones de pruebas o limpieza de un issue backlog, se vuelve fragmentado. El Agent puede avanzar solo un poco y luego detenerse hasta que escribas “continúa”.

La idea de /goal es cambiar la pregunta de “qué hago ahora” a “qué estado final cuenta como terminado”. Por ejemplo:

1

/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错

Este tipo de objetivo encaja de forma natural con tareas largas, porque tiene un punto final claro: las pruebas pasan, la compilación funciona, los archivos se han dividido, una cola queda vacía o se cumplen los criterios de aceptación.

/goal en Codex: experimental y ligado al hilo actual

La documentación de Codex CLI de OpenAI marca /goal como experimental. No es una capacidad estable activada por defecto; primero hay que habilitar features.goals.

Hay dos formas de hacerlo:

1

/experimental

O añadir esto a config.toml:

1
2

[features]
goals = true

Una vez habilitado, se puede usar así:

1

/goal Finish the migration and keep tests green

Los comandos habituales incluyen:

1
2
3
4

/goal
/goal pause
/goal resume
/goal clear

Según la documentación de OpenAI, Codex adjunta el goal al active thread actual y sigue ese objetivo mientras avanza una tarea más grande.

Aquí hay un detalle importante: el lenguaje oficial sobre Codex /goal es prudente. Enfatiza configurar un objetivo experimental para trabajo de larga duración y adjuntar ese objetivo al hilo actual, pero no describe con el mismo detalle que la documentación de Claude Code un evaluator independiente que revise cada turno y arranque automáticamente el siguiente. Por eso, de momento conviene tratar Codex /goal como un mecanismo experimental para objetivos de tareas largas, no como un modo de ejecución desatendida plenamente estable.

/goal en Claude Code: ejecución por varias rondas guiada por condiciones de finalización

La documentación de /goal en Claude Code es más explícita: después de que el usuario define una completion condition, Claude sigue trabajando entre turnos hasta cumplirla.

Ejemplo:

1

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

El mecanismo de Claude Code, a grandes rasgos, es este:

• Cuando termina el turno actual, el control no vuelve inmediatamente al usuario.
• Un modelo pequeño y rápido revisa si la condición del objetivo ya se cumplió.
• Si no se cumplió, Claude empieza automáticamente el siguiente turno.
• Si se cumplió, el goal se borra automáticamente y el estado de finalización queda registrado en el transcript.

Esto hace que /goal en Claude Code se parezca más a “continuar automáticamente hasta satisfacer la condición de finalización”. No solo fija un objetivo en la conversación; delega en un paso de evaluación independiente la decisión de si debe continuar.

Claude Code también permite ver el estado directamente:

1

/goal

El estado muestra la condición del objetivo, el tiempo transcurrido, la cantidad de turnos evaluados, el consumo de tokens y la razón más reciente del evaluator.

Para detenerlo antes de tiempo, se puede usar:

1

/goal clear

stop, off, reset, none y cancel también funcionan como alias de limpieza. Después de activar un objetivo, si la sesión se interrumpe y más tarde se reanuda con --resume o --continue, un goal activo puede recuperarse. Sin embargo, el tiempo, el número de turnos y la línea base de tokens se recalculan.

La diferencia principal

Codex y Claude Code están empujando la programación con IA desde respuestas de un solo turno hacia la ejecución de tareas largas, pero la posición de /goal no es la misma.

En resumen, /goal en Codex se parece más a “adjuntar un objetivo experimental de largo plazo al hilo actual”. /goal en Claude Code se parece más a “definir una condición verificable de parada para la sesión actual y dejar que siga trabajando hasta satisfacerla”.

Cómo escribir un buen /goal

Uses la herramienta que uses, /goal no es un buen lugar para deseos vagos.

Un mal ejemplo:

1

/goal 把项目优化一下

Un mejor ejemplo:

1

/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件

Un buen objetivo suele incluir tres cosas:

1. Un estado final claro.
2. Un método de validación ejecutable.
3. Límites que deben respetarse.

Si el objetivo es grande, conviene añadir una condición de parada:

1

/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题

Esto importa. Cuanto más potente sea /goal, más necesita límites. Si no, el Agent puede modificar demasiados archivos, ejecutarse durante demasiado tiempo, consumir demasiados tokens o seguir adelante con una cuestión que debería haberse detenido para pedir criterio humano.

Cuándo conviene usar /goal

Encaja bien con:

• Corrección de pruebas: hasta que pasen pruebas específicas.
• Migraciones de código: hasta que todos los puntos de llamada estén actualizados y la compilación funcione.
• Limpieza por lotes: hasta eliminar una clase de errores de lint o tipos.
• Documentación: hasta que todos los módulos especificados tengan explicación.
• Gestión de issues: hasta que todos los issues bajo una etiqueta estén tratados o clasificados con claridad.

No encaja bien con:

• Requisitos que todavía no están claros.
• Tareas que requieren juicio de producto frecuente.
• Eliminaciones de alto riesgo, migraciones de datos o cambios de permisos.
• Criterios de aceptación puramente subjetivos.
• Tareas que cruzan muchos módulos no relacionados.

Una regla práctica: si puedes escribir “qué comando ejecutar, qué resultado esperar y qué archivos no se deben tocar”, es buen candidato para /goal. Si solo puedes escribir “hazlo mejor”, sigue siendo más seguro usar conversación normal, plan mode o revisión humana.

Qué significa esto para las herramientas de programación con IA

/goal apunta a una dirección clara: las herramientas de programación con IA están pasando de asistentes interactivos a unidades de trabajo que pueden ejecutarse de forma continua.

Antes, usar un Agent solía implicar quedarse cerca. Si se atascaba, lo guiabas. Si terminaba las pruebas, le decías que continuara. Si aparecía un error, dabas otra orden. /goal comprime esa interacción en una condición de finalización y deja que el Agent decida qué debe hacer el siguiente turno.

Pero esto también sube el listón para los usuarios. Escribir prompts ya no consiste solo en describir una tarea; también implica definir criterios de aceptación, comandos de validación, límites de modificación y reglas de parada. Dicho de otro modo, el trabajo del usuario pasa de “pedirle que continúe” a “definir qué significa terminado”.

Que Codex y Claude Code hayan llegado a /goal muestra que los Agents de tareas largas ya no pertenecen solo a tareas en segundo plano o colas en la nube. Las herramientas locales de programación en terminal también empiezan a necesitar una capacidad más fuerte de avance autónomo.

Resumen

Codex CLI y Claude Code tienen /goal, pero por ahora no conviene tratarlos como la misma función.

El /goal de Codex sigue siendo experimental, requiere features.goals y encaja mejor como una forma de mantener un objetivo de largo plazo en el hilo actual de Codex. El /goal de Claude Code conecta de forma más explícita las condiciones de finalización con la continuación automática, usando un evaluator independiente para decidir si debe seguir.

Para el desarrollo diario, este tipo de comando funciona mejor en tareas de ingeniería con criterios de aceptación claros. No reemplaza el juicio de producto ni la revisión de código, pero puede reducir mucho el ciclo repetitivo de “continúa”, “ejecútalo otra vez” y “corrige hasta que pasen las pruebas”.

La habilidad importante no es memorizar el comando, sino aprender a escribir tareas como objetivos claros, verificables y detenibles.

Referencias

• OpenAI Codex CLI Slash Commands: https://developers.openai.com/codex/cli/slash-commands
• Documentación de Claude Code Goal: https://code.claude.com/docs/en/goal