Cursor AI को प्रॉम्प्ट करने की गाइड

जब कोई AI रिपॉज़िटरी जाँच सकता है, तो बेहतर प्रॉम्प्ट आम तौर पर व्यापक नहीं, संकरा होता है। Cursor को महत्वपूर्ण फ़ाइलें, सीमाएँ, बाध्यताएँ और सत्यापन दें, फिर संपादन से पहले उससे प्रासंगिक क्षेत्र का विश्लेषण करने को कहें।

रिपॉज़िटरी को समझने वाले टूल उपयोगी संदर्भ खोज सकते हैं, लेकिन वे बदलाव को वास्तविकता से अधिक निश्चित भी दिखा सकते हैं। लक्ष्य रिपॉज़िटरी एक्सेस को साक्ष्य में बदलना है, हर संबंधित फ़ाइल बदलने की अनुमति में नहीं।

Cursor के वर्तमान दस्तावेज़ में फ़ाइलों, फ़ोल्डरों, git बदलावों और linter त्रुटियों जैसे रिपॉज़िटरी मटीरियल के लिए context references बताए गए हैं। अपने संस्करण में उपलब्ध context controls का उपयोग करके सहायक को उपयोगी साक्ष्य के सबसे छोटे समूह तक निर्देशित करें।

उदाहरण के लिए, इसके बजाय:

धीमे dashboard को ठीक करें।

लिखें:

signed-in users के लिए dashboard loading delay की जाँच करें।

दायरा: dashboard route, उसके data-loading hook और उस एक card से शुरू करें
जो loading skeleton बहुत देर तक दिखाता है। संदर्भ के रूप में वर्तमान profile provider और
मौजूदा performance instrumentation का उपयोग करें।

परिणाम: पहचानें कि देरी fetch time, अनावश्यक rendering या किसी
state transition के कारण है। सबसे छोटा मापने योग्य सुधार प्रस्तावित करें।

बाध्यताएँ: authorization behavior, localized UI और मौजूदा loading
feedback सुरक्षित रखें। साक्ष्य के बिना cache या नई state library न जोड़ें।

संपादन से पहले execution path का सारांश दें और बताएँ कि आप क्या मापेंगे।

प्रॉम्प्ट सहायक को रिपॉज़िटरी तक पहुँचने का रास्ता देता है, लेकिन हर dashboard फ़ाइल को बदलाव योग्य नहीं मानता।

रिपॉज़िटरी संदर्भ किसी कार्य की शुरुआत में सबसे मूल्यवान होता है। Cursor से कहें कि वह:

1. प्रासंगिक data या control flow को ट्रेस करे;
2. व्यवहार के स्वामी कोड की पहचान करे;
3. पुष्टि किए गए तथ्यों को धारणाओं से अलग करे;
4. बदलने की संभावना वाली सबसे छोटी फ़ाइलें सूचीबद्ध करे;
5. बताए कि कौन-सा टेस्ट या अवलोकन fix को प्रमाणित करेगा।

यह विशेष रूप से तब महत्वपूर्ण है जब अनुरोध किसी साझा provider, global component, authentication, payments या navigation को छूता हो। इन क्षेत्रों में अक्सर ऐसे call sites होते हैं जिन्हें स्थानीय बदलाव सुरक्षित रूप से नज़रअंदाज़ नहीं कर सकता।

अगर कोई feature UI, persistence, workers और settings तक फैला है, तो “notifications feature अपडेट करें” भी व्यापक है। फ़ाइल या boundary constraint जोड़ें:

केवल notification preference form बदलें। client writer preference updates का source
of truth है; इस कार्य में कोई दूसरा writer न जोड़ें और scheduler न बदलें।

form, typed client writer और उनके सीधे tests जाँचें। अगर reported bug के लिए
backend बदलाव चाहिए, तो दायरा बढ़ाने के बजाय रुकें और साक्ष्य समझाएँ।

यह सहायक को वास्तविक cross-boundary issue खोजने से नहीं रोकता। यह विस्तार को स्पष्ट और समीक्षा योग्य बनाता है।

बार-बार लगने वाला project context हर chat prompt में नहीं, रिपॉज़िटरी के instructions या rules में होना चाहिए। स्थायी project guidance का उपयोग इन invariants के लिए करें:

• static-export या deployment boundaries;
• locale आवश्यकताएँ;
• test commands और code style;
• shared state के ownership rules;
• वे paths जहाँ विशेष समीक्षा चाहिए।

task prompt को विशिष्ट समस्या और स्वीकृति मानदंड पर केंद्रित रखें। यदि project instructions और प्रॉम्प्ट में असहमति हो, तो सहायक के अनुमान लगाने की आशा करने के बजाय अनुरोध में ही संघर्ष सुलझाएँ।

बड़े अनुरोधों को सत्यापित करना कठिन होता है, क्योंकि व्यापक diff कारण और प्रभाव छिपा देता है। काम को checkpoints में बाँटें:

पहले मौजूदा form submission path जाँचें और समझाएँ। फ़ाइलें संपादित न करें।

विश्लेषण के बाद केवल validation-state fix लागू करें और उसका केंद्रित
test जोड़ें। अभी पड़ोसी form components का रिफ़ैक्टर न करें।

प्रासंगिक test चलाएँ और diff का सारांश दें। अगर वह पास हो, तो shared cleanup के लिए
अलग follow-up प्रस्तावित करें।

यह पैटर्न सहायक के काम की समीक्षा आसान बनाता है और यदि परिकल्पना गलत हो तो rollback व्यावहारिक रखता है।

AI coding assistant को “सही लगता है” को पूरा होने का नियम नहीं चुनना चाहिए:

स्वीकृति मानदंड:
- सफल submission के लिए मौजूदा व्यवहार अब भी काम करता है;
- रिपोर्ट की गई invalid state पहुँच योग्य और दिखाई देने वाली बनती है;
- keyboard और screen-reader feedback सुरक्षित रहता है;
- लक्षित test पास होता है और उसकी विफलता पुराने bug को पकड़ लेती।

सत्यापन: केंद्रित test suite, type check चलाएँ और ऐसे व्यवहार को कवर करने वाला
कोई भी manual browser step बताएँ जिसे test देख नहीं सकता।

हरे compilation result से भरोसा गढ़ने के बजाय उससे missing test पहचानने को कहें।

कार्य: [एक-वाक्य का इंजीनियरिंग लक्ष्य।]

रिपॉज़िटरी संदर्भ: [प्रासंगिक फ़ाइलें, फ़ोल्डर, diff, त्रुटि या मौजूदा नियम।]
समस्या: [देखा गया व्यवहार और वह किसे प्रभावित करता है।]
दायरा: [पहले जाँचने वाली फ़ाइलें या सीमा।]
वांछित परिणाम: [उपयोगकर्ता या सिस्टम के लिए देखा जा सकने वाला परिणाम।]
बाध्यताएँ: [व्यवहार, संगतता, आर्किटेक्चर और गैर-लक्ष्य।]
स्वीकृति मानदंड: [आवश्यक परिणाम।]
सत्यापन: [केंद्रित टेस्ट, type check, मैन्युअल जाँच, माप।]

पहले विश्लेषण करें। व्यवहार के वर्तमान स्वामी को बताएँ, किसी कमज़ोर धारणा को चुनौती दें,
और संपादन से पहले सबसे छोटा सुरक्षित बदलाव प्रस्तावित करें।

व्यापक तर्क ढाँचे के लिए बेहतर AI प्रॉम्प्ट कैसे लिखें देखें, और कार्य प्रकार के अनुसार पैटर्न के लिए डेवलपर्स के लिए प्रॉम्प्ट इंजीनियरिंग पढ़ें। जो बदलाव मुख्यतः संरचनात्मक हो, उसके लिए कोड रिफ़ैक्टरिंग के प्रॉम्प्ट टेम्पलेट का उपयोग करें।

यदि किसी रिपॉज़िटरी कार्य में scripts या terminal output हो, तो उसे बदलने से पहले वास्तविक command behavior की पुष्टि करें। अनुमानित output को देखा जा सकने वाला test case बनाने के लिए ब्राउज़र में command-line workflows का अभ्यास करें।