La guía definitiva sobre /goal

/goal no es una función. 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, Codex CLI de OpenAI añadió /goal como una forma de asignar una tarea al trabajador de codificación con un estado de finalización definido. Claude Code lo añadió esta semana.

Hermes Agent, el orquestador que ejecuto en un Mac Mini para coordinar el trabajo entre los trabajadores de codificación, ha tenido /goal integrado desde hace un tiempo.

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

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

Qué es realmente /goal

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. Estás dirigiendo cada turno.

/goal invierte eso. Escribes cómo se ve "terminado", lo envías una vez y el agente trabaja hacia eso hasta que lo logra. Aquí hay uno real:

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

El objetivo permanece activo hasta que se logra, se pausa, se bloquea, se limpia o se queda sin presupuesto.

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

El cambio es de dar indicaciones (tú conduces) a asignar (el agente conduce hacia un objetivo que tú 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ífico.

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 a código y le pides una revisión.

Hermes Agent es un tipo de herramienta completamente diferente. No es un trabajador de codificación, sino un orquestador que coordina el trabajo entre trabajadores 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 le digo a Hermes lo que quiero en primer lugar.

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

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 me iniciara sesión. 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 en funcionamiento, las páginas de instalación de Codex y Claude Code son bastante fáciles de seguir. Pero una vez que lo tengas, no deberías configurar otra herramienta manualmente. El punto de tener un orquestador es que el trabajo mecánico deja de ser tuyo.

Lo que Hermes añade sobre /goal

Un /goal simple es útil por sí mismo. 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 al trabajador adecuado para cada tarjeta
4. El trabajador ejecuta el objetivo en segundo plano
5. La tarjeta almacena el ID del proceso, PID, repositorio y criterios de finalización
6. Cuando el build está listo, 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 la salida final inspeccionando el sistema de archivos, las pruebas, el build y el estado de git

El tablero es en lo que se convierte /goal 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. Posee el bucle de control. Descomposición de tareas, selección de trabajadores, tarjetas Kanban, procesos en segundo plano, dependencias, verificación final, resumen para el 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 produjo el constructor 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 a Hermes agent un objetivo para hacer esto:

1/goal Construye una herramienta CLI que encuentre menciones X de 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. Propiedad del 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 dejó la aplicación en un estado funcional. Unos 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, seguridad de solo lectura, manejo de claves API, estados de error, pruebas, utilidad de la interfaz de usuario, errores y problemas de seguridad. Resultado: APROBADO, sin problemas bloqueantes.

Tarjeta 4: Bucle de corrección de Codex. Saltada, porque la revisión pasó. La tarjeta sigue siendo importante cuando se salta. 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. Saltada por la misma razón.

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

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

La regla de verificación

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

1npm test         # 17 pruebas aprobadas
2npm run build    # build de vite aprobado

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 confiados. Te dirán que el build pasa cuando el build 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 sofisticado. Con verificación, se convierte en un contrato.

GIF

Ejecutar múltiples objetivos

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

Mi configuració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, worktrees de git, paquetes separados, documentación vs código, pruebas vs implementación. En cualquier lugar donde dos trabajadores no puedan pisarse.

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, los objetivos de corrección se mantienen dentro del alcance de la corrección. O ejecuta tres constructores en tres worktrees 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 tablero.

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

Si Codex y Claude Code hubieran inventado cada uno su propio formato de entrega de trabajo, 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. Simplemente enrutaré el trabajo hacia ella.

Eso es lo que hacen los buenos primitivos.

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

Sigue → @Saboo_Shubham_