AGENTS.md: हर coding agent के लिए एक ही context file (Codex, Gemini, Claude)

आपने एक पूरी दोपहर एक साफ-सुथरा CLAUDE.md लिखने में लगाई। आपका agent आखिरकार आपकी stack का अंदाज़ा लगाना बंद करके सही test command चलाने लगा। फिर एक teammate वही repo Codex में खोलता है, आप किसी side branch पर Gemini CLI आज़माते हैं, और इतनी मेहनत से बना वह सारा context साथ नहीं आता। हर tool अपनी ही file चाहता है, अपनी ही जगह पर।

AGENTS.md इसी झंझट का जवाब है: एक सादा Markdown file, आपके repo की root पर, जिसे कोई भी coding agent आपके code को छूने से पहले पढ़ता है।

AGENTS.md असल में है क्या

कोई जादू नहीं है। यह AGENTS.md नाम की एक Markdown file है, आमतौर पर repository की root पर, जिसे agent काम शुरू करने से पहले स्थायी निर्देशों की तरह load करता है। इसे ऐसे समझिए जैसे वह README जो आप अपने इंसानी साथियों के बजाय अपने AI साथियों के लिए लिखते हैं: project है क्या, इसे build और test कैसे करना है, किन conventions का पालन करना है, और किन जालों से बचना है।

यह एक खुला convention है, जिसे Codex और agent tools की एक बढ़ती हुई सूची पहले से पढ़ती है, और जिसका साफ़ मकसद इनके बीच portable होना है। एक file, बहुत सारे agents, हर tool के लिए एक अलग बनी-बनाई file के बजाय।

AGENTS.md vs CLAUDE.md vs GEMINI.md

अभी पूरा माहौल tool के हिसाब से बँटा हुआ है:

• CLAUDE.md वह है जिसे Claude Code ढूँढता है।
• GEMINI.md Gemini CLI का convention है।
• AGENTS.md cross-tool standard है, जिसे Codex और बाकी पढ़ते हैं, और जो न्यूट्रल वाली file बनने के लिए बना है।

तीनों में content लगभग एक जैसा होता है: project context, commands, conventions. असली फर्क सिर्फ़ इतना है कि हर tool default रूप से कौन-सी file का नाम पढ़ता है। ठीक इसी वजह से एक ही नियमों को हाथ से तीन files में copy करना एक हारी हुई लड़ाई है (इन्हें sync में रखने के बारे में आगे और बात होगी)।

अगर आप ज़्यादातर Claude Code में काम करते हैं, तो हमारी CLAUDE.md guide Claude-specific structure में गहराई से जाती है। AGENTS.md उसी file का provider-न्यूट्रल भाई है।

इसमें क्या डालें

इसे छोटा और high-signal रखें। agent इसे हर task पर पढ़ता है, इसलिए हर लाइन ध्यान खींचने के लिए होड़ करती है। ज़रूरी चीज़ें:

• stack, एक साँस में। "Next.js 16, TypeScript, Prisma, MariaDB." न इतिहास, न marketing.
• वही commands जो मायने रखती हैं। install, run, build, test और lint कैसे करें। सटीक commands: npm test, न कि "tests चलाओ।"
• Conventions। Naming, file layout, error handling, वे patterns जिन्हें आप review में सचमुच लागू करवाते हैं।
• एक directory map। दो लाइनों में कि चीज़ें कहाँ रहती हैं, ताकि agent अंधाधुंध grep करना बंद कर दे।
• "छूने से पहले पढ़ो" वाले नियम। "billing/ के नीचे कुछ भी edit करने से पहले docs/payments.md पढ़ो।" यह एक आदत ही बहुत सारे नुकसान से बचा लेती है।
• पक्के "ना" वाले नियम। "बिना कहे कभी branch मत बनाओ।" "Commit की गई files में machine के absolute paths नहीं।"

वे गलतियाँ जिनकी वजह से agents इसे नज़रअंदाज़ कर देते हैं

एक context file चुपचाप नाकाम होती है। agent कोई error नहीं फेंकता, बस भटक जाता है। आम वजहें:

1. बहुत लंबी। 600 लाइनों की file उन पाँच नियमों को दबा देती है जो असल में मायने रखते हैं। जो कुछ agent code से ही समझ सकता है, उसे काट दें।
2. अंतर्विरोध। एक section में "हमेशा tests लिखो," दूसरे में "prototypes के लिए tests छोड़ दो।" agent किसी एक को रैंडम चुन लेता है।
3. Machine से बँधे paths। Commit की गई file में /Users/you/project/... हर teammate के लिए, और हर दूसरी machine पर हर agent के लिए टूट जाता है। paths relative रखें।
4. पुरानी पड़ चुकी commands। test command छह महीने पहले बदल गई, file नहीं बदली। अब agent पूरे आत्मविश्वास से गलत चीज़ चला देता है।
5. कोई प्राथमिकता नहीं। सब कुछ "ज़रूरी" है, तो कुछ भी ज़रूरी नहीं रहता। non-negotiables को सबसे ऊपर रखें और उन्हें लेबल करें।
6. Documentation उड़ेल देना। ये instructions हैं, wiki नहीं। अपनी docs के लिंक दें, उन्हें इसमें चिपकाएँ नहीं।

providers के बीच एक ही context बनाए रखना

यहाँ वह व्यावहारिक हिस्सा है जिसे ज़्यादातर guides छोड़ देती हैं। अगर आप, या आपकी टीम, एक से ज़्यादा agent CLI चलाते हैं, तो आप एक ही नियमों की तीन भटकती हुई copies नहीं चाहेंगे।

दो साफ-सुथरे तरीके:

• एक canonical file, पतले pointers। सब कुछ AGENTS.md में रखें और CLAUDE.md तथा GEMINI.md को एक-लाइन की files बना दें जो कहें "AGENTS.md देखें," या उनके symlink बना दें। एक ही source of truth, हर tool को खुराक मिलती है।
• एक file, convention से साझा। अगर आपके tools को किसी custom path पर point किया जा सकता है, तो उन सबको AGENTS.md की ओर मोड़ दें और बाकी मिटा दें।

दोनों ही हालत में नियम एक ही है: context एक बार लिखें, हर provider के लिए एक बार नहीं। यही एकमात्र तरीका भी है जिससे यह सही बना रहता है, क्योंकि एक ही file ही वह अकेली file होती है जिसे लोग सचमुच maintain करते हैं।

जब आप एक साथ कई agents चलाते हैं

repo-level का AGENTS.md इस सवाल का जवाब देता है कि "यह project क्या है।" यह इस सवाल का जवाब नहीं देता कि "यह agent कौन है।" जब आप एक ही code पर एक Backend agent, एक Frontend agent और एक QA agent समानांतर में चलाते हैं, तो हर एक को साझा project context के साथ-साथ अपनी खुद की role भी चाहिए।

यही वह परत है जो AgentsRoom आपके AGENTS.md के ऊपर जोड़ता है। हर agent को एक समर्पित role मिलती है अपने ही system prompt के साथ (DevOps, Frontend, Security और बाकी), ताकि साझा file हल्की बनी रहे जबकि हर agent को फिर भी अपना काम पता रहे। यह डिज़ाइन से ही provider-agnostic है, इसलिए वही setup Claude, Codex या Gemini को साथ-साथ चलाता है, और आपके दोहराए जाने वाले निर्देश हर session में दोबारा टाइप होने के बजाय एक Prompt Library में रहते हैं।

जब आप उस मुकाम पर पहुँचते हैं, तो कई agents को समानांतर में चलाते हुए नज़र न खोने का तरीका अगली स्वाभाविक पढ़ाई है।

निचोड़

एक ही AGENTS.md लिखें। इसे छोटा रखें, अद्यतन रखें, portable रखें। हर tool को इसी की ओर point करें, बजाय हर agent के लिए एक अलग file maintain करने के। आपका context उस CLI से बँधा रहना बंद कर देता है जिससे आपने संयोग से शुरुआत की थी, और आपके agents, चाहे आप कोई भी चलाएँ, सब एक ही पन्ने से शुरू करते हैं।

चाहते हैं कि हर agent एक ही स्क्रीन पर हो, हर एक अपनी role और आपके साझा context के साथ? AgentsRoom डाउनलोड करें, अपना provider connect करें, और अपने बेड़े को काम पर लगा दें।