Agentes on Patrones — Exeal

CLAUDE.md como mapa de contexto para el agente

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Es tentador convertir CLAUDE.md en el sitio donde se vuelca todo lo que un agente “debería saber”: la arquitectura completa, las reglas de negocio, el contrato de la API, el histórico de decisiones. El resultado es un archivo que crece sin límite y que se desincroniza solo, porque cada cambio real (una entidad nueva, un endpoint, una regla de dominio) obliga a acordarse de tocar también el CLAUDE.md a mano — y nadie se acuerda siempre. Un CLAUDE.md largo tampoco resuelve nada mejor que uno corto: un agente no lee mejor 300 líneas que 40, y la información específica (qué endpoint hace qué, qué campo significa qué) cambia con frecuencia suficiente para que documentarla ahí sea garantía de que quede obsoleta.

Skill Run: entorno local determinista para un agente

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Cuando pido a Claude que levante un proyecto en local, suele liarse: no sabe qué variables de entorno necesita, en qué orden arrancar los servicios, o qué comando exacto usar. Cada vez que lo hace, redescubre el mismo proceso a base de prueba y error, y encima con proyectos con frontend + backend + infra, “levantar el proyecto” no es una sola cosa: a veces solo hace falta el frontend contra un backend de mentira para tocar UI, a veces hace falta el backend real con Postgres para depurar persistencia, a veces hace falta todo tal cual se despliega. Sin un contrato claro, el agente tiende a levantar de más (todo el stack cuando solo hacía falta el frontend) o de menos (arranca el backend a pelo, sin las variables de entorno correctas, y luego no sabe por qué falla la autenticación).

Skill Verify: verificación basada en riesgo

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Cuando un agente termina de implementar algo, tiende a declarar la tarea hecha en cuanto el diff “tiene buena pinta”. Eso no es evidencia: un diff que compila y parece razonable puede romper una migración, dejar sin cubrir un caso de error, o cambiar un contrato HTTP sin que ningún test lo note. Y el problema inverso es igual de real: sin un criterio explícito, el agente también puede sobre-verificar, lanzando la suite completa (incluida infraestructura real) para un cambio interno que un test unitario ya cubre de sobra. Ninguno de los dos extremos es barato: uno deja bugs pasar, el otro quema tiempo y contenedores por nada.