Una metodología para automatizar el desarrollo de código de forma supervisada

Qué es

Una metodología para automatizar el desarrollo de código de manera supervisada. El trabajo se parte en fases y, entre fase y fase, hay puertas de verificación automáticas que comprueban lo que se ha hecho antes de dejar avanzar. Si una puerta no pasa, no se sigue, y el veredicto lo emite un script, no el propio agente.

Tiene dos carriles, porque no todo el trabajo merece el mismo papeleo. El ligero es un único fichero por tarea, para lo de todos los días. El pesado es para lo que cuesta caro equivocarse: diseño aprobado por una persona → plan por fases → ejecución que deja evidencia de cada fase → revisión contra un contrato escrito antes de empezar, para que nadie pueda mover la portería a mitad de partido. Hay además un carril específico para cazar bugs, con dos pasadas ciegas y auditoría del propio arreglo.

Lo importante es dónde vive la verdad del trabajo: en ficheros versionados —diseño, plan, registros de cada fase, revisión— dentro del propio proyecto y al lado del commit que les corresponde, no en una conversación que se evapora al cerrar la sesión. Si mañana vuelvo yo, o entra otra persona, o entra otro agente, el expediente está ahí y dice en qué estado quedó cada cosa.

Stack técnico

Cinco skills escritas como contratos en Markdown para Claude Code —entradas, salidas, veredictos permitidos y límites— más dos scripts de Node que ejecutan las puertas: un validador que recorre las comprobaciones de cada etapa (aprobación humana presente, formato del índice, veredictos literales, cobertura fase↔registro, árbol de trabajo limpio) y un sellador que calcula un sha256 agregado del plan aprobado. Ese hash es la pieza clave: se compara a tres puntas —el sello vigente, el que cada registro declara haber usado y el recálculo de hoy— y con eso el script distingue un plan editado después de aprobarse de uno ejecutado contra un plan sin validar.

El reparto de trabajo es deliberado: el modelo hace lo que exige juicio, y los scripts hacen lo que una máquina hace mejor, que es comparar. Un modelo no compara un hash jamás. Un instalador versionado deja las skills en cualquier proyecto, y todo el rastro queda como ficheros de texto: no hace falta más que Node y Git.