Prompt seed AGENTS.md untuk menjalankan beberapa agen coding AI bersama pada codebase tunggal/multi (EstreGenesis)

Dalam satu proyek,

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

ketika beberapa agen coding AI seperti ini dijalankan bersama untuk tujuan distribusi token (meminimalkan biaya),
CLAUDE.md, .cursor/rules/, dan GEMINI.md lama-lama mulai berjalan sendiri-sendiri.
EstreGenesis adalah pustaka prompt seed bootstrap AI Native yang dibuat untuk mencoba memecahkan masalah itu.

https://github.com/SoliEstre/EstreGenesis

Jika satu file seed diberikan sebagai pesan pertama di chat dengan cara

• menyalin-tempel isinya,
• memberikan path lokalnya,
• melampirkannya, atau
• menjelaskan lokasinya lewat chat secara tidak langsung,

maka agen akan

• melakukan bootstrap proyek baru dengan struktur AGENTS.md sebagai single source of truth + file bridge khusus tiap alat, atau
• memeriksa proyek lama yang sudah punya file aturan yang tersebar dan memigrasikannya ke struktur yang sama.

Sesuai kedalaman kebutuhan, Anda bisa memilih salah satu dari 3 tier (Master / Lite / Compact).

• Lite adalah default.
• Jika Anda tipe yang rela menggelontorkan token (mengutamakan kualitas dengan hanya memakai model kelas atas seperti Opus 4.7, GPT 5.5, dll.), atau ingin harness yang lebih kokoh pada model yang lebih rendah (Sonnet, Haiku), gunakan tier Master.
• Sebaliknya, jika ingin meminimalkan pengaruh seed, gunakan tier Compact.

Disediakan dalam pasangan bahasa Inggris/Korea.
Kedua seed bahasa dikelola secara identik hingga phase, migration, dan panduan operasional, jadi untuk tim dwibahasa keduanya bisa dipasang berpasangan.

Ada empat pola inti:

1. AGENTS.md SSoT + bridge tipis per alat untuk mencegah kekacauan aturan.
2. .agent/_coordination/ untuk mencegah konflik edit simultan.
3. .agent/_lessons/ untuk mencegah masalah terulang, sehingga debug 3 jam bisa jadi beres dalam 30 detik di sesi berikutnya.
4. Untuk keputusan penting, loop Research → Report → Plan dipaksakan agar mendorong pengembangan yang kokoh berbasis riset.

Dan yang ditambahkan pada v1.6.0 kali ini adalah kebijakan estimasi agent-time vs human-time.
Karena kebanyakan AI saat menyusun rencana memperkirakan durasi berdasarkan standar developer manusia sehingga menjadi 5~10× lebih besar,
pada pemilihan mode tempo eksekusi di bootstrap Phase 0,

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

jika salah satunya ditetapkan lebih dulu,
semua estimasi akan dilaporkan dengan memisahkan waktu kerja agen + waktu review manusia + durasi aktual yang berlalu.
Mode juga bisa diganti saat proyek berjalan, dan koreksi berdasarkan pengukuran nyata dapat dilakukan lewat _lessons/.

Dan salah satu kebijakan opsional yang penting adalah pola operasi dengan memisahkan repo tiap proyek yang saling terhubung (seperti FE/BE) dan repo terpisah khusus dokumen pengembangan yang mengelola semuanya.

** Karena Antigravity atau GitHub Copilot, dll. tidak bisa mengakses file di luar folder kerja, caranya adalah menaruh tiap source repo di bawah repo dokumen lalu mendaftarkan folder tersebut ke .gitignore agar scope git terpisah.

Dengan cara ini akan terbentuk repo dokumen yang berfokus pada .md, dan meskipun source-nya public repo, dokumen pengembangannya saja bisa dibuat private sehingga cakupan publikasinya dapat diatur.

Khususnya, jika membuat project di Claude Project lalu menarik repo khusus dokumen ini ke file project melalui koneksi GitHub untuk dijadikan pengetahuan project, maka akan tercipta pengaturan yang memungkinkan bukan hanya chat berbasis dokumen proyek tetapi juga deep research. (Setiap kali repo di-push, perlu menekan tombol refresh di project dan menunggu sinkronisasi.)
Dengan memanfaatkan agen coding dan agen yang bisa melakukan deep research di kedua sisi, ketika muncul hal yang memerlukan deep research, Anda bisa meminta prompt permintaan deep research, menjalankannya di Claude Project, lalu menaruh hasilnya di /archive/<tanggal>_<topik> pada repo dokumen dan menyerahkan peninjauan serta penggabungannya kepada agen di IDE, sehingga progres pengembangan proyek dapat ditingkatkan ke level yang tinggi.
Bukan hanya itu, lewat chat Claude Project juga dimungkinkan konsultasi terkait monetisasi dan bisnis (hukum, paten, dll.), jadi pola ini sangat direkomendasikan.

Repo ini merangkum know-how yang terkumpul sambil menjalankan proyek AI Native serius saya yang kedua dengan operasi simultan 3 agen: Antigravity + Claude Code + GitHub Copilot, sembari memperbaiki kesalahan berulang dan bagian-bagian yang tidak nyaman, lalu menyusunnya menjadi seed.
Selain itu, saya juga mengumpulkan pola penggunaan yang berguna dari proyek-proyek saya yang lain untuk terus menggulirkan snowball ini.

Dan ini tidak harus hanya untuk agen coding; bahkan jika diberikan ke agen seperti Hermes, ia akan menyerap dan menerapkan bagian yang cocok untuk dirinya, jadi pada dasarnya ini bisa dianggap sebagai seed serbaguna.

Sebagai referensi, lisensinya adalah Apache 2.0.

Masukan, issue, dan usulan bridge untuk alat AI lain sangat disambut.

[kurthong]

Terima kasih terlebih dahulu atas pengenalan proyek yang bagus. Ini juga bidang yang saya minati.
Polanya sudah Anda susun dengan rapi. Sambil membaca tulisan utama, ada dua hal yang membuat saya penasaran, jadi saya meninggalkan komentar.
Pertama - biaya akumulasi _lessons/. Jika lessons menumpuk dari 100 menjadi sekitar 500, biaya untuk grep lalu membaca seluruh file akan meningkat secara proporsional. Dalam proyek AI Native, saya penasaran apakah Anda punya data pengukuran tentang mulai dari titik ambang mana biaya awal tiap task terasa memberatkan.
Karena bagian optimasi indeks RAG di v1.3 pada akhirnya adalah metadata Markdown, menurut saya itu tampaknya bukan solusi yang mendasar.

Kedua - saat menjalankan multi-agent secara bersamaan, bagian di mana file yang sama dimuat berulang sebanyak jumlah agent. Basisnya adalah desain 3 agent, tetapi jika di tiap sesi masing-masing membaca AGENTS.md + rules.md + architecture.md + STATE.md + lessons, bukankah bagian yang ditujukan untuk menyebarkan token justru malah berlipat? Saya penasaran apakah Anda sudah menemukan cara menyelesaikan bagian ini, atau kalau belum, bagaimana rencana Anda untuk menyelesaikannya.

[soliestre]

Jawaban di atas adalah respons spontan berdasarkan apa yang saya instruksikan langsung lewat prompt saat saya merekayasa seed harness, sejauh yang saya ingat dengan jelas,
rincian spesifik tentang cara menangani akumulasi lessons adalah area yang ditinjau oleh agen selama proses build seed lalu ditambahkan detailnya dan diterapkan dengan inisiatif sendiri, (bagian yang sudah dikerjakan sebelumnya di proyek yang dikerjakan sebelum didistilasi menjadi seed.)
Jadi, daripada saya menjawab langsung, rasanya lebih tepat menanyakan ke agen yang menghimpun seed dan benar-benar paham konfigurasi nyatanya, jadi setelah pulang saya minta pendapatnya tentang tanya-jawab di atas.

Jawaban yang dirangkum adalah seperti ini:

1. grep tag — pencarian dipersempit dengan tag yang terkait konteks pekerjaan, bukan membaca seluruh lessons dari awal sampai akhir.
2. Indeks _lessons/README.md — filter awal sebelum grep melalui judul, tag, dan ringkasan satu baris.
3. Promosi pola — lessons yang berulang dimantapkan ke docs/troubleshooting/, lalu dikendalikan secara alami dengan ceiling folder pengindeksan 50+ entri.

Untuk Q2, konteksnya juga sama:

• operasi concurrent bukan terutama untuk menghemat token, melainkan untuk mencegah konflik dan rule drift.

Begitu katanya.

Kalau tujuannya distribusi token, maka cara yang saya jadikan contoh di atas memang polanya yang tepat.

[soliestre]

Saat ini saya menelusuri proyek-proyek yang sedang saya kerjakan, dan ternyata jumlah lessons maksimalnya 16.
Dan karena bagian dampak serta Severity juga diberi label bersama, tampaknya akumulasi sampai tingkat tertentu masih bisa ditahan,
namun jika menumpuk lebih dari itu, sepertinya perlu dipikirkan rencananya.

Dalam kasus saya, saya tidak menjalankan pengujian terpisah khusus untuk seed,
dan bukan menggunakannya pada proyek tingkat demo, melainkan menerapkan, memakai, lalu menyempurnakannya sambil bekerja pada proyek nyata yang benar-benar sedang berjalan, jadi tidak ada data pengukuran tersendiri.
Untuk bagian optimasi indeks RAG, saat ini diterapkan pada level sekarang karena targetnya adalah repo dokumentasi pengembangan yang berfokus pada Markdown.
(* Bagian ini diterapkan dengan tujuan optimasi saat menghubungkan repo dokumentasi pengembangan di Claude Project.)

Untuk poin kedua, pada praktiknya saya tidak terlalu merekomendasikan operasi simultan real-time.
Asumsi dasarnya adalah menggunakan model yang efektif sesuai tujuannya,
dan selain itu, bila mengerjakan bagian yang jelas berbeda, bisa digunakan secara bersamaan.
Sebagai contoh, dengan Claude menangani bagian PM untuk lebih dulu membuat perencanaan pembagian pekerjaan,
lalu menjalankan FE/BE masing-masing secara paralel di Antigravity dan Codex,
kemudian PM mengumpulkan hasilnya dan melakukan perencanaan berikutnya lagi.

Dan untuk saat ini, karena saya bukan dalam situasi harus menghemat token, semua dijalankan dengan model kelas atas di master seed,
sehingga pembagian token didekati dari sisi memilih paket dengan rasio biaya-manfaat yang baik di tiap platform agen, lalu berlangganan paket yang juga efisien di platform tambahan lain untuk memperluas secara horizontal.
Jika tujuannya adalah benar-benar menghemat token, pada titik ini saya cenderung tidak merekomendasikan penggunaan seed ini.

[soliestre]

Sebagai referensi, batas kapasitas file (pengetahuan proyek) di Claude Project sekitar 10MB, jadi repo tersebut harus didominasi teks.
Tentu saja, beberapa file bisa dikecualikan lewat UI Claude Project, jadi jika dipisahkan per folder atau jumlah filenya sedikit, kemungkinan masih tidak masalah.