GitHub Copilot को प्रॉम्प्ट करने की सर्वोत्तम प्रथाएँ
स्पष्ट कार्य विवरण, प्रासंगिक रिपॉज़िटरी संदर्भ, सीमाओं और जाँचे जा सकने वाले स्वीकृति मानदंड के साथ GitHub Copilot से बेहतर परिणाम पाएँ।
जब कार्य विवरण समस्या, दायरा, सीमाएँ और सफलता का प्रमाण समझाता है, तो GitHub Copilot अधिक उपयोगी कोडिंग सहायता देता है। छोटा प्रॉम्प्ट स्थानीय code completion के लिए काम कर सकता है। रिपॉज़िटरी बदलाव को अच्छे ढंग से लिखे हुए issue जितनी स्पष्टता चाहिए।
उत्पाद सतह महत्वपूर्ण है: GitHub के वर्तमान दस्तावेज़ repository-wide instructions, path-specific instructions, agent instructions और फिर से उपयोग होने वाली prompt files का वर्णन करते हैं; उनका समर्थन फ़ीचर और IDE के अनुसार बदलता है। अपने वातावरण में उपलब्ध टूल इस्तेमाल करें, लेकिन मूल अनुरोध स्पष्ट रखें।
code completion को स्थानीय contract दें
छोटे फ़ंक्शन के लिए आसपास का नाम, types और tests अक्सर पर्याप्त होते हैं। उस व्यवहार को जोड़ें जिसमें सूक्ष्म रूप से गलती होने की आशंका है:
retry-after header के लिए parser लागू करें।
seconds या valid HTTP date, दोनों के लिए milliseconds लौटाएँ। missing, negative या
invalid value के लिए null लौटाएँ। response-error path से throw न करें।
seconds, future date, past date और malformed
input के लिए table-driven tests जोड़ें।
लंबे आर्किटेक्चर ब्रीफ़ की आवश्यकता के बिना यह contract completion को निर्देशित करता है।
टेस्ट कार्य को व्यवहार के रूप में बताएँ
इससे बचें:
preferences hook के लिए टेस्ट लिखें।
इसका उपयोग करें:
मौजूदा test conventions का उपयोग करके preferences hook के लिए टेस्ट जोड़ें।
सत्यापित करें कि initial loading state redirect नहीं करती, successful read
saved preferences को दिखाता है, update पूरा preference object
atomically लिखता है और failed update पिछले दिखाई देने वाले value को बनाए रखता है।
internal function-call counts के बजाय public behavior का उपयोग करें। उस
regression को शामिल करें जो reported bug के साथ विफल होती।
अब सहायक के पास उपयोगकर्ता-केंद्रित contract है, जिसमें एक महत्वपूर्ण नकारात्मक मामला भी शामिल है।
रिफ़ैक्टरिंग प्रॉम्प्ट में व्यवहार-संरक्षण नियम दें
कोड सुझाव किसी सार्वजनिक विवरण को छोड़ते हुए स्थानीय abstraction को सुघड़ बना सकते हैं। अनुरोध में संरक्षण शामिल करें:
इन दोनों card से दोहराई गई status presentation निकालें।
वर्तमान props, दिखाई देने वाले labels, analytics event names, keyboard focus
और mobile layout सुरक्षित रखें। बदलाव को इस feature और उसके सीधे tests तक सीमित रखें।
संपादन से पहले दोहराए गए व्यवहार और वे अंतर सूचीबद्ध करें जिन्हें अलग रहना चाहिए।
इसे shared design-system component में तब तक न बदलें, जब तक मौजूदा primitive
परिणाम को व्यक्त न कर सके।
यदि आप सुरक्षित रखने वाला व्यवहार नहीं बता सकते, तो पहले Copilot से वर्तमान contract और call sites समझाने को कहें।
लक्षणों और साक्ष्य के साथ डीबग करें
लक्षण: उपयोगकर्ता द्वारा filters बदलने के बाद search page stale results दिखाता है।
अपेक्षित: सबसे नया filter selection प्रदर्शित results को नियंत्रित करता है।
देखा गया: धीमा पिछला request नए response को overwrite कर सकता है।
प्रासंगिक कोड: filter UI, request hook और result renderer। हाल का बदलाव:
request retries जोड़े गए।
पहले request lifecycle और प्रतिस्पर्धी परिकल्पनाओं की रूपरेखा दें। बताएँ कि कौन-से logs या
test timing हर परिकल्पना को सिद्ध करेंगे। फिर सबसे छोटा fix और regression
coverage प्रस्तावित करें। साक्ष्य के बिना data layer न बदलें।
इससे सामान्य “race condition ठीक करें” उत्तर अनावश्यक state-management migration में नहीं फैलता।
स्थिर संदर्भ के लिए रिपॉज़िटरी निर्देशों का उपयोग करें
जहाँ समर्थित हो, स्थिर नियम project के साथ रहने चाहिए:
- tests और formatting कैसे चलाने हैं;
- deployment constraints;
- समर्थित locales या platforms;
- public APIs जिन्हें संगत रहना है;
- वे paths जहाँ security या accessibility reviews महत्वपूर्ण हैं।
GitHub के दस्तावेज़ repository-level custom instructions और अधिक लक्षित instruction files का वर्णन करते हैं। उन निर्देशों को छोटा, सटीक और स्थायी conventions तक सीमित रखें। वर्तमान ticket के विवरण—लक्षण, परिणाम और स्वीकृति मानदंड—प्रॉम्प्ट में ही रखें।
कोड पर आधारित दस्तावेज़ीकरण माँगें
नए environment check के बाद deployment troubleshooting guide अपडेट करें।
हर command और environment variable को रिपॉज़िटरी के सामने सत्यापित करें। success
signal, सामान्य failure signal और सुरक्षित अगली कार्रवाई समझाएँ। examples से secrets
बाहर रखें। मौजूदा operational runbook की नकल करने के बजाय उसके links जोड़ें।
“रिपॉज़िटरी के सामने सत्यापित करें” वाक्यांश महत्वपूर्ण है। यह Copilot को बताता है कि सटीक दस्तावेज़ीकरण कोड पढ़ने का काम है, prose generation का नहीं।
हर महत्वपूर्ण प्रॉम्प्ट को स्वीकृति मानदंड पर समाप्त करें
ऐसी finish line इस्तेमाल करें जिसकी कोई दूसरा व्यक्ति समीक्षा कर सके:
काम पूरा होने का अर्थ:
- रिपोर्ट किया गया उपयोगकर्ता व्यवहार बताए अनुसार बदलता है;
- सुरक्षित व्यवहार अपरिवर्तित रहता है;
- केंद्रित tests नए और पुराने paths को सिद्ध करते हैं;
- type check और प्रासंगिक lint command पास होते हैं;
- diff में कोई असंबंधित cleanup नहीं है।
सामान्य प्रॉम्प्ट संरचना के लिए बेहतर AI प्रॉम्प्ट कैसे लिखें पढ़ें। कार्य-विशिष्ट पैटर्न के लिए डेवलपर्स के लिए प्रॉम्प्ट इंजीनियरिंग जारी रखें, फिर AI कोडिंग सहायक की गलतियाँ और उनसे कैसे बचें में बताए गए failure modes से बचें।
जब किसी कोडिंग कार्य में scripts, command output या terminal reproduction शामिल हो, तो उसे याद से वर्णित करने के बजाय सत्यापित करें। उसे प्रॉम्प्ट या टेस्ट में बदलने से पहले अपने ब्राउज़र में command-line workflow का अभ्यास करें।
संदर्भ
ये दस्तावेज़ लिंक इस लेख में उपयोग किए गए कमांड के लिए आधिकारिक विवरण प्रदान करते हैं।