HexaLayered convierte sus reglas de arquitectura en instrucciones para Claude Code
Un kit de desarrollo guiado por especificaciones traduce la arquitectura HexaLayered en reglas que Claude Code aplica al escribir código, con verificación automática antes del code review.
El autor de HexaLayered Architecture ha reunido las reglas de ese diseño en un kit que Claude Code puede leer y aplicar mientras escribe código. La premisa es sencilla: si las normas de la arquitectura solo sirven cuando alguien se las lee, mejor que las cumpla la herramienta que redacta el código, no la memoria del que revisa el pull request.
Un constitution.md que se puede comprobar
El repositorio incluye un directorio .claude con un archivo constitution.md. Ahí no hay consejos del tipo "convendría hacerlo así", sino reglas verificables: qué clases son públicas, cuáles se quedan en package-private y hasta qué capa puede llegar una entidad. El autor cuenta que el problema era recurrente: alguien nuevo entraba al proyecto, usaba TicketEntity en la capa de servicio, y el fallo se colaba en el pull request o pasaba sin que nadie lo viera.
Sobre esa base monta un flujo de desarrollo guiado por especificaciones. El comando /hexa:specify deja por escrito qué se va a construir, /hexa:plan decide qué clase va en qué paquete, y el código viene después. Cuando el archivo ya está abierto, la pregunta "dónde va esta clase" deja de tener sentido.
El script corta antes del code review
Hay además un script de shell que se ejecuta en cada escritura de archivo. Si un servicio importa una entidad, si un Controller sigue siendo público o si una clase alcanza el repositorio de otro módulo, el script termina con código de salida 2 y el error vuelve directo al modelo. No espera a la revisión humana: el propio autor admite que, mientras lo probaba, encontró un fallo en su script.
Mover el kit a otro proyecto son dos comandos: cp -r .claude . y /hexa:bootstrap. El bootstrap localiza el paquete base, detecta si el proyecto usa Maven o Gradle y encuentra el comando de test por su cuenta. En un proyecto Spring Boot arrancado desde cero, la arquitectura queda correcta desde el primer commit.
El autor sacó las reglas del README y las contrastó sobre ays-be, un proyecto real que ya usa el patrón, lo que le sirvió como banco de pruebas. El pull request donde está el cambio es público.
Que las reglas de una arquitectura vivan dentro del propio agente que escribe el código no es nuevo: los archivos de contexto se han vuelto habituales en este tipo de herramientas. Lo que se añade aquí es que parte de esas normas dejan de ser texto para leer y pasan a ser comprobaciones que cortan la escritura del archivo antes de que el error llegue al repositorio.
