¿Por qué seguir repitiendo "usa patrones" en cada prompt en vez de ponerlo en las reglas?
Si una instrucción se repite en casi todos los prompts que le das a un agente de codificación, probablemente no debería vivir en el prompt. Dónde debe vivir cada tipo de conocimiento recurrente en el contexto.
La pregunta real
Es muy común, al trabajar con un agente de codificación, acabar escribiendo el mismo tipo de recordatorio una y otra vez en cada prompt: "usa el patrón repositorio", "sigue arquitectura hexagonal", "no acopl es la capa de dominio a Prisma". Si esas instrucciones se repiten en prácticamente todos los prompts de un proyecto, ¿no debería vivir esa información en algún sitio fijo del contexto en lugar de reescribirse cada vez?
La respuesta es que sí, al cien por cien — y de hecho ese es uno de los principios centrales de la ingeniería de contexto: cualquier instrucción que se repita en más de una tarea es candidata a moverse de "prompt" a "contexto persistente".
Dónde vive cada tipo de conocimiento recurrente
CLAUDE.md / agents.md
Convenciones globales del repositorio: arquitectura elegida (hexagonal, capas, microservicios), estilo de testing, herramientas del stack. Se lee una vez por sesión, no hay que repetirlo nunca en el prompt.
Reglas
Patrones que se aplican a cierto tipo de archivos o situaciones concretas (p. ej. "todo endpoint nuevo debe actualizar primero el contrato OpenAPI"). Se activan automáticamente cuando el contexto coincide.
Skills
Una habilidad reutilizable entre varios agentes, definida una sola vez (p. ej. "cómo generar un contrato Design-First"). Un agente la referencia; no hay que volver a explicar el procedimiento cada vez.
El prompt de la tarea
Debería quedar reservado para lo específico de ese ticket: qué endpoint, qué caso de negocio, qué criterio de aceptación puntual — no para repetir principios generales de arquitectura.
La analogía con onboarding humano
Pensarlo como el onboarding de una persona nueva en el equipo ayuda a decidir dónde va cada cosa. Nadie le recuerda a un desarrollador con seis meses en la empresa, en cada tarea, "recuerda que aquí usamos arquitectura hexagonal" — eso se explicó una vez, quedó documentado, y se asume. Lo que sí se le comunica tarea a tarea es lo específico de ese ticket: qué endpoint, qué reclutador lo pidió, qué caso de borde importa esta vez. Un agente de codificación debería tratarse igual: el contexto persistente (reglas, skills, CLAUDE.md) hace las veces de "cultura del equipo ya asumida", y el prompt de la tarea es solo la parte nueva.
Cuándo importa esta distinción
Esta separación importa especialmente en repositorios con varias personas o varios agentes trabajando en paralelo: si el patrón vive solo en la cabeza (o en el historial de prompts) de quien lo escribió la primera vez, cualquier otra persona del equipo — o cualquier otro agente — puede acabar generando código que no respeta esa convención, simplemente porque nadie se lo recordó esa vez.
Una buena señal práctica: si te sorprendes escribiendo la misma frase de patrón o convención en tres prompts seguidos, es el momento de parar y moverla a una regla o a la plantilla de buenas prácticas del repositorio, en vez de seguir repitiéndola.
Resumen rápido
- Toda instrucción que se repite en varios prompts es candidata a vivir en reglas, agentes o CLAUDE.md, no en el prompt de cada tarea.
- El prompt debería quedar reservado para lo específico de esa tarea concreta; el contexto persistente cubre lo que ya es "cultura asumida" del equipo.
- Partir de una plantilla de buenas prácticas ya consolidada y adaptarla a cada repositorio nuevo evita reconstruir este conocimiento desde cero cada vez.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.