La guía definitiva sobre /goal

/goal no es una funcionalidad. Es un primitivo.

HTTP es un primitivo. JSON es un primitivo. /goal se está convirtiendo en uno para los agentes de codificación.

Hace unas semanas, OpenAI añadió /goal a Codex CLI como una forma de asignarle un trabajo con un estado de "terminado" definido. Claude Code lo agregó esta semana.

Hermes Agent, el orquestador que ejecuto en un Mac Mini para coordinar el trabajo entre agentes de codificación, ya tenía /goal integrado desde hace tiempo.

Así que ahora tengo un constructor, un revisor y un orquestador que aceptan el mismo formato de instrucción, aunque no compartan nada más.

Si solo has visto /goal usado como un prompt más elaborado, te has perdido lo que realmente cambia.

Qué es /goal en realidad

Un prompt normal le pide a un agente la siguiente respuesta. Lees lo que devuelve, decides si es correcto y empujas al agente al siguiente paso. Tú diriges cada turno.

/goal invierte eso. Escribes cómo se ve "completado", lo envías una vez y el agente trabaja hasta lograrlo. Aquí tienes un ejemplo real:

1/goal Construye la aplicación descrita en SPEC.md. "Completado" significa que las pruebas pasan,
2la compilación pasa, el README es preciso y el estado de git solo muestra
3archivos relevantes del proyecto.

El objetivo permanece activo hasta que se logra, se pausa, se bloquea, se borra o se agota el presupuesto.

Esto es diferente a poner la palabra "goal" dentro de un comando normal de una sola ejecución. Si escribes codex exec 'goal: build the app', eso sigue siendo un prompt con una etiqueta. El verdadero primitivo vive dentro de una sesión interactiva de trabajo. Lanzas la CLI, envías /goal y te alejas.

El cambio es de promptear (tú conduces) a asignar (el agente conduce hacia un objetivo que definiste).

GIF

Las tres herramientas que actualmente hablan /goal

Las tres herramientas que aceptan /goal no son todas del mismo tipo, por lo que vale la pena ser específicos.

Codex es la CLI de codificación de OpenAI. Fuerte en implementación, especialmente cuando se le da una especificación clara. /goal es cómo le das esa especificación.

Claude Code es la CLI de codificación de Anthropic. Fuerte en lo inverso: encontrar qué está mal en código que parece correcto. Cumplimiento de especificaciones, problemas de seguridad, estados de error, agujeros de seguridad. /goal es cómo lo apuntas al código y le pides una revisión.

Hermes Agent es un tipo de herramienta completamente diferente. No es un agente de codificación, sino un orquestador que coordina el trabajo entre agentes de codificación como los dos anteriores. /goal es cómo Hermes entrega tareas a la herramienta adecuada para el trabajo, y también cómo yo le digo a Hermes lo que quiero en primer lugar.

Lo que importa no es que una de ellas haya lanzado /goal. Es que tres equipos diferentes convergieron en el mismo primitivo, y esa convergencia es lo que hace posible componerlos.

GIF

Configuración

La primera vez que necesité Codex y Claude Code en el Mac Mini que ejecuta Hermes, no los instalé manualmente. Le envié un mensaje a Hermes pidiéndole que instalara ambos y que me iniciara sesión. Él se encargó del resto.

Ese es el flujo de trabajo ahora. No escribes comandos de instalación. La configuración es solo otro objetivo.

Si aún no tienes un orquestador ejecutándose, las páginas de instalación de Codex y Claude Code son fáciles de seguir. Pero una vez que lo tengas, no deberías configurar otra herramienta manualmente. El objetivo de tener un orquestador es que el trabajo mecánico deja de ser tuyo.

Lo que Hermes añade sobre /goal

Un /goal sin procesar es útil por sí solo. Pero te deja con un problema de coordinación.

Si Codex se ejecuta en una terminal y Claude Code en otra, tienes que recordar qué proceso está haciendo qué. Tienes que revisar los registros. Tienes que pasar manualmente los hallazgos de la revisión de una herramienta a la otra.

Hermes convierte esas ejecuciones sueltas en un flujo de trabajo:

1. Le envías un mensaje a Hermes (en mi caso, a través de Telegram desde mi teléfono)
2. Hermes crea tarjetas de objetivo en un tablero Kanban
3. Hermes elige el trabajador adecuado para cada tarjeta
4. El trabajador ejecuta el objetivo en segundo plano
5. La tarjeta almacena el ID del proceso, el PID, el repositorio y los criterios de "completado"
6. Cuando la compilación está lista, Hermes entrega el repositorio al revisor
7. Si la revisión bloquea, Hermes envía los hallazgos de vuelta como un objetivo de corrección
8. Hermes verifica el resultado final inspeccionando el sistema de archivos, las pruebas, la compilación y el estado de git

El tablero es lo que /goal se convierte cuando hay un orquestador encima. Cada objetivo tiene una tarjeta, cada tarjeta tiene un estado, cada entrega deja un rastro. En lugar de buscar entre terminales, ves el trabajo moverse a través de las columnas en tu teléfono.

Los tres roles

Las herramientas cambian. Los roles no.

Orquestador. Es dueño del bucle de control. Descomposición de tareas, selección de trabajadores, tarjetas Kanban, procesos en segundo plano, dependencias, verificación final, el resumen orientado al usuario. En mi configuración, Hermes.

Constructor. Toma una especificación y produce código funcional. La implementación es el cuello de botella que este rol resuelve. Codex tiende a ser fuerte aquí.

Revisor. Lee lo que el constructor produjo y encuentra qué está mal. La corrección es el cuello de botella. Claude Code tiende a ser fuerte aquí.

Una ejecución real, de principio a fin

Le di al agente Hermes un objetivo para hacer esto:

1/goal Construye una herramienta CLI que encuentre X menciones sobre mí y me notifique cuando
2algo explote.

Hermes dividió la solicitud en seis tarjetas.

Shubham Saboo

@Saboo_Shubham_

·

12 de mayo

Codex /goal lo construye.

Claude Code /goal lo revisa y refina.

Hermes /goal gestiona la orquestación y la entrega.

Todo rastreado en un solo tablero Kanban y los agentes siguen ejecutándose en el bucle.

58

61

852

88K

Tarjeta 1: Especificación. Hermes escribió SPEC.md por sí mismo, capturando el stack, la ruta del repositorio, las restricciones de solo lectura, los requisitos del modo simulado, las pruebas y los comandos de verificación. Gestionado por el rol de PM.

Tarjeta 2: Codex construye. Codex ejecutó /goal contra SPEC.md. Creó los archivos del proyecto, implementó la interfaz de usuario y el backend, añadió pruebas y llevó la aplicación a un estado de aprobación. Aproximadamente 15 minutos. Cuando terminó, npm test pasó, npm run build pasó y git status mostró solo los archivos nuevos relevantes.

Tarjeta 3: Claude Code revisa. Claude Code ejecutó /goal para revisar lo que Codex construyó. Verificó el cumplimiento de la especificación, la seguridad de solo lectura, el manejo de claves API, los estados de error, las pruebas, la utilidad de la interfaz de usuario, los errores y los problemas de seguridad. Resultado: APROBADO, sin problemas bloqueantes.

Tarjeta 4: Bucle de corrección de Codex. Omitida, porque la revisión fue aprobada. La tarjeta sigue siendo importante cuando se omite. Muestra que Hermes puede modelar trabajo condicional. Si Claude Code hubiera bloqueado, Hermes habría entregado los hallazgos de vuelta a Codex como un nuevo /goal.

Tarjeta 5: Verificación final de Claude Code. Omitida por la misma razón.

Tarjeta 6: Resumen final de Hermes. Aplicación funcional en la ruta local, interfaz de usuario y API verificadas en modo simulado. Codex lo construyó con /goal. Claude Code lo revisó con /goal y devolvió APROBADO.

Todo eso vino de un solo mensaje. Tres herramientas diferentes hicieron el trabajo real, pero solo hablé con Hermes.

La regla de verificación

Hermes nunca confió en el autoinforme de Codex. Después de que Codex marcó la compilación como terminada, Hermes ejecutó los comandos por sí mismo:

1npm test         # 17 pruebas pasaron
2npm run build    # compilación de vite pasó

El verificador es lo que convierte un /goal en un contrato en lugar de una promesa. No confíes en el autoinforme del trabajador como definitivo. Confía en el verificador.

Los agentes de codificación son seguros de sí mismos. Te dirán que la compilación pasa cuando la compilación nunca se ejecutó. Te dirán que las pruebas pasan cuando escribieron pruebas que nunca se ejecutaron. El verificador cierra esa brecha.

Sin verificación, /goal es solo un prompt más elaborado. Con verificación, se convierte en un contrato.

GIF

Ejecutar múltiples objetivos

Puedes ejecutar múltiples /goals en paralelo, pero no puedes apuntar a varios trabajadores de codificación a los mismos archivos sin pensarlo primero.

Mi opción predeterminada es un constructor principal por repositorio. Si quiero paralelismo, lo añado a través de límites claros. Diferentes repositorios, diferentes ramas, árboles de trabajo de git, paquetes separados, documentación versus código, pruebas versus implementación. Cualquier lugar donde dos trabajadores no puedan pisarse mutuamente.

El mal patrón es tres trabajadores editando el mismo archivo en el mismo repositorio. Obtienes conflictos, sobrescrituras parciales y un trabajador deshaciendo silenciosamente el trabajo de otro.

El mejor patrón es un escritor a la vez en cualquier archivo dado. El constructor escribe, el revisor solo lee, y los objetivos de corrección se mantienen enfocados en la corrección. O ejecuta tres constructores en tres árboles de trabajo con tres enfoques competidores y deja que el orquestador elija el mejor.

El tablero es lo que hace esto práctico. Sin él, los trabajadores paralelos en segundo plano se convierten en caos de terminal.

Lo que cambia para mí

El marco útil aquí no es "puedo ejecutar agentes en segundo plano".

Es que un mensaje se convierte en un pipeline a través de tres herramientas de codificación diferentes, y veo todo moverse a través de un solo tablero.

Dejas de sentarte en una terminal esperando que un agente termine, y comienzas a gestionar una cola de trabajo con estado visible.

Si Codex y Claude Code hubieran inventado cada uno su propio formato de entrega de tareas, ningún orquestador podría enrutar entre ellos. El tablero es impresionante, pero el primitivo hace que el tablero sea aún más útil.

Los trabajadores pueden cambiar, pero el primitivo permanece igual. La próxima herramienta de codificación que adopte /goal se unirá a este pipeline sin que yo cambie nada. Solo enrutaré trabajo hacia ella.

Eso es lo que hacen los buenos primitivos.

Para más tips geniales e ideas interesantes sobre Hermes, OpenClaw, Claude Code, Codex y otros equipos de agentes 24/7.

Sigue → @Saboo_Shubham_