Prompt semente AGENTS.md para usar vários agentes de IA de programação juntos em uma única ou múltiplas codebases (EstreGenesis)

Em um mesmo projeto,

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

ao rodar vários agentes de IA de programação em paralelo com o objetivo de distribuir tokens (minimizando custos),
CLAUDE.md, .cursor/rules/ e GEMINI.md começam cada vez mais a se desencontrar.
O EstreGenesis é uma biblioteca de prompts semente de bootstrap AI Native criada para tentar resolver esse problema.

https://github.com/SoliEstre/EstreGenesis

Se você pegar um único arquivo semente e, como primeira mensagem no chat,

• colar o conteúdo com copiar e colar, ou
• fornecer o caminho local, ou
• enviar como anexo, ou
• explicar no chat e informar indiretamente a localização do arquivo, etc.

então

o agente

• faz o bootstrap de um novo projeto com AGENTS.md como fonte única da verdade + uma estrutura de arquivos bridge por ferramenta, ou
• inspeciona um projeto existente que já tenha arquivos de regras dispersos e o migra para a mesma estrutura.

Dependendo da profundidade, basta escolher entre os 3 níveis (Master / Lite / Compact).

• Lite é o padrão.
• Se você segue um estilo de despejar muitos tokens (priorizando qualidade ao usar apenas modelos topo de linha, como Opus 4.7 e GPT 5.5),
  ou se quiser um harness mais robusto em modelos menores (Sonnet, Haiku), use o nível Master.
• Por outro lado, se quiser minimizar ao extremo a influência do seed, use o nível Compact.

É fornecido em par inglês/coreano.
Os seeds nas duas línguas são mantidos de forma idêntica até phase, migration e guide operacional, então, em equipes bilíngues, dá para implantar os pares nos dois idiomas juntos.

Os quatro padrões centrais são:

1. AGENTS.md como SSoT + bridges finas por ferramenta para evitar o caos de regras.
2. .agent/_coordination/ para evitar conflitos de edição simultânea.
3. .agent/_lessons/ para evitar reincidência, fazendo com que 3 horas de debug virem uma solução de 30 segundos na sessão seguinte.
4. Decisões importantes passam por um loop forçado de Research → Report → Plan, conduzindo um desenvolvimento robusto baseado em pesquisa.

E o que foi adicionado nesta v1.6.0 é a política de estimativa agent-time vs human-time.
Como, ao planejar, as IAs normalmente estimam prazos inflados em 5~10× com base no ritmo de um desenvolvedor humano,
na escolha do modo de ritmo de execução do bootstrap Phase 0,

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

se você definir isso antecipadamente,
todas as estimativas passam a ser reportadas separando tempo de trabalho do agente + tempo de revisão humana + tempo real decorrido.
Também é possível trocar de modo durante o andamento do projeto, e fazer calibração com medições reais usando _lessons/.

E uma das políticas opcionais importantes é o padrão de operar separando cada repositório de projeto relacionado (como FE/BE) e um repositório separado, dedicado exclusivamente à documentação de desenvolvimento, que coordena tudo isso.

** Como o Antigravity e o GitHub Copilot, entre outros, não conseguem acessar arquivos fora da pasta de trabalho, a ideia é colocar cada repositório de código-fonte sob o repositório de documentação e registrar essas pastas no .gitignore, separando assim o escopo do git.

Dessa forma, você passa a ter um repositório de documentação centrado em .md, e mesmo que o código-fonte esteja em um repositório público, só a documentação de desenvolvimento pode ficar privada, permitindo controlar o escopo de divulgação.

Especialmente no Project do Claude, se você criar um projeto e puxar esse repositório exclusivo de documentação para os arquivos do projeto por meio de uma conexão com o GitHub, ligando-o como conhecimento do projeto, isso vira uma configuração que permite não só conversar com base na documentação do projeto, mas também fazer deep research. (A cada push no repo, é preciso clicar no botão de atualização no projeto e esperar a sincronização.)
Usando ao mesmo tempo agentes de programação e agentes com capacidade de deep research, quando surgir algo que exija pesquisa aprofundada, você pode pedir um prompt de solicitação de deep research, rodar a pesquisa no Claude Project,
e então colocar o resultado em /archive/<data>_<tema> no repositório de documentação e deixar o agente da IDE revisar e consolidar isso, o que pode elevar bastante o nível de andamento do desenvolvimento do projeto.
Além disso, pelo chat do Claude Project também passa a ser possível obter consultoria sobre monetização e negócios (jurídico, patentes etc.), então é um padrão que eu gostaria de recomendar.

Este repositório é, no fundo, a organização em forma de seed do know-how acumulado enquanto eu operava simultaneamente três agentes — Antigravity + Claude Code + GitHub Copilot — no meu segundo projeto AI Native feito para valer, melhorando desconfortos e corrigindo erros recorrentes ao longo do caminho.
Também estou reunindo padrões de uso úteis de outros projetos meus e fazendo essa bola de neve crescer.

E não precisa nem ser necessariamente um agente de programação: mesmo se você entregar isso a um agente como o Hermes, ele absorve e aplica bem apenas as partes adequadas para si, então dá para ver isso praticamente como um seed universal.

Para referência, a licença é Apache 2.0.

Feedback, issues e sugestões de bridges para outras ferramentas de IA são bem-vindos.

[kurthong]

Antes de tudo, obrigado por apresentar um projeto tão bom. Também é uma área que me interessa.
Você organizou muito bem os padrões. Deixei este comentário porque, ao ler o texto, fiquei curioso sobre dois pontos.
Primeiro — o custo acumulado de _lessons/. Se os lessons se acumularem em algo como 100 > 500 itens, o custo de fazer grep e depois ler os arquivos por completo deve aumentar proporcionalmente. Em projetos AI Native, vocês têm algum dado de medição sobre a partir de que ponto esse custo de início de cada tarefa passou a ser um peso?
Como a seção de otimização do índice RAG da v1.3 acaba sendo, no fim, metadados em Markdown, tive a impressão de que não é uma solução essencial.

Segundo — o ponto em que, na operação simultânea de múltiplos agentes, o mesmo arquivo é carregado de forma duplicada pelo número de agentes. Pelo que entendi, a base é um design com 3 agentes, mas se em cada sessão cada um lê AGENTS.md + rules.md + architecture.md + STATE.md + lessons, então o objetivo de distribuir tokens não acaba, na verdade, sendo multiplicado nesse ponto? Fiquei curioso para saber como vocês resolveram isso, ou como pretendem resolver.

[soliestre]

A resposta acima foi algo que eu mesmo instruí diretamente por prompt quando estava fazendo a engenharia do seed harness, e respondi de bate-pronto com base no que eu lembrava com certeza,
ao passo que os detalhes de como lidar com o acúmulo específico de lessons foram uma parte que o agente revisou durante o processo de build do seed e complementou por conta própria para refletir isso, (algo que já estava em andamento no projeto em que trabalhávamos antes da destilação para o seed.)
Então achei que, em vez de eu responder diretamente, fazia mais sentido perguntar ao agente que consolidou o seed e conhece bem a configuração real, então quando cheguei em casa pedi a opinião dele sobre as perguntas e respostas acima.

A resposta que ele organizou foi esta:

1. grep por tags — restringe a busca com tags relacionadas ao contexto do trabalho; não é uma leitura completa de todas as lessons.
2. índice em _lessons/README.md — títulos, tags e um resumo de 1 linha servem como primeiro filtro antes do grep.
3. promoção de padrões — lessons recorrentes são consolidadas em docs/troubleshooting/, e o teto de uma pasta de indexação com mais de 50 itens faz esse controle acontecer naturalmente.

No Q2, é a mesma lógica:

• a operação concorrente não tem como objetivo economizar tokens, mas sim evitar conflitos e rule drift.

Foi isso que ele disse.

Se o objetivo for distribuir tokens, então o método que eu dei como exemplo acima seria exatamente o padrão correto.

[soliestre]

No momento, fui revisar os projetos em que estava trabalhando e vi que o máximo era 16 lessons.
E como a parte de impacto e a severidade também são rotuladas juntas, parece que isso deve aguentar um certo acúmulo,
mas acho que vale a pena já pensar em um plano para quando isso passar desse ponto.

No meu caso, não costumo rodar testes separados para o seed,
e, em vez de usar em projetos de nível demo, acabo aplicando e refinando isso enquanto uso em projetos reais já em andamento, então não tenho métricas separadas.
A parte de otimização do índice de RAG, por enquanto, está aplicada no nível atual porque o alvo é um repositório de documentação de desenvolvimento centrado em Markdown.
(* Essa é uma parte aplicada com o objetivo de otimizar a integração de repositórios de documentação de desenvolvimento no Claude Project.)

Sobre o segundo ponto, na prática eu não costumo recomendar operação simultânea em tempo real.
A premissa básica é usar o modelo mais eficaz de acordo com o objetivo,
e, fora isso, é possível usar ao mesmo tempo quando estiver trabalhando em partes claramente diferentes.
Por exemplo, você pode colocar o Claude responsável pela parte de PM e primeiro fazer o planejamento da distribuição do trabalho;
depois rodar Antigravity e Codex em paralelo para FE/BE, respectivamente;
e então o PM consolida os resultados e faz o próximo planejamento novamente.

E, no momento, como eu não estou numa situação em que preciso economizar tokens, acabo rodando tudo no master seed com modelos topo de linha,
então a distribuição de tokens está sendo tratada numa lógica de expansão horizontal: escolher, em cada plataforma de agente, o plano com melhor custo-benefício e assinar também planos custo-benefício em outras plataformas adicionais.
Se o objetivo principal for economizar tokens de forma absoluta, no estágio atual eu não recomendaria o uso deste seed.

[soliestre]

Só como referência, o limite de tamanho dos arquivos (conhecimento do projeto) no Claude Project é de cerca de 10MB, então o repositório precisa ser necessariamente focado em texto.
Claro, também é possível excluir alguns arquivos pela UI do Claude Project, então pode funcionar bem se eles estiverem separados por pasta ou se a quantidade for pequena.