Cómo usar /goal de forma eficiente: un agente autónomo es un contrato operativo, no un botón mágico (2026)

- /goal es una función de Codex, actualmente tras un feature flag y cambiando rápido; la sintaxis y el comportamiento aquí se contrastaron con la documentación oficial al momento de escribir; verifica la documentación en vivo antes de depender de ella.

Qué es /goal (y qué no es)

/goal es el goal mode de Codex (OpenAI Codex CLI) para un objetivo largo y mecánico con una condición de parada verificable. Lo activas con /experimental o añadiendo goals = true bajo [features] en config.toml, y luego ejecutas /goal <objective>. Mientras corre, escribe /goal para ver el estado; contrólalo con /goal pause, /goal resume, /goal clear.

Y aquí está lo más importante: /goal no es un límite de seguridad, no reemplaza las decisiones de producto y no es un lugar para correr un backlog sin límites. Es un bucle persistente, nada más. (Nota: /goal es una función de Codex, no un comando nativo de Claude Code; no confundas los dos.) Para la sintaxis, mira la guía oficial del goal mode.

La verdad dura: /goal solo hace al agente más persistente, no más inteligente

La gente ensalza /goal como si fuera el botón de "apretar una vez y la app se construye sola". Yo abusé de él durante una semana y me llevé un buen golpe cada vez. La conclusión es simple: /goal no hace al agente más inteligente, lo hace más persistente. Persistente en la dirección correcta es genial; persistente en la dirección equivocada duele: simplemente se lanza por el camino equivocado sin detenerse a cuestionarse.

Los tres "golpes" de abajo son los modos de fallo más comunes, y la lección de cada uno.

Golpe n.º 1 - desvío de límite tras el auto-compact (un deploy a producción)

Escribí la meta con toda claridad: hacer deploy solo a staging. Pero tras unos cuantos auto-compacts, el agente se salió del contexto, olvidó el límite e hizo deploy directo a producción, aun cuando había un hook que le recordaba la tarea después de cada compact.

Lección dolorosa: nunca le des a un agente acceso privilegiado a producción. No confíes en el "ya se acordará". No: no se acuerda con la fiabilidad que crees. Justo por eso el goal mode no es un límite de seguridad: la línea de seguridad tiene que vivir en tus permisos, no en una nota dentro de un prompt. Mira cómo apretar el acceso en permisos de Claude Code y buenas prácticas de seguridad para programar con IA.

Golpe n.º 2 - las metas vagas son licencia para divagar

"Hazlo más bonito." "Mejora la UX." Suena humano. Pero, para un agente, eso es licencia para divagar. Cambió una cosa, rompió otra, alucinó un poco y a veces se detuvo pronto sin que nada hubiera mejorado con claridad.

Lección: una meta debe definir qué significa "mejor". ¿Más bonito cómo?

• ¿Espaciado más ajustado?
• ¿Contraste más legible?
• ¿Mejor responsividad en móvil?
• ¿Menos pasos en el checkout?
• ¿Mayor tasa de finalización?

Si no sabes lo que quieres, no se lo lances a un agente y ejecutes /goal. Primero haz brainstorm, planifica, escribe criterios de aceptación. Cuando los requisitos todavía no están claros, una ronda rápida de pedirle a un advisor que aclare (advisor/kongming) vale más que encender la autonomía. Para escribir un plan con comprobaciones concretas, mira planificación de proyectos para Claude Code.

Golpe n.º 3 - verificación ausente (un "listo" confiado y falso)

Fijé una meta para una nueva página de frontend, pero olvidé decirle al agente que usara agent-browser para la verificación visual. ¿El resultado? Se saltó la verificación de verdad y reportó, muy seguro, "completado con éxito". Luego la abrí y recordé que la vida no es un cuento de hadas.

Lección: no confíes en nadie. Provee las herramientas correctas y exige explícitamente que el agente las use antes de terminar. Los tests en verde no bastan:

• El frontend hay que mirarlo (screenshot/agent-browser).
• El flujo hay que recorrerlo a clics.
• El deploy debe comprobar el entorno.
• El PR debe revisar el diff.

El contrato operativo - la fórmula de un buen /goal

En resumen: un buen /goal no es un prompt ingenioso. Es un contrato operativo con cinco partes:

Esto encaja con la "prueba de uso" del goal mode: úsalo solo cuando la tarea (1) sea más larga que un turno y sobre todo mecánica, (2) tenga una condición de parada verificable y (3) tenga un alcance lo bastante claro para avanzar sin una decisión de producto en cada checkpoint. No uses /goal para trabajo exploratorio, peticiones de mejora vagas, cambios de credenciales de producción, infraestructura compartida destructiva o un backlog mezclado.

Cómo uso /goal: separar la planificación del día de la ejecución de la noche

Mi forma favorita ahora es separar el pensar del día de la ejecución de la noche.

De día (pensar)

1. Crear issues en GitHub para cada bug / función / mejora.
2. Usar las skills de brainstorm y plan para aclarar cada issue.
3. Responder en la issue con un resumen de la implementación + un enlace al plan.md.
4. Añadir la etiqueta ready to implement.
5. Repetir hasta que cada issue esté preparada.

De noche (ejecución)

Antes de descansar y pasar tiempo con la familia, dejo correr /goal: "Implementa todas las issues marcadas como ready-to-implement según los planes predefinidos." El bucle por issue:

1. Ordenar las issues por prioridad.
2. Implementar una issue a la vez.
3. Crear un worktree y branch separados por issue.
4. ak:cook --auto (ejecución continua contra el plan).
5. ak:code-review.
6. ak:ship beta.
7. ak:review-pr --fix.
8. Añadir la etiqueta ready to ship y pasar a la siguiente issue.

Esto funciona mucho mejor. El agente ya no adivina "¿qué quieres?": ejecuta contra un plan aclarado, con su propio branch, revisión, deploy beta, PR y etiqueta. Me despierto, hago café, abro la máquina y hay una pila de PRs esperando. Mi trabajo ya no es teclear "continue" como una payasa microgestora: es revisar con ojos humanos, volver a probar y luego hacer el merge. Para correr worktrees/PRs en paralelo, mira orquestar subagents; coloca este bucle dentro del flujo brainstorm → plan → cook → ship.

¿Quieres el bucle de gates ya montado? (AgentKit)

El bucle de la noche es fuerte gracias a sus gates de calidad: ak:cook, ak:code-review, ak:ship, ak:review-pr. AgentKit entrega esos gates y corre tanto en Claude Code como en Codex, así que encaja con el /goal de Codex. Para ser franca: /goal es de Codex y es gratis; el kit solo añade el proceso ya montado + la revisión para que no lo ensambles tú misma. Para más detalles, lee la reseña de AgentKit o la reseña del Engineer Kit.

El valor real de /goal

Ese es el valor real de /goal: no dejar que el agente piense por ti, sino dejar que se encargue de la ejecución repetitiva después de que tú ya hiciste el pensar. Tú haces el pensar - spec, plan, criterios de aceptación - y luego lo dejas darle duro. Tu trabajo es revisar con ojos humanos, volver a probar y luego hacer el merge.

Preguntas frecuentes (FAQ)

¿Qué es /goal y de qué herramienta es?

/goal es el goal mode de Codex (OpenAI Codex CLI), actualmente tras un feature flag: actívalo con /experimental o goals = true bajo [features] en config.toml. NO es un comando nativo de Claude Code; no confundas los dos.

¿Cuándo NO deberías usar /goal?

Para trabajo exploratorio, requisitos vagos, cambios de credenciales de producción, operaciones destructivas en infraestructura compartida o un backlog mezclado con alcance poco claro. /goal encaja en tareas mecánicas y de larga duración con una condición de parada verificable.

¿Cómo se escribe una buena meta?

Trátala como un contrato operativo de cinco partes: Resultado (qué significa "listo"), Alcance (qué puede/no puede tocar), Restricciones (límites que no se rompen), Verificación (cómo se prueba el "listo") y Reglas de parada (cuándo parar o preguntar a una persona).

¿Puede /goal hacer deploy a producción de forma segura?

No debería. No le des al agente acceso a producción; el goal mode no es un límite de seguridad. La línea de seguridad pertenece a tus permisos (mínimo privilegio), no a una nota en el prompt: tras unos cuantos auto-compacts el agente puede olvidar el límite.

¿Bastan los tests en verde para que el agente reporte "listo"?

No. El frontend hay que mirarlo (screenshot/agent-browser), el flujo recorrerlo a clics, el entorno de deploy comprobarlo y el diff del PR revisarlo. Provee las herramientas correctas y exige que el agente las use antes de terminar.

¿Necesitas AgentKit para usar /goal?

No. /goal es de Codex y es gratis. AgentKit solo añade los gates ak:cook / ak:code-review / ak:ship / ak:review-pr para correr dentro del bucle: útil si quieres un proceso ya montado en vez de ensamblar uno.

Conclusión

No mitifiques /goal. Es un bucle terco, útil cuando ya hiciste el pensar y solo necesitas ejecución repetitiva. Escribe la meta como un contrato operativo, blinda el acceso a producción, exige verificación y separa la planificación del día de la ejecución de la noche. ¿Necesitas aclarar los requisitos antes de ejecutarlo? Mira advisor vs kongming. ¿Necesitas un plan con criterios de aceptación? Mira planificación de proyectos para Claude Code.