Agent को repository का उपयोगी context दें

वर्तमान checkout से शुरू करें

Agent को जानना चाहिए कि वह कौन-सी repository और branch बदल रहा है। उसे यह भी जानना चाहिए कि working directory में असंबंधित बदलाव हैं या नहीं। इन तथ्यों से तय होता है कि वह सुरक्षित रूप से क्या edit कर सकता है और अंतिम diff को कैसे समझना चाहिए।

Implementation से पहले agent से project instructions और package configuration का निरीक्षण करने को कहें। दूसरी repository से याद की गई command यहाँ गलत हो सकती है। परिचित framework के नाम से installed version या project के conventions सिद्ध नहीं होते।

छोटे बदलाव के लिए संबंधित module, callers, tests और architecture decision दें। जाँच में स्पष्ट जरूरत दिखने पर अधिक जानकारी जोड़ें।

स्थायी नियम repository instructions में रखें

Instruction file में समर्थित commands, module की सीमाएँ, review requirements और जिम्मेदार व्यक्ति के निर्णय वाली कार्रवाइयाँ बताई जा सकती हैं। AGENTS.md convention coding tools को इस जानकारी के लिए पहचानने योग्य स्थान देता है। Tools का support और instructions की प्राथमिकता अलग हो सकती है, इसलिए अपने tool का व्यवहार जाँचें।

Project के स्थायी नियम repository में रखें। वर्तमान काम task brief में रखें। Instruction file को हर बातचीत का इतिहास या अस्थायी योजनाओं की सूची न बनाएँ।

उपयोगी instruction है: “जब route के access व्यवहार में बदलाव हो, authorization integration tests चलाएँ।” अस्पष्ट instruction है: “Security को लेकर हमेशा सावधान रहें।” पहला instruction स्थिति और ऐसी कार्रवाई बताता है जिसे reviewer जाँच सकता है।

Instructions का code से मिलान करें

Commands, directories या architecture बदलने पर instructions पुराने पड़ जाते हैं। Guide में ऐसी script हो जो मौजूद नहीं है, तो package configuration जाँचें। Document किसी service को read-only बताता हो, तो उस दावे पर भरोसा करने से पहले permissions जाँचें।

टकराव दर्ज करें। Implementation का व्यवहार समझने के लिए वर्तमान version के सीधे प्रमाण इस्तेमाल करें। पुराने code में उल्लंघन होने के कारण जानबूझकर बनाई policy को चुपचाप न छोड़ें। Policy और वर्तमान व्यवहार अलग प्रश्नों के उत्तर हैं।

उदाहरण के लिए, guide shared branch पर direct writes रोक सकती है, जबकि पुरानी script अब भी ऐसा करती हो। सही प्रतिक्रिया policy बनाए रखना और script सुधारना है। मौजूदा code किसी प्रतिबंधित कार्रवाई को दोहराने की अनुमति नहीं है।

Context को संबंधित और सुरक्षित रखें

पूरी repository में credentials, private fixtures, customer exports और पुराने support logs हो सकते हैं। Repository access मिलने से हर file अपने आप model service के लिए उपयुक्त नहीं हो जाती।

स्वीकृत tools और डेटा के उपयोग के नियम अपनाएँ। Secrets context से बाहर रखें। जहाँ संभव हो, customer के उदाहरणों की जगह मनगढ़ंत डेटा दें। Uploaded files के साथ connected tools भी जाँचें: search connector ऐसी जानकारी ला सकता है जो शुरुआती prompt में थी ही नहीं।

Repository का “Secrets न पढ़ें” instruction उपयोगी guidance है। यह secret storage और संवेदनशील directories का access सीमित करने की जगह नहीं लेता।

अगले व्यक्ति के लिए उपयोगी record छोड़ें

काम पूरा होने पर बदला व्यवहार, verification और अनसुलझी सीमाएँ pull request में दर्ज करें। समर्थित workflow बदलने पर स्थायी project documentation update करें। Agent की पूरी बातचीत repository में copy करने से बचें।

Record से भविष्य में रखरखाव करने वाला व्यक्ति लंबी बातचीत दोबारा समझे बिना काम दोहरा सके। Canonical documents के links दें और हर स्थायी नियम का एक प्रामाणिक विवरण रखें।

अच्छे context से बार-बार की जाँच कम होती है। अपेक्षित व्यवहार और काम करने वाली commands स्पष्ट होने से गलतियाँ पहचानना भी आसान होता है।