Un desarrollador publicó dev-process-toolkit, un plugin para Claude Code que implementa puertas duras entre fases de desarrollo: el agente no puede avanzar si los tests o el linter fallan. El resultado es un workflow de 5 fases con exit codes reales que elimina el problema central de los agentes IA — su tendencia a saltarse validaciones cuando creen que el código “se ve bien”.
En 30 segundos
- dev-process-toolkit es un plugin para Claude Code que fuerza un workflow de 5 fases con gates determinísticos — el agente no puede ignorarlos.
- Las puertas ejecutan comandos reales (compilador, linter, suite de tests) y verifican exit codes reales. No confía en la auto-evaluación del agente.
- Si en el segundo intento los mismos issues persisten, escala a revisión humana en vez de quemar tokens en un tercer round.
- Soporta TypeScript, Flutter/Dart, Python, Rust, Go y Java. Se instala en un comando:
/plugin marketplace add nesquikm/dev-process-toolkit. - Fue probado en producción en tres proyectos: un dashboard TypeScript/React, un servidor Node/MCP y una app Flutter de retail.
Claude Code es una herramienta de desarrollo creada por Anthropic que utiliza el modelo Claude para asistir en tareas de programación, debugging y refactoring, disponible como aplicación de escritorio, web, CLI y extensiones IDE.
El problema real: agentes que ignoran bugs mientras trabajan
Ponele que le pedís a Claude Code que agregue autenticación a tu API. El agente trabaja, modifica tres archivos, declara “listo” y te muestra un diff prolijo. Pero los tests de integración que tenías escritos ahora fallan porque cambió el comportamiento del middleware. ¿El agente los corrió? Buena pregunta.
El problema de la validación de bugs con Claude Code no es nuevo: los agentes de IA priorizan completar la tarea pedida sobre la calidad del resultado. Podés decirle “ejecutá los tests antes de commitear” y va a cumplirlo a veces, cuando se acuerda, cuando juzga que son relevantes, o cuando el contexto de la conversación no lo desvió hacia otra cosa. No hay garantía estructural de nada.
Dicho esto, el problema es más sutil que “el agente es flojo”. Los LLMs evalúan si algo “se ve bien” basándose en patrones de código. Si el código que generaron se parece a código correcto, asumen que es correcto. Eso no es lo mismo que correr el compilador y fijarse el exit code.
Qué es dev-process-toolkit: workflow de 5 fases con puertas duras
dev-process-toolkit es un plugin oficial para Claude Code que define un proceso de desarrollo en cinco fases obligatorias. No son sugerencias. El agente no puede pasar a la siguiente fase si la puerta de la actual está cerrada.
Las cinco fases son:
- Specs como source of truth: antes de tocar código, se define qué debe hacer la feature.
- TDD: los tests se escriben primero. No al final, no “cuando haya tiempo”.
- Gate checks determinísticos: compilador, linter y suite de tests corren como comandos reales.
- Self-review acotado: el agente revisa su propio trabajo, pero dentro de un scope definido.
- Aprobación humana: el desarrollador da el OK final.
La diferencia clave con decirle al agente “portate bien” es estructural. El plugin codifica el proceso en la configuración del entorno, no en el prompt. Claude Code no decide si ejecutar las validaciones — las ejecuta porque está configurado para ejecutarlas. En cuando hablamos de Claude profundizamos sobre esto.
Cómo funcionan los gates: exit codes reales, no confianza ciega
Acá viene lo bueno: las puertas no le preguntan al agente si los tests pasaron. Ejecutan los comandos y leen los exit codes.
Si corrés npm test y el proceso termina con exit code 1, la puerta se cierra. El agente tiene que arreglar los tests antes de continuar. No hay forma de declarar “en realidad los tests son opcionales en este contexto” o “los tests fallan pero el código está bien”.
Hay un detalle de diseño que vale mencionar: la prevención de loops circulares. Si el agente encuentra bugs en el round 1, los intenta arreglar y re-corre los gates. Si en el round 2 los mismos issues siguen presentes, el plugin escala a revisión humana. No hay round 3. Eso es una decisión inteligente — los loops donde el agente da vueltas arreglando el mismo bug son el peor escenario tanto en calidad como en tokens consumidos.
Stacks soportados y dónde fue probado
El plugin soporta TypeScript, Flutter/Dart, Python, Rust, Go y Java. La razón por la que funciona en múltiples stacks es que no tiene lógica específica por lenguaje: depende de los comandos de build, test y lint que cada stack ya tiene definidos.
¿Alguien lo verificó en proyectos reales antes de publicarlo? Sí, en tres:
- Un dashboard TypeScript/React
- Un servidor Node con implementación MCP
- Una app Flutter para retail
Tres proyectos no son una muestra enorme (y hay que tomarlo con ese contexto), pero son suficientes para decir que el approach sobrevive a stacks distintos con herramientas de build distintas. Lo explicamos a fondo en al comparar diferentes modelos.
Instalación y setup: tres pasos
El proceso de instalación es directo:
- Paso 1:
/plugin marketplace add nesquikm/dev-process-toolkit - Paso 2:
/dev-process-toolkit:setup - Paso 3: El plugin lee tu
package.json,pubspec.yamlopyproject.toml, genera unCLAUDE.mdcon los comandos de gates configurados, y opcionalmente scaffoldea los archivos de spec.
El setup es agnóstico al stack — lee la configuración que ya tiene tu proyecto y la traduce a gates. No tenés que reescribir nada.
Con plugin vs sin plugin: la diferencia que importa
Sin el plugin, el flujo típico es algo así: le pedís al agente que implemente algo, el agente trabaja, declara que está listo, vos revisás el diff, y si tenés suerte los tests pasan. La validación depende de que el agente recuerde hacerla, de que la considere necesaria, y de que el prompt no haya derivado hacia otro lado durante la sesión.
Con el plugin, el workflow es 100% reproducible. Siempre las mismas fases, siempre los mismos gates, siempre los mismos comandos. No importa si el task es simple o complejo, si la sesión lleva 10 mensajes o 100.
El beneficio secundario que no es tan obvio: menos tokens desperdiciados. Los loops circulares donde el agente intenta arreglar algo, falla, intenta de nuevo con la misma estrategia y falla otra vez son costosos. El gate de round 2 corta ese loop antes de que empiece el tercero.
Subagentes especialistas: code-reviewer y test-writer
Una funcionalidad adicional: el plugin puede lanzar subagentes especializados cuando el workflow lo necesita. Un subagente de code-review para auditar logic bugs, edge cases y violations. Un subagente de test-writer para ayudar a escalar la cobertura de tests. Sobre eso hablamos en si trabajás en proyectos grandes.
No es automático en todos los casos — es una opción que el workflow tiene disponible. La decisión de cuándo spawnear un subagente está codificada en la lógica del plugin, no delegada al criterio del agente principal en ese momento.
Errores comunes al configurar validación en agentes IA
Poner las instrucciones de validación en el prompt del sistema
El problema con “siempre corré los tests antes de commitear” en el system prompt es que el agente lo trata como una preferencia, no como una restricción. Si el contexto cambia o el task se vuelve complejo, esa instrucción compite con otras consideraciones. Las instrucciones estructurales en la configuración del entorno pesan más que las instrucciones en el prompt.
Asumir que “el agente reportó que los tests pasaron” equivale a “los tests pasaron”
Si el agente corrió los tests y te lo cuenta, eso no es lo mismo que verificar el exit code. El agente puede malinterpretar la salida, puede haber encontrado un error en la ejecución del comando que confundió con un test failure, o puede haber omitido tests que estaban marcados como skip. Los gates del plugin no preguntan, verifican.
Instalar el plugin sin configurar los comandos correctos
El setup lee la configuración del proyecto, pero si tu package.json tiene scripts de test mal definidos o el linter no está configurado, los gates van a fallar o a no ejecutar lo que esperás. Antes de hacer el setup, verificá que npm test y npm run lint (o el equivalente de tu stack) funcionen correctamente desde la terminal.
Preguntas Frecuentes
¿Cómo evitar que Claude Code ignore bugs mientras trabaja en otra tarea?
El plugin dev-process-toolkit resuelve este problema con gates determinísticos que el agente no puede saltear. Cada fase del workflow requiere que los checks anteriores pasen antes de continuar. Si el agente detecta un bug durante la ejecución de gates, tiene que arreglarlo antes de seguir adelante, independientemente de cuál era la tarea original. Más contexto en en nuestro análisis de arquitecturas.
¿Qué es dev-process-toolkit y cómo se instala?
dev-process-toolkit es un plugin para Claude Code que implementa un proceso de desarrollo en 5 fases con puertas de validación obligatorias. Se instala con /plugin marketplace add nesquikm/dev-process-toolkit seguido de /dev-process-toolkit:setup. El setup genera automáticamente el CLAUDE.md con los comandos de gates basándose en la configuración de tu proyecto.
¿Cómo implementar TDD automático con Claude Code?
dev-process-toolkit incluye una fase de TDD obligatoria en su workflow: los tests se escriben antes del código de implementación. El plugin fuerza este orden porque lo codifica en la secuencia de fases. El agente no puede pasar a escribir código de producción hasta que la fase de specs y tests esté completa.
¿Con qué stacks de desarrollo es compatible el plugin?
El plugin soporta TypeScript, Flutter/Dart, Python, Rust, Go y Java. Funciona leyendo la configuración de build y test que ya tiene el proyecto (package.json, pubspec.yaml, pyproject.toml, etc.) y traduciéndola a comandos de gates. Fue probado en producción en proyectos TypeScript/React, Node/MCP y Flutter.
¿Qué pasa si el agente falla los gates dos veces seguidas?
Si los gates del round 2 encuentran los mismos issues que el round 1, el plugin escala a revisión humana. No intenta un tercer round. Esta decisión evita los loops circulares donde el agente consume tokens dando vueltas con la misma estrategia fallida sin llegar a una solución.
Conclusión
dev-process-toolkit resuelve algo que los prompts de sistema no pueden resolver: la imprevisibilidad de un agente que decide por su cuenta cuándo validar y cuándo no. El approach no es nuevo conceptualmente (TDD, gates de CI/CD), pero llevarlo al nivel del plugin de Claude Code significa que el workflow es parte del entorno, no del prompt.
Si usás Claude Code para desarrollo y alguna vez recibiste código que “se veía bien” pero rompía tests existentes, esto vale la pena probarlo. El costo es una instalación de un comando. Si las puertas duras te parecen demasiado restrictivas para tu flujo, siempre podés no instalarlo — pero al menos sabés que la opción existe.
Para proyectos que corren en producción y que necesiten garantías reales sobre el código generado, este tipo de tooling es el camino. Si además ese proyecto vive en un servidor propio, donweb.com tiene opciones de hosting con soporte local para equipos que trabajan con stacks de este tipo.