Claude Code Todos los ecosistemas Manual para desarrollo — Julio 2026
Trabajo autónomo con /goal en Claude Code
En pocas palabras: /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.
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.
Idea clave: /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
.pas de 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.
Requisito: /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.
Fijas /goal ─► Turno de Claude (trabaja) ─► Evaluador (Haiku) lee el chat
▲ │
│ ¿condición cumplida? │
└────────────── NO ◄─────────────────┤
│ SÍ
▼
Objetivo cumplido ► se borra solo
La regla de oro: el evaluador solo juzga lo que Claude ha escrito en la conversación. No ejecuta comandos ni abre ficheros por su cuenta. Por eso la condición tiene que apoyarse en algo que la propia salida de Claude pueda demostrar: un log de compilación limpio, la salida de un grep, un 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.
Condición débil (evítala): «Arregla el módulo de cobros y déjalo bien.»
No hay estado final medible ni verificación: el evaluador no puede saber cuándo parar.
Condición sólida: «GLOP-1170 implementada; el proyecto compila sin warnings nuevos (log pegado), cada criterio de aceptación de JIRA queda mapeado a su fichero:procedimiento, y 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 |
La receta que mejor funciona sin tests: compilación limpia + una segunda ancla objetiva (grep o git status) + checklist de criterios de JIRA. Con las tres, el evaluador tiene señal de sobra para decidir.
No te fíes de la autoevaluación a secas. Si la única «prueba» es que Claude afirme «lo he revisado y está bien», el evaluador se cree esa afirmación optimista. Combina siempre el checklist con una ancla objetiva (compilación o grep); nunca dejes el checklist solo.
El límite honesto: la prueba manual de verdad — abrir el TPV y hacer un cobro con el datáfono — no la puede hacer el evaluador, que solo lee texto. En esas tareas, /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:
Tarea JIRA (definida) ─► /explore-plan ─► [revisas el plan] ─► /goal implementar ─► revisas el diff + prueba manual ─► PR
1 Explora y planifica. Lanza /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ú.
2 Implementa con objetivo. Ya con el plan validado, lanzas el /goal de implementación anclado a la verificación de tu proyecto (compilación, grep, checklist). Claude itera hasta dejarlo demostrado.
3 Revisa, prueba y entrega. El objetivo se cierra solo; tú revisas el diff, haces la prueba manual que corresponda y de ahí al PR. La responsabilidad del código sigue siendo del dev.
Plantilla — Fase Explorar & Planificar
Aquí la meta no es un test ni un build, sino un plan completo:
/goal Existe un plan de implementación para <KEY> en .claude/sessions/ que cubre: ficheros a tocar, cambios por fichero, riesgos y cada criterio de aceptación de JIRA mapeado a un cambio concreto. Ningún criterio queda sin abordar. Detente tras 10 turnos.
Plantilla — Implementar hasta verificación en verde
/goal <KEY> implementada según su descripción en JIRA. Demuéstralo: (1) <VERIFICACIÓN> (compila / grep / curl, según el proyecto) con la salida pegada; (2) lista cada criterio de aceptación con su fichero:procedimiento; (3) git status solo muestra ficheros de <RUTA>. Detente cuando los tres estén demostrados o tras 20 turnos.
Plantilla — Refactor / dividir un fichero grande
/goal He dividido <FICHERO> en módulos de <800 líneas cada uno. Demuéstralo: pega el conteo de líneas por módulo (todos <800) y el log de compilación limpio. Ninguna firma pública cambia y el comportamiento se mantiene. Detente tras 25 turnos.
Plantilla — Vaciar un backlog de versión
/goal Cada tarea asignada a mí en la versión <X.Y.Z> con estado «To Do» tiene su rama feature/<KEY> con la implementación, compila y sus criterios de aceptación quedan demostrados en el chat. Trabaja una a una y ve reportando cuáles quedan. Detente cuando la cola esté vacía o tras 40 turnos.
Sustituye los placeholders: <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 |
Antes de copiar: confirma los comandos reales de tu proyecto (los de arranque, compilación o lint están en el 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.
/goal GLOP-1170 implementada. Demuéstralo en el chat: (1) lista cada criterio de aceptación de la tarea en JIRA con el fichero:procedimiento que lo resuelve; (2) el proyecto compila sin errores ni warnings nuevos (log de compilación pegado); (3) git status muestra solo units de cobro modificadas. Detente cuando los tres estén demostrados o tras 25 turnos.
Dividir una unit enorme (caso muy nuestro, p. ej. ficheros de datos táctil de miles de líneas), verificado por conteo + compilación:
/goal He dividido UdatosTactil.pas en units temáticas de <800 líneas. Demuéstralo: pega el conteo de líneas por unit nueva (todas <800) y el log de compilación limpio. Ninguna firma pública cambia y ninguna funcionalidad cambia de comportamiento. Detente tras 30 turnos.
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):
/goal APIREST-62 implementada: el endpoint /auth/users exige autenticación. Demuéstralo: pega `php artisan route:list –path=auth/users` mostrando el middleware auth aplicado, y una llamada curl que devuelva 401 sin token y 200 con token válido. No se tocan otras rutas. Detente tras 20 turnos.
Comprobar que una validación queda en su sitio, sin levantar tests:
/goal El FormRequest de la ruta de cobro valida los campos indicados en APIREST-XXX. Demuéstralo: pega el grep del FormRequest con las reglas y `php artisan route:list` mostrando que la ruta lo usa. `php -l` sin errores en los ficheros tocados. Detente tras 20 turnos.
Web Glop — frontend / dashboard (Vue)
/goal GLOP-XXXX implementada; `npm run build` compila y `npm run lint` sale limpio. Lista cada criterio de aceptación de JIRA con el componente que lo resuelve. Ningún fichero fuera de src/views/cobros se modifica. Detente tras 20 turnos.
Migración de convención verificada por grep (recuerda: ApiService nunca hace get(url) sin slug):
/goal No queda ninguna llamada ApiService.get(url) sin slug en src/: ejecuta el grep y pega el resultado (0 coincidencias). `npm run build` compila y `npm run lint` limpio. Ningún otro directorio cambia. Detente tras 25 turnos.
Android Glop — Kotlin
/goal APPGLOP-XXX implementada según su descripción en JIRA; `./gradlew assembleDebug` compila y `./gradlew ktlintCheck` pasa. Lista cada criterio de aceptación de JIRA con la clase/función que lo resuelve. No se modifican módulos fuera de :feature:comandas. Detente tras 20 turnos.
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).
/goal El cambio en servicio-post está implementado; el proyecto compila sin errores (log en el chat) y el servicio arranca correctamente en local (salida de arranque pegada). git status muestra solo ficheros del servicio y no se toca la lógica de conexión con la nube. Detente tras 25 turnos.
WordPress — wooglop y addons (PHP)
/goal La tarea en wooglop está implementada; `php -l` no da errores de sintaxis en los ficheros tocados y `phpcs –standard=WordPress` pasa sin errores. Lista cada criterio de aceptación con el fichero:función que lo resuelve. No se modifican otros plugins del ecosistema. Detente tras 20 turnos.
7. Buenas prácticas y precauciones
Combínalo con el modo automático. Sin él, /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.
Nunca sobre 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.
Pon siempre un límite. Añade «o detente tras N turnos» a la condición. Sin tope, un objetivo mal medido puede iterar más de la cuenta. Claude reporta el progreso contra ese límite en cada turno.
Ancla a algo objetivo, no a una opinión. «Compila y el grep da 0 coincidencias» es verificable; «el código es correcto» no. Si tu proyecto no tiene tests, apóyate en compilación + grep + git status (sección 4).
Acota el alcance. Las cláusulas «no se toca nada fuera de <RUTA>» y «ninguna firma pública cambia» evitan que el objetivo se expanda y modifique cosas que no tocaba.
Vigila la razón del evaluador. En cada turno se muestra por qué la condición aún no se cumple. Si ves que da vueltas sobre lo mismo, corta con /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). |
Indicador en pantalla: mientras un objetivo está activo verás ◎ /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
