Claude Code Todos los ecosistemas Manual para desarrollo — Julio 2026
Trabajo autónomo con /goal en Claude Code
/goal fija una condición de finalización y Claude sigue trabajando solo, turno tras turno, hasta cumplirla — sin que tengas que ir dándole a «continúa». Es ideal para llevar una tarea feature/<KEY> desde el plan hasta dejarla verificada de una sentada. Y como en muchos de nuestros proyectos las pruebas se hacen a mano, este manual explica cómo usarlo sin necesidad de una suite de tests (compilación, grep, diff y checklist), con plantillas listas para copiar por cada ecosistema.
Contenido
- 1. Qué es
/goaly para qué sirve - 2. Cómo funciona: la regla de oro del evaluador
- 3. Anatomía de una condición efectiva
- 4. Cómo verificar sin tests automatizados
- 5. El flujo recomendado: del ticket al PR
- 6. Plantillas por ecosistema (copiar y pegar)
- 7. Buenas prácticas y precauciones
- 8. Referencia rápida de comandos
- 9. Preguntas frecuentes
1. Qué es /goal y para qué sirve
Normalmente, cuando Claude termina un turno te devuelve el control y esperas a que le des la siguiente instrucción. Con /goal cambias eso: defines una condición de finalización y, al acabar cada turno, un modelo pequeño y rápido comprueba si ya se cumple. Si no, Claude arranca otro turno por su cuenta. Cuando la condición se cumple, el objetivo se borra automáticamente.
/goal sirve para trabajo sustancial con un final verificable. Tú describes dónde está la meta, no cada paso para llegar. Claude itera hasta llegar.
Casos típicos en nuestro día a día:
- Implementar una tarea hasta que compile y cada criterio de aceptación quede demostrado.
- Migrar o refactorizar un módulo hasta que compile y el diff no toque nada fuera de su sitio.
- Dividir un fichero gigante (por ejemplo un
.pasde miles de líneas) en units enfocadas dentro de un presupuesto de tamaño. - Vaciar un backlog de tickets de una versión, trabajándolos uno a uno hasta que la cola quede vacía.
/goal necesita Claude Code v2.1.139 o posterior y un espacio de trabajo de confianza (el evaluador forma parte del sistema de hooks). Si tu versión es anterior, actualiza antes de usarlo.
2. Cómo funciona: la regla de oro del evaluador
Después de cada turno, la condición y la conversación hasta ese momento se envían al modelo pequeño y rápido de tu sesión (por defecto Haiku). Ese evaluador responde sí o no, y añade una breve razón que verás en pantalla y que orienta el siguiente turno de Claude.
git status, un curl. Una condición como «el código queda elegante» no es verificable y el objetivo no se cerrará nunca.
Dicho de otro modo: si quieres que el objetivo se cierre cuando «el endpoint exige autenticación», la condición correcta es «php artisan route:list muestra el middleware auth en /auth/users«, porque Claude ejecutará ese comando y su salida quedará en la transcripción para que el evaluador la lea. Fíjate en que ahí no hace falta ningún test automatizado — y eso es justo lo que desarrolla la sección 4.
3. Anatomía de una condición efectiva
Una condición que aguanta muchos turnos sin desviarse suele tener estos cuatro ingredientes:
| Ingrediente | Qué es | Ejemplo |
|---|---|---|
| Estado final medible | El resultado observable que marca «hecho». | un build sin errores, un grep con 0 coincidencias, una cola vacía, un recuento de líneas |
| Verificación establecida | Cómo debe probarlo Claude, con un comando concreto. | «el proyecto compila (log pegado)»; «git status solo muestra el módulo X» |
| Restricciones | Lo que NO debe cambiar por el camino. | «no se tocan otras rutas», «ninguna firma pública cambia» |
| Límite | Un tope de turnos o tiempo para que no se enganche. | «o detente tras 20 turnos» |
La condición puede tener hasta 4.000 caracteres, así que hay sitio de sobra para ser específico.
No hay estado final medible ni verificación: el evaluador no puede saber cuándo parar.
git status solo muestra units de cobro. Detente tras 20 turnos.»Estado final + verificación + restricción + límite. El evaluador sabe exactamente qué mirar — y no ha hecho falta un solo test.
4. Cómo verificar sin tests automatizados
En muchos de nuestros proyectos las pruebas se hacen a mano y no hay una suite automatizada. No es un problema para /goal: el comando no necesita «tests», necesita evidencia objetiva escrita en el chat. Un test es solo una forma de generarla; estas son las anclas que puedes usar sin una sola línea de test.
| Ancla | Qué demuestra | Cómo pedirla en la condición | Fuerza |
|---|---|---|---|
| Compilación / build | Que el cambio integra y no rompe la construcción. | «compila sin errores ni warnings nuevos, con el log pegado en el chat» | Objetiva |
| Búsqueda (grep) | Que algo existe, ya no existe o es consistente. | «0 coincidencias de get(url) sin slug, con el grep pegado» | Objetiva |
Diff / git status | Que solo se tocó lo previsto. | «git status muestra solo ficheros de app/Cobros« | Objetiva |
| Comprobación funcional puntual | Que un endpoint o servicio responde como debe. | «curl a /auth/users devuelve 401 sin token, salida pegada» | Objetiva (si se ejecuta) |
| Checklist contra JIRA | Que cada criterio de aceptación está cubierto. | «lista cada criterio y el fichero:procedimiento que lo resuelve» | Depende del mapeo de Claude |
git status) + checklist de criterios de JIRA. Con las tres, el evaluador tiene señal de sobra para decidir.
/goal deja el trabajo hasta «compila + criterios cubiertos + auto-revisado» y la validación final la haces tú antes del PR. Te ahorra el camino, no la prueba final.
5. El flujo recomendado: del ticket al PR
Las tareas os llegan ya definidas (las generamos con la revisión previa y quedan en JIRA). A partir de ahí, el flujo natural con /goal mantiene un punto de control humano entre planificar y ejecutar:
/explore-plan (o un /goal de planificación) para que produzca un plan que cubra ficheros a tocar, riesgos y criterios de aceptación. Lo revisas tú./goal de implementación anclado a la verificación de tu proyecto (compilación, grep, checklist). Claude itera hasta dejarlo demostrado.Plantilla — Fase Explorar & Planificar
Aquí la meta no es un test ni un build, sino un plan completo:
Plantilla — Implementar hasta verificación en verde
Plantilla — Refactor / dividir un fichero grande
Plantilla — Vaciar un backlog de versión
<KEY> (p. ej. GLOP-1170, APIREST-62, APPGLOP-45), <VERIFICACIÓN> por el ancla de tu ecosistema (tabla de la sección 6), <RUTA> por el directorio del módulo, <FICHERO> por el archivo real.
6. Plantillas por ecosistema (copiar y pegar)
Cada ecosistema tiene sus anclas de verificación. Estas son las que puedes usar sin una suite de tests — ajústalas si tu proyecto tiene otras:
| Ecosistema | Stack | Anclas de verificación (sin suite de tests) |
|---|---|---|
| Central Glop | Delphi / Firebird | compilación del .dproj + grep + git status |
| Web Glop (API/back) | Laravel / PHP | php artisan route:list · php -l · curl al endpoint · grep |
| Web Glop (front) | Vue / Node | npm run build · npm run lint · grep |
| Android Glop | Kotlin | ./gradlew assembleDebug · ./gradlew ktlintCheck · grep |
| Central Servicios | Delphi / Windows | compilación + arranque del servicio + git status |
| WordPress | PHP / WooCommerce | php -l · phpcs · comprobación en navegador |
CLAUDE.md del ecosistema). Los de aquí son los típicos, pero cada proyecto puede tener su propio script.
Central Glop — Delphi / Firebird (Glop TPV)
La verificación fuerte es la compilación limpia, reforzada con el checklist de criterios y git status. Ancla la condición al log de compilación que Claude pegue en el chat.
Dividir una unit enorme (caso muy nuestro, p. ej. ficheros de datos táctil de miles de líneas), verificado por conteo + compilación:
Web Glop — glop-api-rest / backend (Laravel)
Ejemplo con una tarea real de API sin autenticación, verificado por route:list + curl (sin test automatizado):
Comprobar que una validación queda en su sitio, sin levantar tests:
Web Glop — frontend / dashboard (Vue)
Migración de convención verificada por grep (recuerda: ApiService nunca hace get(url) sin slug):
Android Glop — Kotlin
Central Servicios — servicios Windows
Como en Central Glop, la verificación fuerte es la compilación, reforzada con el arranque del servicio en local (que Claude pegue la salida de arranque).
WordPress — wooglop y addons (PHP)
7. Buenas prácticas y precauciones
/goal te seguirá pidiendo permiso en cada edición y no correrá solo. El modo automático aprueba las herramientas dentro del turno; /goal decide si hay otro turno. Juntos es cuando se vuelve realmente autónomo.
main. Un objetivo autónomo puede tocar muchos ficheros. Trabaja siempre en la rama feature/<KEY> de la tarea, para poder descartar todo con un git reset si el resultado no convence.
git status (sección 4).
<RUTA>» y «ninguna firma pública cambia» evitan que el objetivo se expanda y modifique cosas que no tocaba.
/goal clear y reformula la condición.
8. Referencia rápida de comandos
| Comando | Qué hace |
|---|---|
/goal <condición> | Fija el objetivo y arranca un turno de inmediato (la condición es la propia directiva). Si ya había uno, lo reemplaza. |
/goal | Sin argumentos: muestra el estado — condición, tiempo, turnos evaluados, tokens gastados y la última razón del evaluador. |
/goal clear | Cancela el objetivo activo antes de cumplirse. Alias válidos: stop, off, reset, none, cancel. |
claude -p "/goal ..." | Modo no interactivo: ejecuta el bucle hasta completarse en una sola invocación. Se corta con Ctrl+C. |
--resume / --continue | Restaura un objetivo que seguía activo al cerrar la sesión (se reinician contador de turnos, temporizador y línea base de tokens). |
◎ /goal active con el tiempo que lleva corriendo. Iniciar una conversación nueva con /clear también elimina el objetivo.
9. Preguntas frecuentes
No tenemos tests automatizados. ¿Tiene sentido usar /goal?
Sí. /goal no necesita tests, necesita evidencia objetiva en el chat. Ancla la condición a la compilación, a un grep, a git status o a un curl, y refuérzala con el checklist de criterios de JIRA. Lo tienes desarrollado en la sección 4.
¿Consume muchos tokens el evaluador?
No. El evaluador corre en el modelo pequeño y rápido (Haiku por defecto) y su gasto es normalmente insignificante frente al del turno principal. Lo caro es el trabajo, no la comprobación.
¿Va a escribir código sin mi permiso?
Solo si activas el modo automático. Con /goal a secas, cada herramienta que edite ficheros te seguirá pidiendo confirmación; lo que /goal elimina son los «continúa» por turno, no las aprobaciones por herramienta.
¿Cómo lo paro a mitad?
En sesión interactiva, /goal clear. En modo no interactivo (-p), Ctrl+C. Y /clear (nueva conversación) también lo borra.
¿Qué pasa si cierro la sesión con un objetivo a medias?
Si reanudas con --resume o --continue, la condición se restaura (se reinician contadores). Un objetivo ya cumplido o ya borrado no se restaura.
¿Por qué mi objetivo no se cierra nunca?
Casi siempre es una condición no verificable desde el chat: revisa que se apoye en algo cuyo resultado Claude pegue en la conversación (compilación, grep, git status, curl). Mira la razón del evaluador de cada turno para ver qué le falta.
¿En qué se diferencia de /loop o de un Stop hook?
/goal arranca el siguiente turno cuando acaba el anterior y para cuando un modelo confirma la condición. /loop arranca cada intervalo de tiempo. Un Stop hook vive en tu configuración y aplica a todas las sesiones de su ámbito; /goal es un atajo de una sola sesión (por dentro es justo un Stop hook basado en prompt).
Glop — Trabajo autónomo con /goal en Claude Code — Manual para desarrollo — Julio 2026