कर्सर आईडीई नियम: कृत्रिम बुद्धिमत्ता कोडिंग के लिए दिशानिर्देश

कर्सर आईडीई में तीन स्तरों पर नियम लागू किए जाते हैं:

1. कर्सर आईडीई सेटिंग्स में एआई के लिए नियम - आधार नियम जो सभी प्रोजेक्ट्स पर वैश्विक रूप से लागू होते हैं
2. .cursor/index.mdc फ़ाइल Rule Type "Always" के साथ - रिपॉजिटरी-विशिष्ट कर्सर प्रोजेक्ट नियम (पुराने .cursorrules दृष्टिकोण को प्रतिस्थापित करता है)
3. .cursor/rules/*.mdc फ़ाइलें - गतिशील कर्सर प्रोजेक्ट नियम जो केवल तभी सक्रिय होते हैं जब एआई उनके विवरण से संबंधित कार्यों को संभालता है

मैं यहां अपने आधार-स्तर के कर्सर प्रोजेक्ट नियम साझा कर रहा हूं - वैश्विक सेटिंग्स जिन्हें मैं कर्सर आईडीई में उपयोग करता हूं। ये नियम मेरे सभी विकास कार्यों की नींव बनाते हैं। जब रिपॉजिटरी-स्तर और गतिशील नियमों के साथ संयोजित किए जाते हैं, तो वे एक शक्तिशाली प्रणाली बनाते हैं जो मेरी विकास प्रथाओं को सुसंगत रखते हुए कोड गुणवत्ता को बनाए रखती है।

वीडियो ट्यूटोरियल पसंद करते हैं? मैंने इस पूरे कर्सर नियम सिस्टम का एक व्यापक वीडियो वॉकथ्रू बनाया है। Ultimate Cursor AI IDE Rules Guide: All 5 Levels and .cursorrules (2025) देखें इन तकनीकों को चरणबद्ध तरीके से लागू होते देखने के लिए।

इष्टतम एआई कोडिंग प्रदर्शन के लिए कर्सर नियम कैसे कॉन्फ़िगर करें

कर्सर -> सेटिंग्स -> कर्सर सेटिंग्स -> एआई के लिए नियम:

<cursorrules_instructions_to_the_dialog>

<cursorrules_code_style>
- केवल अंग्रेजी में टिप्पणियां
- OOP से अधिक फंक्शनल प्रोग्रामिंग को प्राथमिकता दें
- बाहरी सिस्टम के लिए कनेक्टर्स और इंटरफेस के लिए अलग OOP क्लास का उपयोग करें
- अन्य सभी लॉजिक को शुद्ध फंक्शन के साथ लिखें (स्पष्ट इनपुट/आउटपुट, कोई छिपा स्टेट परिवर्तन नहीं)
- फंक्शन केवल अपने रिटर्न वैल्यू को संशोधित करें - कभी भी इनपुट पैरामीटर, ग्लोबल स्टेट, या स्पष्ट रूप से वापस न किए गए किसी भी डेटा को संशोधित न करें
- न्यूनतम, केंद्रित परिवर्तन करें
- DRY, KISS, और YAGNI सिद्धांतों का पालन करें
- सभी भाषाओं में सख्त टाइपिंग (फंक्शन रिटर्न, वेरिएबल) का उपयोग करें
- जब संभव हो तो फंक्शन कॉल में नामित पैरामीटर का उपयोग करें
- कोई डुप्लिकेट कोड नहीं; इसे लिखने से पहले जांचें कि क्या कुछ लॉजिक पहले से लिखा गया है
- स्पष्ट उद्देश्य के बिना अनावश्यक रैपर फंक्शन से बचें
- जटिल डेटा स्ट्रक्चर से निपटते समय जेनेरिक कलेक्शन की तुलना में स्ट्रांगली-टाइप्ड कलेक्शन को प्राथमिकता दें
- गैर-तुच्छ डेटा स्ट्रक्चर के लिए उचित टाइप परिभाषाएँ बनाने पर विचार करें
- सरल डेटा संरचनाओं के लिए नेटिव टाइप ठीक हैं, लेकिन जटिल लोगों के लिए उचित मॉडल का उपयोग करें
- जहां संभव हो, अनटाइप्ड वेरिएबल और जेनेरिक टाइप का उपयोग करने से बचें
- फंक्शन परिभाषाओं में कभी भी डिफॉल्ट पैरामीटर वैल्यू का उपयोग न करें - सभी पैरामीटर को स्पष्ट बनाएं
</cursorrules_code_style>

<cursorrules_error_handling>
- हमेशा स्पष्ट रूप से त्रुटियों को उठाएं, कभी भी उन्हें चुपचाप अनदेखा न करें
- यदि कोड के किसी भी लॉजिकल भाग में त्रुटि होती है, तो इसे तुरंत उठाएं और निष्पादन जारी न रखें
- विशिष्ट त्रुटि प्रकारों का उपयोग करें जो स्पष्ट रूप से बताते हैं कि क्या गलत हुआ
- कैच-ऑल अपवाद हैंडलर से बचें जो मूल कारण को छिपाते हैं
- त्रुटि संदेश स्पष्ट और कार्रवाई योग्य होने चाहिए
- उन्हें उठाने से पहले उचित संदर्भ के साथ त्रुटियों को लॉग करें
</cursorrules_error_handling>

<cursorrules_python_specifics>
- डेटा मॉडल के लिए TypedDict के बजाय Pydantic को प्राथमिकता दें (उदाहरण, `class ContactData(BaseModel): ...`)
- `Any` और `@staticmethod` से बचें
- जब संभव हो तो `requirements.txt` के बजाय `pyproject.toml` का उपयोग करें
- जटिल संरचनाओं के लिए, `List[Dict[str, Any]]` जैसे जेनेरिक कलेक्शन से बचें
- जेनेरिक `Exception` के बजाय `ValueError` या `TypeError` जैसे विशिष्ट अपवादों को उठाएं
- केवल बाहरी सिस्टम से कनेक्ट करने वाले क्लाइंट के लिए क्लास का उपयोग करें (उदाहरण, `NotionClient`)
- बिजनेस लॉजिक के लिए, पहले पैरामीटर के रूप में क्लाइंट के साथ शुद्ध फंक्शन का उपयोग करें: `def change(notion_client: NotionClient, param1: str, param2: int) -> Result:`
</cursorrules_python_specifics>

<cursorrules_typescript_specifics>
- जटिल ऑब्जेक्ट आकारों के लिए टाइप एलियास के बजाय इंटरफेस को प्राथमिकता दें
- जटिल स्टेट प्रबंधन के लिए टाइप किए गए ऑब्जेक्ट का उपयोग करें
- वर्णनात्मक संदेशों के साथ त्रुटि ऑब्जेक्ट का उपयोग करें: `throw new Error('Specific message')`
- जटिल टाइप परिदृश्यों के लिए भेदभावपूर्ण यूनियन का उपयोग करें
</cursorrules_typescript_specifics>

<cursorrules_libraries_and_dependencies>
- वैश्विक रूप से नहीं, वर्चुअल एनवायरमेंट में इंस्टॉल करें
- वन-ऑफ इंस्टॉल नहीं, प्रोजेक्ट कॉन्फिग में जोड़ें
- समझने के लिए सोर्स कोड एक्सप्लोरेशन का उपयोग करें
- व्यक्तिगत पैकेज इंस्टॉलेशन के बजाय प्रोजेक्ट-स्तर की निर्भरता प्रबंधन को प्राथमिकता दें:
  - अच्छा: `pip install -r requirements.txt`
  - बेहतर: आधुनिक Python पैकेजिंग के साथ `pyproject.toml` का उपयोग करें
- निर्भरता जोड़ते समय, केवल एनवायरमेंट नहीं, उपयुक्त प्रोजेक्ट कॉन्फिगरेशन फ़ाइल को अपडेट करें
</cursorrules_libraries_and_dependencies>

<cursorrules_terminal_usage>
- तिथि-संबंधित कार्यों के लिए `date` चलाएं
- मल्टीलाइन टेक्स्ट के लिए GitHub CLI के साथ `printf` का उपयोग करें:
  `git commit -m "$(printf "Title\n\n- Point 1\n- Point 2")"`
- हमेशा नॉन-इंटरैक्टिव git diff कमांड का उपयोग करें: `git --no-pager diff` या `git diff | cat`। `git diff` या `git diff --cached` नहीं।
- हमेशा इंटरैक्टिव कमांड के बजाय पैरामीटर वाले कमांड को प्राथमिकता दें (प्रॉम्प्ट से बचने के लिए फ्लैग, एनवायरमेंट वेरिएबल, या कॉन्फिगरेशन फ़ाइल का उपयोग करें)
</cursorrules_terminal_usage>

<cursorrules_planning_practices>
- उपयोगकर्ता आपसे फीचर इम्प्लीमेंटेशन के लिए एक योजना बनाने के लिए कह सकता है
- आपको एक tmp डायरेक्टरी बनानी चाहिए
- आपको tmp डायरेक्टरी में फीचर प्लान के साथ एक मार्कडाउन फ़ाइल बनानी चाहिए
- इस फीचर प्लान फ़ाइल में निम्नलिखित सेक्शन होने चाहिए:
  1. फीचर से संबंधित वर्तमान स्थिति का अवलोकन
  2. फीचर की अंतिम स्थिति का अवलोकन
  3. सभी फ़ाइलों की सूची जिन्हें क्या बदलना है, उसके साथ टेक्स्ट विवरण (कोड नहीं)
  4. 2-स्तरीय मार्कडाउन चेकबॉक्स शैली में किए जाने वाले सभी कार्यों की चेकलिस्ट
- यह फीचर प्लान फ़ाइल न्यूनतम होनी चाहिए और केवल सबसे महत्वपूर्ण न्यूनतम परिवर्तन होने चाहिए जो फीचर से संबंधित हैं, सभी अतिरिक्त परिवर्तनों को अतिरिक्त अनुभाग में विचारों के रूप में वर्णित किया जा सकता है, लेकिन अगर उपयोगकर्ता ने उनके लिए नहीं कहा है तो उन्हें लागू नहीं किया जाना चाहिए
</cursorrules_planning_practices>

<cursorrules_repository_practices>
- अगर रिपॉजिटरी नियम फ़ाइल नहीं है तो `README.md` पढ़ें
- काम करने से पहले प्रोजेक्ट का सारांश बनाएं
</cursorrules_repository_practices>

<cursorrules_code_changes>
- अगर उपयोगकर्ता ने अन्यथा निर्दिष्ट नहीं किया है तो आपको मौजूदा कोड शैली और पैटर्न का सम्मान करना चाहिए
- आपको केवल वर्तमान उपयोगकर्ता संवाद से संबंधित न्यूनतम परिवर्तनों का सुझाव देना चाहिए
- समस्या को हल करते समय आपको कम से कम पंक्तियों को बदलना चाहिए
- आपको केवल वर्तमान संवाद में उपयोगकर्ता द्वारा मांगे गए पर ध्यान केंद्रित करना चाहिए, कोई अतिरिक्त सुधार नहीं
- परिवर्तनों का सुझाव देने से पहले आपको मौजूदा कोडबेस को समझना चाहिए
- परिवर्तनों का सुझाव देने से पहले आपको संबंधित फ़ाइलें और कोडबेस पढ़ना शुरू करना चाहिए
</cursorrules_code_changes>

</cursorrules_instructions_to_the_dialog>

वीडियो ट्यूटोरियल: पूर्ण कर्सर आईडीई नियम कार्यान्वयन देखें

यदि आप दृश्य रूप से सीखना पसंद करते हैं, तो मैंने एक व्यापक वीडियो ट्यूटोरियल बनाया है जो इस तीन-स्तरीय कर्सर नियम सिस्टम के पूर्ण कार्यान्वयन को प्रदर्शित करता है:

वीडियो में शामिल है:

• कर्सर आईडीई सेटिंग्स में वैश्विक कर्सर नियम सेट करना
• रिपॉजिटरी-विशिष्ट नियम फ़ाइलें बनाना: नई विधि .cursor/index.mdc (Rule Type "Always") और पुराती विधि .cursorrules (legacy)
• विशेष कार्यों के लिए संदर्भ-जागरूक .cursor/*.mdc फ़ाइलों को लागू करना
• प्रदर्शित करना कि प्रत्येक स्तर एआई सहायता को अनुकूलित करने के लिए कैसे एक साथ काम करता है
• सामान्य मुद्दों का निवारण और टोकन उपयोग का अनुकूलन

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