Prompt semilla AGENTS.md para usar varios agentes de codificación con IA juntos en una base de código única o múltiple (EstreGenesis)

En un mismo proyecto, si pones a correr juntos varios agentes de codificación con IA como

• Claude Code
• Cursor
• GitHub Copilot
• Gemini (Antigravity)
• Cline
• Windsurf
• Continue

con el objetivo de distribuir tokens (minimizar costos),
CLAUDE.md, .cursor/rules/ y GEMINI.md empiezan poco a poco a desalinearse entre sí.
EstreGenesis es una biblioteca de prompts semilla de bootstrap AI Native creada para intentar resolver ese problema.

https://github.com/SoliEstre/EstreGenesis

Si tomas uno de los archivos semilla y lo entregas como primer mensaje del chat, ya sea

• copiando y pegando el contenido,
• proporcionándolo como ruta local,
• adjuntándolo, o
• explicando por chat de forma indirecta dónde está el archivo,

entonces el agente puede

• bootstrapear un proyecto nuevo con una estructura de fuente única de verdad en AGENTS.md + archivos puente por herramienta, o
• inspeccionar un proyecto existente que ya tenga archivos de reglas dispersos y migrarlo a esa misma estructura.

Según el nivel de profundidad, puedes elegir entre 3 niveles: 3-tier (Master / Lite / Compact).

• Lite es el valor predeterminado.
• Si tu estilo es gastar muchos tokens (priorizando calidad con modelos de gama alta como Opus 4.7, GPT 5.5, etc.), o si quieres un arnés más sólido en modelos más modestos (Sonnet, Haiku), conviene usar el nivel Master.
• En cambio, si quieres minimizar al máximo la influencia del seed, elige el nivel Compact.

Se ofrece en pares inglés/coreano.
Ambos seeds se mantienen sincronizados hasta en phase, migration y guías de operación, así que si tu equipo es bilingüe, pueden desplegar ambos pares de idioma al mismo tiempo.

Hay cuatro patrones clave:

1. AGENTS.md como SSoT + puentes delgados por herramienta para evitar el caos de reglas.
2. .agent/_coordination/ para prevenir conflictos de edición simultánea.
3. .agent/_lessons/ para que una depuración de 3 horas se convierta en una solución de 30 segundos en la siguiente sesión, evitando reincidencias.
4. Las decisiones importantes siguen el ciclo Research → Report → Plan, forzando un desarrollo más sólido basado en investigación.

Y lo que se agregó en esta versión v1.6.0 es una política de estimación de tiempo agent-time vs human-time.
Como la mayoría de las IAs, al planificar, suelen inflar los tiempos entre 5 y 10× usando como referencia el ritmo de un desarrollador humano,
en la selección del modo de ritmo de ejecución del bootstrap Phase 0 puedes definir de antemano una de estas opciones:

• Cautious 2~4×
• Proactive 5~6×
• Burst 6~8×
• Sprint 9~10×

y entonces todas las estimaciones se reportan separando tiempo de trabajo del agente + tiempo de revisión humana + tiempo real transcurrido.
También es posible cambiar de modo durante el proyecto y hacer ajustes con mediciones reales usando _lessons/.

Y una de las políticas opcionales importantes es el patrón de operar separando cada repo de proyectos relacionados (como FE/BE) y un repo aparte dedicado exclusivamente a documentación de desarrollo que los coordina a todos.

** Como Antigravity o GitHub Copilot no pueden acceder a archivos fuera de la carpeta de trabajo, la idea es poner cada repo de código fuente dentro del repo de documentación y registrar esas carpetas en .gitignore para separar el alcance de git.

Con esto se crea un repo de documentación centrado en archivos .md, y aunque el código fuente esté en un repo público, la documentación de desarrollo puede mantenerse privada para controlar mejor qué se publica.

En particular, si creas un proyecto en Claude Project y conectas por GitHub ese repo exclusivo de documentación a los archivos del proyecto para enlazarlo como conocimiento del proyecto, puedes dejar todo preparado para hacer no solo chat, sino también deep research basado en la documentación del proyecto. (Cada vez que hagas push al repo, necesitas hacer clic en el botón de actualización dentro del proyecto y esperar a que sincronice.)
Al usar por ambos lados tanto agentes de codificación como agentes capaces de hacer deep research, cuando surja algo que requiera investigación profunda, puedes pedir un prompt para solicitarla, ejecutar la deep research en Claude Project,
y luego poner el resultado en /archive/<fecha>_<tema> dentro del repo de documentación y dejar que el agente del IDE lo revise y lo integre; eso puede elevar mucho el nivel de avance del proyecto.
Además, mediante el chat de Claude Project también se puede pedir asesoría sobre monetización y temas de negocio (legales, patentes, etc.), así que me gustaría recomendar este patrón.

Este repo organiza como seeds el conocimiento acumulado mientras operaba en paralelo tres agentes —Antigravity + Claude Code + GitHub Copilot— en mi segundo proyecto AI Native realmente serio, mejorando errores repetidos y puntos incómodos sobre la marcha.
Además, he ido reuniendo patrones de uso útiles de otros proyectos míos para seguir haciendo crecer esa bola de nieve.

Y aunque no sea estrictamente un agente de codificación, incluso si se lo pasas a un agente como Hermes, absorbe bien las partes que le resultan adecuadas y las aplica, así que en la práctica también puede verse como un seed de uso general.

Por cierto, la licencia es Apache 2.0.

Se agradecen comentarios, issues y propuestas de puentes para otras herramientas de IA.

[kurthong]

Antes que nada, gracias por presentar un buen proyecto. También es un área que me interesa.
Organizaste muy bien los patrones. Te dejo este comentario porque, al leer el post, me surgieron dudas sobre dos puntos.
Primero: el costo acumulado de _lessons/. Si lessons se acumula hasta unas 100 > 500 entradas, el costo de hacer grep y luego leer los archivos completos va a aumentar de forma proporcional; me da curiosidad saber si tienen datos medidos sobre a partir de qué umbral ese costo inicial por tarea empezó a volverse pesado en un proyecto AI Native.
Porque la sección de optimización del índice RAG en v1.3 al final parece ser metadatos en Markdown, así que no me parece una solución de fondo.

Segundo: el punto donde, al operar varios agentes en simultáneo, el mismo archivo se carga duplicado tantas veces como agentes haya. Si la base es un diseño de 3 agentes, pero en cada sesión cada uno lee AGENTS.md + rules.md + architecture.md + STATE.md + lessons, ¿no termina siendo justamente un punto donde el objetivo de distribuir tokens se multiplica en vez de reducirse? Me gustaría saber cómo resolvieron esa parte, o si no, cómo piensan resolverla.

[soliestre]

La respuesta de arriba es lo que respondí en el momento basándome en lo que recuerdo con certeza: eran indicaciones que yo mismo di directamente en los prompts cuando estaba haciendo la ingeniería del seed harness,
y el manejo detallado de cómo acumular lessons fue un área que el agente revisó durante el proceso de build del seed y completó por su cuenta añadiendo detalles y reflejándolos. (Era algo que ya venía avanzándose en el proyecto donde trabajábamos antes de destilarlo al seed.)
Así que, más que responder yo directamente, pensé que lo correcto era preguntarle al agente que compiló el seed, que conoce mucho mejor la configuración real, y al llegar a casa le pedí su opinión sobre las preguntas y respuestas de arriba.

La respuesta que me resumió fue esta:

1. grep por tags — se acota la búsqueda con tags relacionados con el contexto de trabajo; no se releen todos los lessons.
2. Índice en _lessons/README.md — primer filtro antes del grep usando título, tags y resumen de una línea.
3. Promoción de patrones — los lessons que se repiten se consolidan en docs/troubleshooting/, y el límite natural del folder de indexación de más de 50 casos sirve como control.

Q2 va en la misma línea:

• la operación concurrente no tiene como objetivo ahorrar tokens, sino principalmente evitar conflictos y evitar el rule drift.

Eso fue lo que dijo.

Si el objetivo fuera distribuir tokens, entonces el método que mencioné arriba como ejemplo sí sería exactamente el patrón correcto.

[soliestre]

Revisé los proyectos en los que estoy trabajando actualmente, y parece que el máximo de lessons era 16.
Y como además se etiquetan junto con la parte de impacto y la severidad, da la impresión de que puede soportar cierta acumulación,
pero creo que sí habría que pensar en un plan para cuando se acumule más que eso.

En mi caso, no suelo ejecutar pruebas separadas para el seed,
y como no lo uso en proyectos a nivel demo sino que lo aplico, uso y voy puliendo en proyectos reales en pleno desarrollo, no tengo métricas aparte.
La parte de optimización del índice RAG, por ahora, está aplicada al nivel actual porque el objetivo es un repo de documentación de desarrollo centrado en Markdown.
(* Es una parte aplicada con el objetivo de optimizar la integración del repo de documentación de desarrollo en Claude Project.)

Sobre el segundo punto, en la práctica no diría que recomiendo una operación simultánea en tiempo real.
La suposición base es usar el modelo más efectivo según el objetivo,
y fuera de eso, sí se pueden usar al mismo tiempo cuando están trabajando en partes claramente distintas.
Por ejemplo, primero usar Claude como responsable de la parte de PM para hacer la planeación de distribución del trabajo,
luego ejecutar Antigravity y Codex en paralelo para FE y BE respectivamente,
y después que PM consolide los resultados y vuelva a hacer la siguiente planeación.

Y por ahora no estoy en una situación en la que necesite ahorrar tokens, así que estoy ejecutando todo en el master seed con modelos de gama alta,
por lo que la distribución de tokens la estoy abordando más bien desde la perspectiva de elegir planes con buena relación costo-beneficio para cada plataforma de agentes y, del mismo modo, suscribirme a planes rentables en otras plataformas para escalar horizontalmente.
Si el objetivo es ahorrar tokens de forma absoluta, en este momento no diría que sea recomendable usar este seed.

[soliestre]

Como referencia, el límite de capacidad para archivos (conocimiento del proyecto) de Claude Project es de alrededor de 10 MB, así que el repo necesariamente debe ser principalmente de texto.
Por supuesto, es posible excluir algunos archivos desde la UI de Claude Project, así que si están separados por carpetas o si la cantidad es pequeña, podría funcionar bien.