Cómo empezar a usar Ralph con Claude Code
Si ya usas Claude Code para programar, RALPH es el siguiente paso natural cuando tu problema no se resuelve “a la primera”.
El plugin ralph-wiggum automatiza ciclos iterativos para que Claude siga trabajando, corrigiendo y refinando el resultado hasta que se cumpla una condición de salida (o hasta que tú lo pares).
Qué es RALPH y por qué existe
Ralph Wiggum (técnica popularizada en la comunidad como “Ralph is a bash loop”) describe una idea simple: en vez de pedirle a un agente que haga una tarea y se detenga, lo metes en un bucle que le fuerza a iterar sobre el mismo objetivo, aprendiendo de sus fallos y de los cambios que él mismo va introduciendo en el repo.
En Claude Code, el plugin oficial ralph-wiggum implementa esa idea con un patrón específico: hooks que interceptan el final de la sesión y reinyectan comandos/prompts para continuar automáticamente.
Cómo funciona en Claude Code (mecánica interna a alto nivel)
Sin entrar en detalles innecesarios, lo importante es entender el “motor”:
- Al iniciar un Ralph loop, el plugin configura un User prompt submit hook que inyecta el comando
/ralph-loopcomo entrada del usuario. - Una vez dentro del modo loop, el plugin vuelve a inyectar
/continuecada vez que termina el turno de Claude, para empujar otra iteración sin intervención manual. - En la práctica, esto hace que Claude vaya encadenando iteraciones sobre el mismo objetivo, acumulando cambios en el directorio de trabajo (y típicamente en git si tú se lo pides).
El patrón clave es el “stop-hook loop”: cuando Claude “cree que ya terminó” e intenta parar, el hook lo bloquea y lo vuelve a lanzar contra el objetivo.
Instalación (rápida)
Hay varias guías, pero el flujo más repetido es:
- Abrir Claude Code.
- Ejecutar
/plugin. - Ir a Discover y buscar
ralph-wiggum. - Instalarlo a nivel proyecto o global.
- Reiniciar Claude Code.
Comandos principales y opciones
En el uso diario, lo que te importa es esto:
1) Iniciar el loop
/ralph-loop "<prompt>"para arrancar el bucle con tu objetivo.
2) Limitar el daño (imprescindible)
--max-iterations N: corta tras N iteraciones.
3) Definir una señal de “ya está”
--completion-promise "TEXTO": el loop termina cuando Claude emite ese texto exacto (se recomienda hacerlo muy específico).
4) Cancelar el loop
/cancel-ralph: detiene el loop activo.
Nota operativa:
--completion-promisesuele ser frágil (matching exacto) y que la seguridad real es--max-iterations.
Casos de uso donde RALPH sí aporta (y por qué)
RALPH brilla en trabajo mecánico, largo y verificable, donde cada iteración puede acercarte a un resultado objetivo:
- Procesar un conjunto de PRs o tareas repetitivas en un repo.
- Ejecutar un checklist de setup con múltiples pasos.
- Refactors masivos en una codebase.
- Cualquier workflow con N tareas discretas que puedas “trackear” con un TODO.
Piénsalo como “ejecución autónoma prolongada”, no como magia: funciona mejor cuando hay tests, linters, scripts reproducibles y criterios de aceptación claros.
Cómo escribir prompts que marcan la diferencia
En la práctica, el factor determinante no es el plugin, sino la ingeniería del prompt y la verificabilidad.
Recomendaciones que se repiten en la documentación y guías:
- Criterios de aceptación explícitos (qué debe quedar cierto al final).
- Definición de verificación (qué comando lo demuestra: tests, lint, build).
- Promesa de finalización (“completion promise”) inequívoca y difícil de disparar por accidente.
- Iteraciones acotadas (siempre).
Ejemplo típico (orientativo) de la idea:
- “Arregla todos los errores de ESLint en
src/. Cuandonpm run lintpase, imprimeLINT_CLEANy no antes. Máximo 10 iteraciones.”
Mejores prácticas para redactar prompts en Ralph
Definir criterios de finalización claros
- Especifica qué significa que la tarea esté “completa”.
- Usa condiciones que puedan ser verificadas automáticamente, por ejemplo: tests que pasen, linters sin errores o criterios de salida exactos.
- Incluye una frase o etiqueta específica (como un token de finalización) que Claude debe generar al terminar correctamente.
Ejemplo (incorrecto):
“Crea una API REST y hazla buena”
Ejemplo (correcto):
“Construye una API REST para ‘todos’ con: endpoints CRUD funcionando, validación de entradas, tests pasando con cobertura mínima del 80%, y al final imprime “COMPLETE”.”
Objetivos incrementales
- Divide tareas grandes o complejas en fases o pasos concretos.
- Cada fase debe tener criterios claros de éxito.
- Esto ayuda a que el loop progrese y no se atasque en una parte demasiado amplia sin dirección.
Promover autocorrección
- Diseña el prompt para que Claude verifique y corrija su propio trabajo antes de continuar.
- Por ejemplo, define un proceso de test-driven development (TDD): escribir test fallidos, implementarlos, ejecutar tests y repetir hasta que todo pase.
Añadir mecanismos que eviten ciclos interminables
- Incluye mecanismos que eviten ciclos interminables en caso de que el loop no pueda cumplir los criterios.
- El principal mecanismo de seguridad es siempre especificar
--max-iterationsen el comando/ralph-looppara limitar la cantidad de iteraciones. - El token de finalización (
--completion-promise) debe ser específico y difícil de generar por accidente.
Consejos adicionales implícitos
- Las mejores prácticas se enfocan en convertir ambigüedad en métricas verificables y en promover la verificación automática del progreso.
- Cuanto más explícito, medible y dividido esté el objetivo, mayor la probabilidad de que Ralph conduzca la sesión a un resultado útil antes de agotar iteraciones o tokens.
Seguridad, coste y control: lo que debes hacer siempre
RALPH puede quemar tokens durante horas si lo dejas suelto. La guía práctica es:
- Empieza pequeño y escala.
- Siempre define
--max-iterations. - Pide validación automatizada (tests/lint/build) en cada iteración o al menos antes de la promesa final.
- Ten a mano
/cancel-ralphcomo “kill switch”.
Limitaciones y problemas conocidos
A día de hoy, hay incidencias reales alrededor del plugin, especialmente ligadas a la ejecución de scripts vía Bash() y a los chequeos de permisos/seguridad de Claude Code:
Fallos de permisos por formato del comando
Se ha reportado que el slash command /ralph-wiggum:ralph-loop puede fallar porque el sistema de permisos recibe el comando con marcadores tipo ««!` en vez del comando limpio.
Solución: invocar el script directamente con Bash(".../setup-ralph-loop.sh" ...) cuando el slash command falla.
Restricciones por comandos multilinea
También hay problemas porque el plugin intenta ejecutar scripts multilínea y eso choca con validaciones de seguridad (por riesgo de inyección de c´odigo), causando fallos en el permiso/ejecución.
Interacciones raras con sesiones concurrentes
Hay comportamiento inesperado del stop hook interfiriendo con otra sesión/terminal distinta. Si trabajas con múltiples agentes a la vez, conviene extremar precauciones y aislar sesiones.
Recomendaciones si quieres usar RALPH en serio
- Define el objetivo como una especificación verificable, no como una intención.
- Obliga a Claude a demostrar el resultado (tests/lint/build) antes de mostrar la promesa final.
- Cap iterations siempre.
- Si se atasca, cancela y reescribe el prompt: normalmente el problema es ambigüedad, falta de límites o falta de verificación.
- Si te falla el comando por permisos, prueba el workaround de ejecutar el script vía
Bash()directamente (y revisa los issues/PRs recientes del plugin).
Información basada en la publicación
