Birden çok AI kodlama ajanını tekli/çoklu kod tabanında birlikte çalıştırırken kullanılan AGENTS.md tohum prompt’u (EstreGenesis)

Tek bir projede

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

gibi AI kodlama ajanlarını token dağıtımı (maliyeti en aza indirme) amacıyla bir arada çalıştırmaya başlayınca,
CLAUDE.md, .cursor/rules/ ve GEMINI.md zamanla birbirinden kopmaya başlıyor.
EstreGenesis, bu sorunu çözmek için oluşturulmuş AI Native bootstrap tohum prompt kütüphanesidir.

https://github.com/SoliEstre/EstreGenesis

Tek bir tohum dosyasını sohbetin ilk mesajı olarak

• içeriği kopyalayıp yapıştırarak,
• yerel bir yol olarak vererek,
• ek olarak yükleyerek ya da
• sohbette açıklayıp dolaylı biçimde dosya konumunu ileterek

aktardığınızda

ajan

• yeni bir projeyi AGENTS.md tek doğruluk kaynağı + araç bazlı köprü dosyaları yapısıyla bootstrap edebilir ya da
• dağınık kural dosyaları bulunan mevcut bir projeyi inceleyip aynı yapıya migrate edebilir.

Derinlik ihtiyacına göre 3 kademeden (Master / Lite / Compact) birini seçebilirsiniz.

• Varsayılan seviye Lite’tır.
• Token’ı bolca kullanan bir tarzınız varsa (Opus 4.7, GPT 5.5 gibi üst seviye modellerle kalite odaklı çalışmak) ya da
  daha düşük modellerde (Sonnet, Haiku) düzeni daha sağlam kurmak istiyorsanız Master kademesini kullanabilirsiniz.
• Buna karşılık tohumun etkisini en aza indirmek istiyorsanız Compact kademesine geçebilirsiniz.

İngilizce/Türkçe değil, İngilizce/Korece çiftleri olarak sunuluyor.
İki dildeki tohumlar phase, migration ve işletim rehberine kadar aynı şekilde yönetildiği için, iki dilli ekiplerde her iki dil çifti birlikte de dağıtılabilir.

Temel desen dört başlıkta toplanıyor:

1. AGENTS.md SSoT + araç bazlı ince köprülerle kural kaosunu önleme.
2. .agent/_coordination/ ile eşzamanlı düzenleme çakışmalarını engelleme.
3. .agent/_lessons/ ile 3 saatlik debug sürecinin bir sonraki oturumda 30 saniyede çözülmesini sağlayarak aynı sorunun tekrarını önleme.
4. Kritik kararlar için Research → Report → Plan döngüsünü zorunlu kılarak araştırma temelli, sağlam geliştirme sürecini yönlendirme.

Ayrıca bu v1.6.0 sürümünde eklenen yeniliklerden biri de agent-time vs human-time tahmin politikası.
Çoğu AI planlama yaparken süre tahminlerini insan geliştirici ölçüsüne göre 5~10× şişirdiği için,
bootstrap Phase 0’daki çalışma temposu modu seçiminde

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

seçeneklerinden birini baştan belirlediğinizde,
tüm tahminler ajan çalışma süresi + insan inceleme süresi + gerçek geçen süre olarak ayrıştırılarak raporlanıyor.
Proje ilerlerken mod değişikliği de yapılabiliyor ve _lessons/ ile gerçek ölçümlere göre düzeltme uygulanabiliyor.

Önemli ve isteğe bağlı politikalardan biri de, (FE/BE gibi) birbirine bağlı proje repo’larını ve bunları yöneten ayrı bir geliştirme dokümantasyonu repo’sunu birbirinden ayırarak işletme deseni.

** Antigravity veya Github Copilot gibi araçlar çalışma klasörü dışındaki dosyalara erişemediği için, doküman repo’sunun altına her kaynak repo’yu yerleştirip ilgili klasörleri .gitignore içine ekleyerek git kapsamını ayırma yaklaşımı.

Bu şekilde çoğunlukla .md dosyalarından oluşan bir doküman repo’su ortaya çıkıyor; kaynak public repo olsa bile geliştirme dokümanlarını private tutarak görünürlük kapsamını ayrı yönetmek mümkün oluyor.

Özellikle Claude Project içinde proje oluşturup bu doküman repo’sunu projenin dosyalarına GitHub bağlantısıyla ekleyerek proje bilgisine bağlarsanız, proje dokümanları temelli olarak yalnızca sohbet değil deep research de yapılabilen bir kurulum elde ediyorsunuz. (Her repo push işleminden sonra project içinde yenile butonuna tıklayıp senkronizasyonun tamamlanmasını beklemek gerekir.)
Kodlama ajanları ile deep research yapabilen ajanları birlikte kullanırken, deep research gerektiren bir konu çıktığında deep research talep prompt’u isteyip Claude Project üzerinde çalıştırabilir,
çıkan sonucu doküman repo’sundaki /archive/<tarih>_<konu> altına koyup IDE içindeki ajana gözden geçirme ve derleme görevi verebilirsiniz; bu da projenin geliştirme sürecini yüksek bir seviyeye taşır.
Bununla da kalmayıp, Claude Project sohbeti üzerinden gelir elde etme ve iş dünyasıyla ilgili (hukuk, patent vb.) danışmanlık da mümkün hale geldiği için bu deseni özellikle tavsiye ediyorum.

Bu repo, benim ikinci ciddi AI Native projemde Antigravity + Claude Code + GitHub Copilot olmak üzere 3 ajanı eşzamanlı kullanırken, aynı hataların tekrarını ve rahatsız edici noktaları iyileştirerek biriktirdiğim deneyimi tohum haline getirdiğim bir çalışma.
Bunun dışında diğer projelerimde işe yarayan kullanım desenlerini de toplayarak bu kartopunu büyütmeye devam ediyorum.

Ayrıca illa bir kodlama ajanı olması da gerekmiyor; Hermes gibi ajanlara verseniz de kendisine uygun kısımları iyi şekilde özümseyip uyguladığı için, pratikte evrensel bir tohum olarak da görülebilir.

Bu arada lisans Apache 2.0’dır.

Geri bildirimler, issue’lar ve diğer AI araç köprüleri için öneriler memnuniyetle karşılanır.

[kurthong]

Öncelikle güzel proje tanıtımı için teşekkürler. Benim de ilgi duyduğum bir alan.
Örüntüleri iyi derlemişsiniz. Yazıyı okurken iki noktayı merak ettiğim için yorum bırakıyorum.
Birincisi - _lessons/ birikimli maliyeti. lessons sayısı 100’den >500’e kadar birikirse grep sonrası dosyaların baştan sona okunma maliyeti orantılı olarak artacaktır; AI Native projelerde görev başına başlangıç maliyetinin hangi eşikten itibaren yük olmaya başladığına dair, varsa, ölçüm verilerini merak ediyorum.
v1.3 RAG indeks optimizasyonu bölümü sonuçta Markdown metadata’sı olduğu için bunun özsel bir çözüm olmadığını düşünüyorum.

İkincisi - çoklu ajanı eşzamanlı çalıştırırken aynı dosyanın ajan sayısı kadar tekrar yüklenmesi meselesi. Tasarım temeli 3 ajan olsa da her biri kendi oturumunda AGENTS.md + rules.md + architecture.md + STATE.md + lessons dosyalarının tamamını okuyorsa, token dağıtma amacı tersine çarpan etkisi yaratmıyor mu? Bu kısmı nasıl ele aldığınızı ya da ileride nasıl ele almayı düşündüğünüzü merak ediyorum.

[soliestre]

Yukarıdaki yanıt, seed harness’ı tasarlarken doğrudan prompt’larla talimat verdiğim ve emin olduğum kadarıyla hemen yanıtladığım içerikti.
Lessons birikiminin nasıl ele alındığına dair ayrıntılar ise seed build sürecinde ajan tarafından incelenip detaylar eklenerek yansıtılan bir alandı; yani seed’e damıtılmadan önce üzerinde çalışılan projede zaten ilerlemiş kısım.
Bu yüzden doğrudan benim yanıtlamamdan ziyade, gerçek yapıyı en iyi bilen ve seed’i derleyen ajana sormanın daha doğru olacağını düşündüm; eve gelince yukarıdaki soru-cevap hakkında görüşünü sordum.

Onun düzenleyip verdiği yanıt şöyle:

1. Etiket grep’i — İş bağlamıyla ilgili etiketlere daraltarak arama yapılıyor; tüm lessons baştan sona okunmuyor.
2. _lessons/README.md indeksi — Başlık, etiket ve tek satırlık özetle grep öncesi ilk filtreleme yapılıyor.
3. Pattern yükseltme — Tekrarlayan lessons, docs/troubleshooting/ altına yerleştiriliyor; 50+ kayıtlı indeks klasörü tavanı sayesinde doğal bir kontrol sağlanıyor.

Q2 de aynı bağlamda:

• Eşzamanlı kullanımın asıl amacı token tasarrufu değil, çakışmaları ve rule drift’i önlemek.

Böyle söylüyor.

Amaç token dağıtımıysa, yukarıda örnek olarak verdiğim yöntem tam olarak doğru pattern olur.

[soliestre]

Şu anda üzerinde çalıştığım projeleri gözden geçirdim; lessons için en fazla 16 tane vardı.
Ayrıca etki kısmı ve Severity birlikte etiketlendiği için belli bir seviyeye kadar birikmeyi kaldıracak gibi görünüyor,
ama bunun üstüne yığılması durumuna yönelik bir planı da düşünmek gerekecek gibi.

Benim durumumda seed için ayrı testler çalıştırmıyorum;
demo seviyesindeki projelerde denemekten ziyade gerçekten aktif olarak yürüyen projelere uygulayıp kullanırken iyileştiriyorum, bu yüzden ayrıca ölçüm verisi yok.
RAG indeks optimizasyonu kısmı şu an için ağırlıklı olarak Markdown tabanlı geliştirme dokümantasyonu repo hedefi için mevcut seviyede uygulanmış durumda.
(* Claude Project'in geliştirme dokümanı repo entegrasyonunda optimizasyon amacıyla uygulanmış kısımdır.)

İkinci konuya gelince, pratikte gerçek zamanlı eşzamanlı kullanım önermiyorum.
Temel varsayım, amaca göre etkili modeli kullanmak;
bunun dışında bariz biçimde farklı parçalar üzerinde çalışılıyorsa aynı anda kullanılabilir.
Örneğin önce Claude'u PM kısmından sorumlu tutup iş dağıtımı planlamasını yaptırdıktan sonra,
Antigravity ve Codex'te FE/BE taraflarını aynı anda çalıştırıp,
sonrasında PM'in sonuçları derleyip yeniden bir sonraki planlamayı yapması gibi.

Ayrıca şu anda benim için token tasarrufu öncelikli bir durum olmadığından, master seed'in tamamını üst seviye modellerle çalıştırıyorum.
Bu yüzden token dağıtımı, her ajan platformunda fiyat/performansı yüksek planı seçip ek platformlarda da benzer şekilde uygun maliyetli planlara abone olarak yatay ölçekleme yaklaşımıyla ele alınıyor.
Mutlak amaç token'ı olabildiğince kısmaksa, şu aşamada bu seed'in kullanımını özellikle önermem.

[soliestre]

Bilginize, Claude Project'in dosya (proje bilgisi) kapasite sınırı yaklaşık 10MB olduğu için repoda mutlaka metin ağırlıklı içerik bulunmalıdır.
Elbette bazı dosyaları hariç tutmak Claude Project tarafındaki UI üzerinden mümkün olduğundan, klasörlerle ayrılmışsa veya dosya sayısı azsa bu da sorun olmayabilir.