एक/अनेक codebase में कई AI coding agents को साथ चलाते समय इस्तेमाल होने वाला AGENTS.md seed prompt (EstreGenesis)

एक ही project में

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

जैसे AI coding agents को token distribution (लागत कम करने) के उद्देश्य से कई को साथ चलाते-चलाते,
CLAUDE.md, .cursor/rules/, और GEMINI.md धीरे-धीरे अलग-अलग दिशा में जाने लगते हैं।
EstreGenesis इसी समस्या को हल करने के लिए बनाया गया एक AI Native bootstrap seed prompt library है।

https://github.com/SoliEstre/EstreGenesis

बस किसी एक seed file को chat के पहले message में

• उसका content copy-paste करके डाल दें, या
• local path के रूप में दें, या
• attachment के रूप में भेज दें, या
• chat में समझाकर अप्रत्यक्ष रूप से file location बता दें

तो agent

• नए project को AGENTS.md single source of truth + हर tool के bridge file structure के साथ bootstrap कर देता है, या
• जिन existing projects में पहले से बिखरी हुई rule files हों, उन्हें inspect करके उसी structure में migrate कर देता है।

गहराई के हिसाब से 3-tier (Master / Lite / Compact) में से एक चुनकर इस्तेमाल कर सकते हैं।

• Lite default है।
• अगर आपका style token ज़्यादा खर्च करने वाला है (जैसे Opus 4.7, GPT 5.5 जैसे higher-end models ही इस्तेमाल करके quality को प्राथमिकता देना),
  या low-end models (Sonnet, Haiku) में harness को थोड़ा और मजबूत रखना चाहते हैं, तो Master tier इस्तेमाल करें।
• इसके उलट अगर seed के प्रभाव को बहुत कम रखना चाहते हैं, तो Compact tier चुनें।

यह English/Korean pair में उपलब्ध है।
दोनों language seeds में phase, migration, और operations guide तक एक जैसी maintenance की जाती है, इसलिए अगर आपकी team bilingual है, तो दोनों language pair को साथ deploy कर सकते हैं।

मुख्य pattern चार हैं:

1. AGENTS.md SSoT + tool-specific पतले bridge, ताकि rule chaos रोका जा सके।
2. .agent/_coordination/ के जरिए concurrent editing conflicts को रोकना।
3. .agent/_lessons/ के जरिए 3 घंटे की debugging को अगले session में 30 सेकंड में निपटाने लायक बनाकर वही गलती दोबारा होने से रोकना।
4. बड़े फैसलों में Research → Report → Plan loop को अनिवार्य करके research-based मज़बूत development को lead करना।

और इस v1.6.0 में जो जोड़ा गया है, वह agent-time vs human-time estimation policy है।
ज़्यादातर AI planning बनाते समय अवधि का अनुमान human developer के मानक के हिसाब से 5~10× बढ़ाकर बता देते हैं, इसलिए
bootstrap Phase 0 के execution pace mode selection में

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

में से पहले से चुन लेने पर
सारे estimates को agent work time + human review time + actual elapsed duration में अलग करके report किया जाता है।
project के दौरान mode switch भी किया जा सकता है, और _lessons/ के जरिए actual measurements के आधार पर calibration भी हो जाता है।

और एक अहम optional policy यह है कि (FE/BE जैसे) आपस में जुड़े project repos और उन्हें समग्र रूप से संभालने वाले अलग development-documentation-only repo को अलग करके चलाया जाए।

** Antigravity या Github Copilot जैसे tools work folder के बाहर की files access नहीं कर पाते, इसलिए documentation repo के नीचे हर source repo रखकर और उस folder को .gitignore में डालकर git scope को अलग किया जा सकता है.

ऐसा करने पर .md केंद्रित documentation repo बनता है। source public repo हो तो भी development documents को private रखकर उनकी visibility को अलग से नियंत्रित किया जा सकता है।

खासकर Claude के Project में project बनाकर इस documentation-only repo को project files में Github connection के जरिए जोड़ दें, तो उसे project knowledge से connect करके project documents के आधार पर chat ही नहीं, deep research तक संभव हो जाती है। (हर repo push के बाद project में refresh button दबाकर sync होने का इंतज़ार करना पड़ता है.)
coding agents और deep research करने वाले agents को दोनों तरफ इस्तेमाल करते हुए, जब deep research की ज़रूरत पड़े, तो deep research request prompt बनवाकर Claude Project में deep research चलाएँ,
और उसका result documentation repo के /archive/<date>_<topic> में डालकर IDE agent से review और consolidation कराएँ, तो project development की गुणवत्ता को काफ़ी ऊँचे स्तर तक ले जाया जा सकता है।
इतना ही नहीं, Claude Project chat के जरिए monetization और business (legal, patent वगैरह) से जुड़े advisory use cases भी संभव हो जाते हैं, इसलिए मैं इस pattern की सिफारिश करना चाहूँगा।

यह repo मेरे दूसरे serious AI Native project में Antigravity + Claude Code + GitHub Copilot इन 3 agents को एक साथ चलाते हुए, बार-बार होने वाली गलतियों और असुविधाजनक बिंदुओं को सुधारते-सुधारते जमा हुए know-how को seed के रूप में व्यवस्थित करके बनाया गया है।
इसके अलावा मेरे दूसरे projects से भी उपयोगी usage patterns इकट्ठे करके यह snowball की तरह बढ़ रहा है।

और ज़रूरी नहीं कि यह सिर्फ coding agents के लिए ही हो; Hermes जैसे agents को भी दे दें, तो वह अपने लिए उपयुक्त हिस्सों को अच्छी तरह absorb करके apply कर लेता है, इसलिए इसे लगभग all-purpose seed भी मान सकते हैं।

संदर्भ के लिए, license Apache 2.0 है।

feedback, issues, और दूसरे AI tools के लिए bridge suggestions का स्वागत है।

[kurthong]

सबसे पहले, अच्छे प्रोजेक्ट परिचय के लिए धन्यवाद। यह क्षेत्र मेरी भी रुचि का है.
आपने patterns को बहुत अच्छी तरह व्यवस्थित किया है। मूल लेख पढ़ते हुए दो बिंदुओं को लेकर जिज्ञासा हुई, इसलिए यह टिप्पणी लिख रहा हूँ।
पहला - _lessons/ का cumulative cost। अगर lessons 100 से >500 तक जमा हो जाएँ, तो grep के बाद फाइलों को पूरा पढ़ने की लागत अनुपात में बढ़ेगी। AI Native प्रोजेक्ट्स में ऐसा कौन-सा threshold था जहाँ हर task की शुरुआती लागत बोझिल लगने लगी? अगर आपके पास कोई measurement data हो, तो जानने में रुचि होगी।
v1.3 RAG index optimization section आखिरकार Markdown metadata ही लगती है, इसलिए यह मुझे मूलभूत समाधान नहीं लगता।

दूसरा - multi-agent concurrent operation के समय वह बिंदु जहाँ वही फाइल agent की संख्या के बराबर बार duplicate load होती है। यह 3-agent design base लगता है, लेकिन अगर हर session में AGENTS.md + rules.md + architecture.md + STATE.md + lessons सब पढ़े जाएँ, तो token distribution का उद्देश्य उल्टा गुणा होकर बढ़ नहीं जाता? इस हिस्से को आपने कैसे हल किया, या आगे कैसे हल करने की सोच रहे हैं, यह जानना चाहूँगा।

[soliestre]

ऊपर का जवाब वह सामग्री है जिसे मैंने seed harness को engineer करते समय सीधे prompt में निर्देशित किया था, और जहाँ तक मुझे पक्का याद है, उसी आधार पर तुरंत जवाब दिया था.
lessons के ठोस accumulation को handle करने के तरीके की बारीकियाँ seed build process में agent ने review करते हुए खुद detail जोड़कर reflect की थीं, (यानी seed में distill करने से पहले जिस project पर काम हो रहा था, वहाँ यह हिस्सा पहले से progress में था.)
इसलिए मुझे लगा कि मेरे सीधे जवाब देने से बेहतर होगा कि उस agent से पूछा जाए जिसने seed को संकलित किया था और जो वास्तविक configuration को अच्छी तरह समझता है, इसलिए घर आकर मैंने ऊपर के प्रश्नोत्तर पर उसकी राय पूछी.

उसने जवाब को इस तरह संक्षेप में व्यवस्थित किया:

1. tag grep — work context से जुड़े tags तक सीमित करके search, पूरे lessons को शुरू से अंत तक पढ़ना नहीं.
2. _lessons/README.md index — title·tag·1-line summary के आधार पर grep से पहले first-pass filter.
3. pattern promotion — बार-बार दोहराए जाने वाले lessons को docs/troubleshooting/ में स्थिर किया जाता है, और 50+ cases वाले indexing folder ceiling से यह स्वाभाविक रूप से नियंत्रित रहता है.

Q2 भी इसी संदर्भ में:

• concurrent operation का मुख्य उद्देश्य token बचत नहीं, बल्कि conflict prevention और rule drift prevention है.

उसका कहना यही है.

अगर उद्देश्य token distribution होता, तो ऊपर मैंने जो तरीका उदाहरण के तौर पर बताया था, वही सटीक pattern होता.

[soliestre]

मैंने अभी जिन प्रोजेक्ट्स पर काम कर रहा था, उन्हें देखा तो lessons की अधिकतम संख्या 16 ही थी.
और क्योंकि impact पार्ट और severity को साथ में label किया जाता है, इसलिए लगता है कि कुछ हद तक accumulation संभल जाएगा,
लेकिन अगर यह उससे ज़्यादा जमा हो जाए तो उसके लिए कोई plan पहले से सोचकर रखना होगा.

मेरे मामले में, मैं seed के लिए अलग से test नहीं चलाता,
और यह demo-स्तर के प्रोजेक्ट्स में आज़माने वाला मामला नहीं है, बल्कि वास्तव में चल रहे production-जैसे प्रोजेक्ट्स पर लागू करके इस्तेमाल करते हुए उसे refine कर रहा हूँ, इसलिए कोई अलग measurement data मौजूद नहीं है.
RAG index optimization वाला हिस्सा फिलहाल Markdown-केंद्रित development document repo को target करके मौजूदा स्तर पर लागू किया गया है.
(* यह Claude Project के development document repo integration के समय optimization के उद्देश्य से लागू किया गया हिस्सा है.)

दूसरे बिंदु के बारे में, व्यावहारिक रूप से मैं real-time simultaneous operation की खास सिफारिश नहीं करता.
मूल assumption यह है कि उद्देश्य के अनुसार सबसे प्रभावी model का उपयोग किया जाए,
और इसके अलावा, जब साफ़ तौर पर अलग-अलग parts पर काम हो रहा हो, तब उन्हें एक साथ इस्तेमाल किया जा सकता है.
उदाहरण के लिए, पहले Claude को PM part की ज़िम्मेदारी देकर task distribution planning कराई जाए,
फिर Antigravity और Codex में FE/BE को क्रमशः एक साथ चलाया जाए,
और उसके बाद PM नतीजों को समेटकर फिर अगली planning करे — कुछ इस तरह.

और फिलहाल मैं ऐसी स्थिति में नहीं हूँ जहाँ मुझे token बचाने की ज़रूरत हो, इसलिए master seed में सब कुछ higher-end models पर चला रहा हूँ,
इस वजह से token distribution को हर agent platform के लिए बेहतर cost-performance plan चुनने, और अतिरिक्त platforms के लिए भी उसी तरह cost-effective plan subscribe करके horizontal scaling के नज़रिए से approach किया जा रहा है.
अगर उद्देश्य बिल्कुल token बचाना है, तो मौजूदा समय में मैं इस seed के उपयोग की सिफारिश नहीं करूँगा.

[soliestre]

संदर्भ के लिए, Claude Project की फ़ाइलें (project knowledge) की capacity limit लगभग 10MB है, इसलिए repo का मुख्यतः text-केंद्रित होना ज़रूरी है.
बेशक, कुछ फ़ाइलों को exclude करना Claude Project की UI में संभव है, इसलिए अगर वे folders से अलग की गई हों या उनकी संख्या कम हो, तो वह भी ठीक हो सकता है.