CLAUDE.md उपयोग मार्गदर्शिका: अपने प्रोजेक्ट के नियमों को इसकी मेमोरी में लिखें

📚 श्रृंखला नेविगेशन: पिछला लेख 17 चित्र और मल्टीमॉडल आपको सिखाता है कि स्क्रीनशॉट और त्रुटि छवियों को सीधे Claude को कैसे दें। यह लेख एक अलग दिशा लेता है—प्रोजेक्ट के "नियमों" को एक बार में इसकी मेमोरी में लिखें, ताकि यह हर बार काम शुरू करने पर स्वचालित रूप से उनका पालन करे, और आपको रोज़ उन्हें दोहराना न पड़े।

कहा जाता है कि CLAUDE.md जितना विस्तृत हो, उतना अच्छा है। लेकिन सच कहें तो, सबसे बेकार CLAUDE.md वह होता है जिसमें तीन सौ पंक्तियाँ होती हैं, पर Claude उनमें से एक भी नहीं सुनता।

कल्पना करें कि आप एक ऐसा प्रोजेक्ट संभाल रहे हैं जिसमें पूर्ववर्ती व्यक्ति द्वारा छोड़ा गया CLAUDE.md है, जो बहुत लंबा-चौड़ा है: कंपनी की पृष्ठभूमि, उत्पाद का विज़न, टीम का परिचय, तकनीकी चयन का इतिहास... आपको दूसरी स्क्रीन पर स्क्रॉल करने के बाद ही एक उपयोगी वाक्य मिलता है "npm के बजाय pnpm का उपयोग करें"। परिणाम? Claude अभी भी आपको बिना किसी हिचकिचाहट के npm install देता है।

समस्या यह नहीं है कि यह बात नहीं मानता, बल्कि यह है कि वह नियम दो सौ पंक्तियों के बकवास में दब गया है, और इसका ध्यान बहुत पहले ही भटक गया था।

CLAUDE.md (Claude की प्रोजेक्ट मेमोरी फ़ाइल) एक ऐसी चीज़ है, जो यदि अच्छी तरह से लिखी जाए, तो एक जादुई उपकरण है, लेकिन यदि खराब तरीके से लिखी जाए, तो एक बोझ बन जाती है—यह हर सत्र में आपकी संदर्भ विंडो (context window) घेरती है। यह जितना अधिक फूला हुआ होगा, वास्तविक काम के लिए उतनी ही कम जगह बचेगी। आज, हम इस मामले को विस्तार से समझेंगे: इसके कितने स्तर हैं, क्या लिखना चाहिए, क्या नहीं लिखना चाहिए, अन्य फ़ाइलों को कैसे संदर्भित करना है, और इसे सुव्यवस्थित कैसे बनाए रखना है।

इस लेख को पढ़ने के बाद, आप जानेंगे:

• CLAUDE.md के तीन स्तर (उपयोगकर्ता स्तर / प्रोजेक्ट स्तर / उपनिर्देशिका स्तर) क्या प्रबंधित करते हैं और उनका लोडिंग क्रम क्या है
• एक "क्या लिखें vs क्या न लिखें" चेकलिस्ट, जो शुरुआती लोगों द्वारा बकवास भरने की 90% गलतियों से बचाती है
• अन्य फ़ाइलों को संदर्भित करने के लिए @ सिंटैक्स का सही उपयोग, और संदर्भ (context) पर इसका वास्तविक मूल्य
• किसी सत्र में अस्थायी रूप से मेमोरी जोड़ने का आधिकारिक तरीका, साथ ही टेम्पलेट के रूप में एक "अच्छा vs बुरा" तुलना चार्ट

ℹ️ यह लेख केवल इस बात पर केंद्रित है कि CLAUDE.md फ़ाइल को कैसे अच्छी तरह से लिखा जाए और इसे कैसे बनाए रखा जाए। /init वन-क्लिक जेनरेशन के बारे में 12 "प्रोजेक्ट इनिशियलाइज़ेशन" में चर्चा की गई थी। व्यापक ऑटो-मेमोरी (auto-memory) तंत्र पर विशेष रूप से 25 "मेमोरी सिस्टम" में चर्चा की जाएगी।

---

01 पहले समझें: CLAUDE.md आखिर क्या है

सबसे पहले निष्कर्ष: CLAUDE.md आपके द्वारा Claude को लिखा गया एक "स्थायी निर्देश" है। हर बार जब यह एक सत्र शुरू करता है, तो यह इसे पढ़ता है और इसे अपने दिमाग में प्रोजेक्ट पृष्ठभूमि के रूप में रखता है।

इसकी आवश्यकता क्यों है? क्योंकि हर Claude Code सत्र एक खाली स्लेट से शुरू होता है—पिछली बार जब आपने ईमानदारी से समझाया था "pnpm का उपयोग करें, legacy निर्देशिका को न छुएं, और परीक्षण इस तरह चलाएं", तो उसे इस बार कुछ भी याद नहीं रहता है। बिना CLAUDE.md के, आपको हर बार फिर से सब कुछ समझाना होगा। क्या यह कष्टप्रद नहीं है?

तुलना: नए कर्मचारियों के लिए एक ऑनबोर्डिंग मैनुअल। जब कोई नया कर्मचारी पहले दिन आता है, तो आप उसके पास खड़े होकर पूरे दिन नियम नहीं बताते हैं। आप उसे एक मैनुअल देते हैं: प्रोजेक्ट क्या करता है, कोड कैसे सबमिट करना है, और कौन से लैंडमाइंस से बचना है। वह इसे पढ़ता है और काम शुरू कर देता है। CLAUDE.md Claude का ऑनबोर्डिंग मैनुअल है—और यह वह प्रकार है जिसे वह हर दिन काम करने से पहले फिर से पढ़ता है।

लेकिन यहाँ एक महत्वपूर्ण समझ है, जिसे आधिकारिक दस्तावेज़ीकरण बहुत स्पष्ट रूप से बताता है:

CLAUDE.md सामग्री सिस्टम प्रॉम्प्ट (system prompt) के हिस्से के बजाय सिस्टम प्रॉम्प्ट के बाद उपयोगकर्ता संदेश के रूप में पारित की जाती है। Claude इसे पढ़ता है और इसका पालन करने का प्रयास करता है, लेकिन कड़ाई से पालन करने की कोई गारंटी नहीं है।

सरल शब्दों में: CLAUDE.md एक "मजबूत सुझाव" है, "लोहे का नियम" नहीं। यह Claude के व्यवहार को आकार देता है, लेकिन यह एक सख्त प्रवर्तन परत (enforcement layer) नहीं है। इसलिए, आप जितना अधिक विशिष्ट और संक्षिप्त लिखेंगे, यह उतनी ही अधिक मजबूती से उसका पालन करेगा। किसी खतरनाक ऑपरेशन को 100% रोकने के लिए इस पर निर्भर रहना? वह Hook का काम है, CLAUDE.md का नहीं—इन दोनों के बीच श्रम का विभाजन बाद के अध्यायों में समझाया जाएगा।

इसमें कब सामग्री जोड़नी चाहिए? आधिकारिक तौर पर कुछ बहुत व्यावहारिक संकेत दिए गए हैं:

• Claude दूसरी बार वही गलती करता है — इसका मतलब है कि इसे लिखकर पक्का करना होगा
• इस सत्र में आपने फिर से वह सुधार टाइप किया जो आपने पिछले सत्र में टाइप किया था
• कोड समीक्षा के दौरान, आपने पाया कि उसे पहले से ही इस कोडबेस के किसी विशिष्ट कन्वेंशन को जानना चाहिए था
• नए टीम के साथियों को जल्दी से शुरू करने के लिए उसी पृष्ठभूमि की आवश्यकता होती है

💡 एक वाक्य में सारांश: CLAUDE.md ऑनबोर्डिंग मैनुअल है जिसे Claude को हर बार काम शुरू करने से पहले पढ़ना चाहिए, "लोहे के नियम" के बजाय "मजबूत सुझाव" स्तर। जितना अधिक विशिष्ट लिखा होगा, उतना ही अधिक उपयोगी होगा।

---

02 तीन स्तर: कौन वैश्विक प्रबंधन करता है, कौन एकल प्रोजेक्ट का प्रबंधन करता है

CLAUDE.md की केवल एक प्रति नहीं है। इसे कई स्थानों पर रखा जा सकता है, बड़े से लेकर छोटे दायरे तक। शुरुआती लोग अक्सर यहाँ भ्रमित हो जाते हैं, चलिए इसे एक बार में साफ़ करते हैं।

आधिकारिक दस्तावेज़ों के अनुसार, आमतौर पर तीन स्तरों का उपयोग किया जाता है (प्लस एक स्थानीय संस्करण):

स्तर	कहाँ रखें	कितना बड़ा दायरा	क्या यह git में जाता है
उपयोगकर्ता स्तर	~/.claude/CLAUDE.md	इस मशीन पर आपके सभी प्रोजेक्ट	नहीं, विशुद्ध रूप से व्यक्तिगत पसंद
प्रोजेक्ट स्तर	./CLAUDE.md या ./.claude/CLAUDE.md	वर्तमान प्रोजेक्ट	✅ हाँ, टीम साझाकरण
उपनिर्देशिका स्तर	किसी भी उपनिर्देशिका/CLAUDE.md	जब Claude उस निर्देशिका में फ़ाइल पढ़ता है तभी लोड होता है	✅ हाँ, मल्टी-मॉड्यूल रिपॉजिटरी के लिए उपयुक्त
स्थानीय स्तर (संस्करण)	./CLAUDE.local.md	वर्तमान प्रोजेक्ट, केवल आपके लिए	❌ .gitignore में जोड़ें

एक "होस्टेड पॉलिसी लेयर" भी है, जिसे IT एडमिनिस्ट्रेटर सिस्टम डायरेक्टरी (macOS के लिए /Library/Application Support/ClaudeCode/CLAUDE.md) में परिनियोजित करते हैं, जो उपयोगकर्ता स्तर से पहले लोड होती है और व्यक्तियों द्वारा इसे बाहर नहीं किया जा सकता है। व्यक्तिगत उपयोगकर्ताओं को आमतौर पर इसका सामना नहीं करना पड़ता है, इसलिए इसे इस लेख में छोड़ दिया गया है; एंटरप्राइज़ परिदृश्यों के लिए आधिकारिक दस्तावेज़ देखे जा सकते हैं।

श्रम का विभाजन कैसे करें? एक वाक्य याद रखें: व्यक्तिगत आदतें उपयोगकर्ता स्तर पर रखें, टीम नियम प्रोजेक्ट स्तर पर रखें।

• उपयोगकर्ता स्तर (~/.claude/CLAUDE.md): क्रॉस-प्रोजेक्ट सामान्य व्यक्तिगत प्राथमिकताएं रखें। उदाहरण के लिए "हिंदी में उत्तर दें", "सीधे शुरू करने से पहले कोड बदलने के लिए अपने विचार साझा करें", "अंग्रेजी में कमिट संदेशों का उपयोग करें"। इनका किसी विशिष्ट प्रोजेक्ट से कोई लेना-देना नहीं है, ये "आपकी" आदतें हैं, इसलिए ये सभी प्रोजेक्ट्स पर लागू होती हैं और किसी भी प्रोजेक्ट के git में नहीं जाती हैं।
• प्रोजेक्ट स्तर (./CLAUDE.md): ऐसे नियम रखें जो इस प्रोजेक्ट के लिए विशिष्ट हों और पूरी टीम को उनका पालन करना चाहिए। टेक स्टैक, बिल्ड कमांड, डायरेक्टरी कन्वेंशन, नो-मॉडिफाई सूचियां। यह वर्ज़न कंट्रोल में कोड के साथ जाता है, और जब नए सहकर्मी इसे क्लोन करते हैं, तो वे इन विशिष्टताओं के साथ आते हैं।
• उपनिर्देशिका स्तर: केवल बड़ी रिपॉजिटरी में ही उपयोगी है। उदाहरण के लिए, फ्रंट-एंड निर्देशिका में एक फ्रंट-एंड विशिष्ट फ़ाइल रखें, और बैक-एंड निर्देशिका में एक बैक-एंड विशिष्ट फ़ाइल रखें। यह सामान्य रूप से लोड नहीं होती है। केवल तभी जब Claude वास्तव में उस निर्देशिका में फ़ाइलों को पढ़ता है, वह उस CLAUDE.md को आसानी से ले आता है—संदर्भ (context) बचाता है।

तुलना अभी भी ऑनबोर्डिंग मैनुअल है: उपयोगकर्ता स्तर = आपकी व्यक्तिगत कार्य आदत पुस्तिका (आप इसे तब भी अपने साथ ले जाते हैं जब आप कंपनी बदलते हैं); प्रोजेक्ट स्तर = इस कंपनी द्वारा जारी कर्मचारी मैनुअल (जब आप छोड़ते हैं तो आप इसे वापस कर देते हैं); उपनिर्देशिका स्तर = किसी विशिष्ट विभाग के भीतर अतिरिक्त नियम (केवल तभी जारी किए जाते हैं जब आप उस विभाग में स्थानांतरित होते हैं)।

एक सामान्य उपयोगकर्ता-स्तरीय कॉन्फ़िगरेशन का उदाहरण: ~/.claude/CLAUDE.md में यह वाक्य रखें "जब कई कार्यान्वयन विकल्प हों, तो मुझे चुनने के लिए विकल्प सूचीबद्ध करें, मेरे लिए चुपचाप निर्णय न लें"। यह आपके हर प्रोजेक्ट के लिए सही है, इसलिए इसे उपयोगकर्ता स्तर पर रखना सबसे आसान है—इसे एक बार सेट करने के बाद, आपको इस वाक्य को किसी नए प्रोजेक्ट में फिर से समझाने की आवश्यकता नहीं है।

💡 एक वाक्य में सारांश: व्यक्तिगत आदतें उपयोगकर्ता स्तर (~/.claude/CLAUDE.md) पर लिखें, टीम के नियम प्रोजेक्ट स्तर (./CLAUDE.md git में) पर लिखें, और बड़ी रिपॉजिटरी के लिए मॉड्यूल द्वारा विभाजित करने के लिए उपनिर्देशिका स्तर का उपयोग करें।

---

03 लोडिंग क्रम: प्रोजेक्ट स्तर "बाद में बोलना अधिक प्रभावी" क्यों है

पिछले अनुभाग ने तीन स्तरों को सूचीबद्ध किया। जब वे एक ही समय में मौजूद हों, तो अंतिम निर्णय किसका होता है? यह एक और आम गलत धारणा है जिसे स्पष्ट करने की आवश्यकता है।

आधिकारिक नियम: सबसे व्यापक दायरे से सबसे विशिष्ट दायरे तक क्रम में लोड करें। आपकी प्रारंभ निर्देशिका (startup directory) के जितने करीब निर्देश होगा, उसे उतनी ही देर से पढ़ा जाएगा।

यह कैसे क्रमबद्ध है? Claude Code आपके वर्तमान निर्देशिका से शुरू होता है और ऊपर जाता है। रास्ते में प्रत्येक स्तर पर यदि CLAUDE.md है, तो उसे एकत्र किया जाता है, और अंत में उन्हें संदर्भ (context) के एक पूरे टुकड़े में जोड़ दिया जाता है। क्रम मोटे तौर पर इस प्रकार है:

उपयोगकर्ता स्तर ~/.claude/CLAUDE.md
        ↓ (पहले पढ़ें)
(निर्देशिका ट्री में उच्च) मूल निर्देशिका CLAUDE.md
        ↓
प्रोजेक्ट रूट ./CLAUDE.md
        ↓ (बाद में पढ़ें, आपके सबसे करीब)
उपनिर्देशिका CLAUDE.md (केवल तभी जोड़ा जाता है, जब Claude उस निर्देशिका में फ़ाइलों को पढ़ता है)

दो मुख्य बिंदुओं पर ध्यान दें, दोनों आधिकारिक दस्तावेज़ों से:

सबसे पहले, पाई गई सभी फ़ाइलें "संयोजित" (concatenated) हैं, "ओवरराइट" (overwritten) नहीं। वे सभी संदर्भ में जाती हैं, यह नहीं कि बाद वाले पहले वालों की जगह ले लेते हैं। इसलिए, उपयोगकर्ता स्तर और प्रोजेक्ट स्तर एक ही समय में प्रभावी होते हैं। ऐसा कोई मामला नहीं है कि "प्रोजेक्ट स्तर सेट होने पर उपयोगकर्ता स्तर अमान्य हो जाता है"।

दूसरा, कार्य निर्देशिका के करीब के निर्देश "अंतिम पढ़े जाते हैं"। जब दो नियम टकराते हैं—उदाहरण के लिए, उपयोगकर्ता स्तर कहता है "स्ट्रिंग्स के लिए सिंगल कोट्स का उपयोग करें" और प्रोजेक्ट स्तर कहता है "डबल कोट्स का उपयोग करें"—करीब वाला प्रोजेक्ट स्तर, क्योंकि यह बाद में बोलता है, आमतौर पर अधिक प्रमुख होता है। सीधे शब्दों में कहें तो, प्रोजेक्ट नियम आपकी व्यक्तिगत आदतों को ओवरराइड कर सकते हैं, जो ठीक वही प्रभाव है जो टीम सहयोग चाहता है।

यह आरेख तीन स्तरों को ऊपर से नीचे तक स्टैक करता है: उपयोगकर्ता स्तर (सभी प्रोजेक्ट्स का प्रबंधन करता है, पहले पढ़ा जाता है), प्रोजेक्ट स्तर (वर्तमान प्रोजेक्ट, git में प्रवेश करता है), उपनिर्देशिका स्तर (कोड के सबसे करीब, संघर्ष की स्थिति में हावी होता है); दाईं ओर का तीर "ऊपर से नीचे" लोडिंग क्रम को इंगित करता है, और नीचे का लोहे का नियम बताता है—तीनों स्तरों को एक साथ जोड़ा गया है, ओवरराइट नहीं किया गया है। कोड के जितना करीब होगा, उसे उतनी ही देर से पढ़ा जाएगा, और उसी का निर्णय अंतिम होगा।

यहाँ एक आम गलत धारणा को भी ठीक करना होगा। इंटरनेट पर कई ट्यूटोरियल प्राथमिकता को "प्रोजेक्ट लोकल → प्रोजेक्ट रूट → उपनिर्देशिका → ग्लोबल" के रूप में लिखते हैं। यह आधिकारिक लोडिंग दिशा के विपरीत है। इस कथन से गुमराह होना बहुत आसान है, लेकिन यदि आप आधिकारिक दस्तावेज़ों को देखें, तो यह स्पष्ट है: आधिकारिक बयान स्पष्ट रूप से बताता है कि लोडिंग "सबसे व्यापक दायरे से सबसे विशिष्ट दायरे तक" होती है, और प्रोजेक्ट निर्देश उपयोगकर्ता निर्देशों के बाद दिखाई देते हैं। आधिकारिक जानकारी का पालन करें और इसे उल्टा याद न रखें।

एक और विचारशील विवरण: /compact (संवाद को संपीड़ित करना) के बाद प्रोजेक्ट रूट में CLAUDE.md स्वचालित रूप से डिस्क से फिर से पढ़ा जाएगा, यह खो नहीं जाएगा। लेकिन उपनिर्देशिकाओं में नेस्टेड CLAUDE.md स्वचालित रूप से फिर से इंजेक्ट नहीं किए जाएंगे, उन्हें तब तक इंतजार करना होगा जब तक कि Claude अगली बार वापस आने के लिए उस निर्देशिका में फ़ाइलों को न पढ़ ले। इसलिए, महत्वपूर्ण नियमों को प्रोजेक्ट रूट में रखने का प्रयास करें, उन्हें बहुत गहरा न छिपाएं।

💡 एक वाक्य में सारांश: मल्टी-लेवल CLAUDE.md को ओवरराइट नहीं किया जाता है बल्कि संयोजित किया जाता है। कार्य निर्देशिका के जितने करीब होगा, उसे उतनी ही देर से पढ़ा जाएगा, और संघर्ष की स्थिति में उतना ही हावी होगा, इसलिए प्रोजेक्ट नियम व्यक्तिगत आदतों को ओवरराइड कर सकते हैं—आधिकारिक लोडिंग दिशा को उल्टा याद न रखें।

---

04 क्या लिखें vs क्या न लिखें

यह अनुभाग पूरे लेख की जीवनरेखा है। यदि CLAUDE.md अच्छी तरह से नहीं लिखा गया है, तो 90% समय इसका कारण यह होता है कि "जो स्पष्ट रूप से लिखा जाना चाहिए था वह नहीं लिखा गया, और जो नहीं लिखा जाना चाहिए था उसका ढेर लगा दिया गया।"

पहले बात करते हैं कि क्या लिखा जाना चाहिए—आधिकारिक बयान स्पष्ट है: "वे तथ्य लिखें जिन्हें Claude को प्रत्येक सत्र में बनाए रखना चाहिए।" सूची में अनुवादित, ये पाँच श्रेणियां हैं:

श्रेणी	विशेष रूप से क्या लिखें	उदाहरण
प्रोजेक्ट अवलोकन	एक वाक्य में बताएं कि यह प्रोजेक्ट क्या है	"FastAPI पर आधारित ऑर्डर मैनेजमेंट बैकएंड"
टेक स्टैक	भाषाएं, फ्रेमवर्क, डेटाबेस, प्रमुख उपकरण	"Python 3.11 / PostgreSQL / pytest"
सामान्य आदेश	टेस्ट, बिल्ड और चेक कैसे चलाएं	uv run pytest、uv run ruff check .
कोड कन्वेंशन	शैली, नामकरण, अनिवार्य लेखन विनिर्देश	"फ़ंक्शन में टाइप एनोटेशन होना चाहिए", "स्ट्रिंग्स के लिए डबल कोट्स का उपयोग करें"
स्पष्ट "क्या न करें"	लैंडमाइंस, गैर-परिवर्तनीय फ़ाइलें, ऐसे ऑपरेशन जिनके बारे में पहले पूछना चाहिए	"migrations/ में मौजूदा फ़ाइलों को संशोधित न करें"

इनमें से, सामान्य आदेशों का सबसे अधिक बार संदर्भ दिया जाता है—Claude अंधाधुंध अनुमान लगाने या गलत आदेशों का उपयोग करने से बचने के लिए परीक्षण और निर्माण चलाने से पहले यहां आदेशों को देखेगा। निषेध सूची इसे "स्मार्ट लेकिन परेशानी पैदा करने वाला" होने से रोकने के लिए एक रेलिंग है: कौन सी निर्देशिकाएं विरासत कोड (legacy code) हैं जिन्हें केवल पढ़ा जा सकता है लेकिन बदला नहीं जा सकता है, कौन सी फ़ाइलें संशोधित करने से पहले आपको सूचित की जानी चाहिए, और कौन सी प्रमुख फ़ाइलें सामग्री आउटपुट करने से निषिद्ध हैं।

अब बात करते हैं क्या न लिखें, जो शुरुआती लोगों के लिए एक प्रमुख आपदा क्षेत्र है:

• ❌ लंबी पृष्ठभूमि: कंपनी का परिचय, उत्पाद का विज़न, तकनीकी चयन का ऐतिहासिक मूल—Claude कोड लिखने के लिए इनका उपयोग नहीं कर सकता है, यह केवल संदर्भ (context) लेता है।
• ❌ पुरानी जानकारी: पैकेज मैनेजर बदल गया है लेकिन CLAUDE.md अपडेट नहीं हुआ है, और इसमें अभी भी npm लिखा है, जो इसे गुमराह करेगा।
• ❌ चीजें जो कोड देखकर जानी जा सकती हैं: डायरेक्टरी संरचना में प्रत्येक फ़ाइल क्या करती है, इसे न दोहराएं, और पहले से ही ESLint कॉन्फ़िगरेशन द्वारा परिभाषित कोड शैली की प्रतिलिपि न बनाएं। Claude स्वयं कोड पढ़ेगा, दोहराना बस जगह बर्बाद करना है।

इस मामले पर आधिकारिक रुख बहुत स्पष्ट है, और इसमें विशेष रूप से लाल रेखाएं (red lines) दी गई हैं:

प्रत्येक CLAUDE.md फ़ाइल का लक्ष्य 200 पंक्तियों के अंतर्गत होना चाहिए। लंबी फ़ाइलें अधिक संदर्भ की खपत करती हैं और अनुपालन कम करती हैं।

200 पंक्तियाँ इतनी महत्वपूर्ण क्यों हैं? क्योंकि CLAUDE.md आपके संवाद (conversation) के साथ एक ही संदर्भ विंडो (context window) के लिए प्रतिस्पर्धा करता है। यदि आप तीन सौ पंक्तियों की बकवास भरते हैं, तो इसका अर्थ है कि शुरुआत में ही एक बड़ा कार्यक्षेत्र (workspace) घेर लिया गया है, और वास्तविक कार्यों के लिए छोड़ी गई जगह सिकुड़ जाती है—और महत्वपूर्ण नियम बकवास में दब जाते हैं, ध्यान भटक जाता है, और अनुपालन बढ़ने के बजाय घट जाता है। यही उस "तीन सौ पंक्तियों, जिसे कोई नहीं सुनता" बीमारी का मूल कारण है जिसका उल्लेख शुरुआत में किया गया था।

एक आसान और अचूक तरीका है: प्रत्येक नियम लिखने से पहले, स्वयं से पूछें "क्या Claude इसे केवल कोड देखकर जान सकता है? यदि हाँ, तो इसे हटा दें।" अकेले इस चाकू से, एक हैंडओवर प्रोजेक्ट का CLAUDE.md तीन सौ से अधिक पंक्तियों से अस्सी पंक्तियों तक कट सकता है, और जो बचा है वह सभी कठिन बाधाएं हैं जिनका वह अनुमान नहीं लगा सकता है—काटने के बाद, पैकेज मैनेजर का गलत उपयोग करने की संख्या स्पष्ट रूप से कम हो जाएगी।

💡 एक वाक्य में सारांश: "तथ्य जो प्रत्येक सत्र में याद रखे जाने चाहिए" (अवलोकन / टेक स्टैक / आदेश / कन्वेंशन / निषिद्ध क्षेत्र) लिखें, वह सब कुछ हटा दें जो Claude कोड देखकर स्वयं निकाल सकता है, और पूरे पाठ को 200 पंक्तियों के नीचे रखें।

---

05 अन्य फ़ाइलों का संदर्भ देना: @ सिंटैक्स और इसकी कीमत

कभी-कभी आपके प्रोजेक्ट में पहले से ही रेडीमेड स्पेसिफिकेशन दस्तावेज़ होते हैं—एक API डिज़ाइन गाइड, एक डेटाबेस कन्वेंशन। सामग्री को CLAUDE.md में कॉपी करने की आवश्यकता नहीं है, बस संदर्भ के लिए @ सिंटैक्स का उपयोग करें।

इसे लिखना बहुत सरल है, CLAUDE.md में कहीं भी @ प्लस पथ (path) लिखें:

प्रोजेक्ट अवलोकन के लिए, कृपया @README देखें। उपलब्ध आदेशों के लिए, @package.json देखें।

# अन्य निर्देश
- git वर्कफ़्लो @docs/git-instructions.md

जब Claude CLAUDE.md पढ़ता है, तो यह संदर्भित फ़ाइल सामग्री का विस्तार करेगा और उन्हें एक साथ संदर्भ (context) में लोड करेगा। आधिकारिक तौर पर निर्दिष्ट किए गए कुछ विवरण, नुकसान से बचने के लिए याद रखें:

• सापेक्ष पथ (Relative paths) को "संदर्भ रखने वाली फ़ाइल" के सापेक्ष हल किया जाता है, आपकी कार्य निर्देशिका के सापेक्ष नहीं। इसे गलत समझना आसान है।
• निरपेक्ष पथ (Absolute paths) भी ठीक हैं; संदर्भित फ़ाइलें अन्य फ़ाइलों को भी संदर्भित कर सकती हैं, अधिकतम चार हॉप्स (hops) तक पुनरावर्ती रूप से (recursively)।
• जब पहली बार किसी आउट-ऑफ़-प्रोजेक्ट संदर्भ (out-of-project reference) का सामना करना पड़ता है, तो Claude Code आपको पुष्टि करने के लिए एक अनुमोदन बॉक्स पॉप अप करेगा जिसमें इन फ़ाइलों को सूचीबद्ध किया जाएगा; यदि आप मना करते हैं, तो यह संदर्भ हमेशा के लिए अक्षम हो जाएगा, और बॉक्स फिर पॉप अप नहीं होगा।

लेकिन यहाँ सबसे महत्वपूर्ण समझ है, जिस पर आधिकारिक तौर पर बार-बार जोर दिया गया है, और यह सबसे आसान गड्ढा भी है:

आयातित फ़ाइलें (Imported files) स्टार्टअप पर विस्तारित होती हैं और संदर्भ में लोड की जाती हैं। @path आयात में विभाजित करने से संगठन में मदद मिलती है, लेकिन संदर्भ कम नहीं होता है, क्योंकि आयातित फ़ाइलें स्टार्टअप पर लोड होती हैं।

सीधे शब्दों में कहें तो: @ संदर्भ "संगठन" है, "पैसे बचाना" नहीं। बहुत से लोग सोचते हैं कि सामग्री को बाहरी फ़ाइलों में विभाजित करके और CLAUDE.md मुख्य भाग को छोटा करके, संदर्भ को बचाया जाता है—गलत। संदर्भित फ़ाइलें अभी भी शुरुआत में पूरी तरह से विंडो में लोड होती हैं, और जो संदर्भ (context) लिया जाना चाहिए था वह बिल्कुल भी कम नहीं होता है। कल्पना करें कि एक 500-पंक्ति के स्पेसिफिकेशन को @ संदर्भ के साथ विभाजित किया गया है, यह सोचकर कि इसे पतला कर दिया गया है। परिणामस्वरूप, जब आप /context (संदर्भ उपयोग की जाँच करें) देखते हैं, तो एक भी टोकन कम नहीं हुआ है।

तो सिद्धांत यह है: @ संदर्भ का उपयोग संरचना को साफ़ करने और मनुष्यों के लिए बनाए रखने में आसान बनाने के लिए किया जाता है, लेकिन संदर्भ को बचाने के लिए, आपको "सामग्री को सुव्यवस्थित करने" या "पथ दायरा नियमों" (path scope rules) पर भरोसा करना होगा, फ़ाइलों को विभाजित करने पर नहीं। संदर्भित एकल फ़ाइल बहुत बड़ी नहीं होनी चाहिए, यदि यह बहुत बड़ी है, तो यह अभी भी एक ड्रैग होगी।

वैसे, एक संबंधित बिंदु: यदि आपके पास कुछ विशुद्ध रूप से व्यक्तिगत प्रोजेक्ट प्राथमिकताएं हैं जो git में नहीं जानी चाहिए (जैसे कि आपका स्थानीय सैंडबॉक्स URL, आपका पसंदीदा परीक्षण डेटा), तो उन्हें ./CLAUDE.md में न लिखें, उन्हें ./CLAUDE.local.md में लिखें, और फिर इसे .gitignore में जोड़ें। यह CLAUDE.md के साथ लोड होता है और बिल्कुल उसी तरह व्यवहार किया जाता है, सिवाय इसके कि इसे सबमिट नहीं किया जाएगा और यह टीम के साथियों को प्रभावित नहीं करेगा।

💡 एक वाक्य में सारांश: @पथ बाहरी दस्तावेज़ों को "स्पष्ट संरचना" के लिए लाता है, लेकिन संदर्भित सामग्री अभी भी पूरी तरह से संदर्भ में लोड होती है और टोकन नहीं बचाती है; यदि आप सहेजना चाहते हैं, तो आपको वास्तव में सामग्री को हटाना होगा; व्यक्तिगत प्राथमिकताओं को CLAUDE.local.md में रखें और gitignore करें।

---

06 रखरखाव: सत्र में जोड़ें, नियमित रूप से सुव्यवस्थित करें

CLAUDE.md कोई ऐसी चीज़ नहीं है जिसे एक बार लिख दिया जाए और फिर छोड़ दिया जाए। इसे प्रोजेक्ट के साथ बढ़ना चाहिए। यह खंड दो रखरखाव क्रियाओं के बारे में बताता है: अस्थायी रूप से कुछ कैसे जोड़ें, और नियमित रूप से कैसे पतला करें।

यदि आप सत्र के दौरान अस्थायी रूप से एक नियम जोड़ना चाहते हैं तो क्या करें

अक्सर ऐसा होता है: चैट करते समय, आपने Claude के एक वाक्य को सही किया, और सोचा "इस नियम का भविष्य में हर बार पालन किया जाना चाहिए, इसे लिखा जाना चाहिए।" सबसे आसान आधिकारिक तरीका—सीधे संवाद में इसे बताएं:

"डेटाबेस ऑपरेशंस को सर्विस लेयर (Service layer) के माध्यम से जाना चाहिए, सीधे रूट (route) में SQL न लिखें" वाले इस नियम को CLAUDE.md में जोड़ें।

Claude इसे CLAUDE.md फ़ाइल में लिखने में आपकी मदद करेगा। आप किसी भी समय /memory कमांड भी टाइप कर सकते हैं, और यह वर्तमान सत्र में लोड किए गए सभी CLAUDE.md, CLAUDE.local.md, और नियम फ़ाइलों को सूचीबद्ध करेगा। संपादक में खोलने के लिए क्लिक करें, और आप इसे मैन्युअल रूप से भी बदल सकते हैं। यदि आप चाहते हैं कि Claude स्वयं शब्द-चयन तय करे, तो पहली विधि का उपयोग करें; यदि आप शब्द-चयन को सटीक रूप से नियंत्रित करना चाहते हैं, तो इसे स्वयं संपादित करने के लिए /memory का उपयोग करें।

ℹ️ एक संस्करण अंतर अनुस्मारक: प्रारंभिक Claude Code में, इनपुट बॉक्स में # से शुरू होने वाला एक वाक्य टाइप करके मेमोरी जल्दी से जोड़ी जा सकती थी। नए संस्करण में, यह इंटरैक्शन बदल गया है—वर्तमान आधिकारिक दृष्टिकोण का पालन करें: या तो Claude को सीधे "इसे CLAUDE.md में जोड़ने" के लिए कहें, या इसे स्वयं संपादित करने के लिए /memory का उपयोग करें। यदि आप "xxx याद रखें" टाइप करते हैं, तो Claude डिफ़ॉल्ट रूप से इसे अपनी स्वयं की ऑटो-मेमोरी (auto-memory) में सहेज लेगा (जो 25 "मेमोरी सिस्टम" का विषय है); यदि आप स्पष्ट रूप से इसे CLAUDE.md में डालना चाहते हैं, तो बस "इसे CLAUDE.md में जोड़ें" पूरा वाक्य कहें।

नियमित रूप से सुव्यवस्थित करें, पुरानी और परस्पर विरोधी जानकारी को हटा दें

एक छिपा हुआ खतरा जिसका आधिकारिक तौर पर नाम लिया गया है: जब दो नियम एक-दूसरे के विपरीत होते हैं, तो Claude बेतरतीब ढंग से पालन करने के लिए एक को चुन सकता है। इसलिए आपको नियमित रूप से पीछे मुड़कर देखना चाहिए और पुराने और परस्पर विरोधी नियमों को साफ़ करना चाहिए। सुव्यवस्थित करने के ट्रिगर:

• पैकेज मैनेजर / बिल्ड टूल बदल दिया (पुराने आदेशों को हटा दिया जाना चाहिए, उन्हें रखना गुमराह करने वाला है)
• महत्वपूर्ण निर्भरताएँ जोड़ी या हटाई गईं
• नए प्रोग्रामिंग कन्वेंशन सेट किए (रास्ते में, जांचें कि क्या वे पुराने नियमों के साथ संघर्ष करते हैं)
• पाया कि CLAUDE.md चुपचाप 200 पंक्तियों से आगे बढ़ गया है

यह आंकने के लिए कि क्या कोई नियम अच्छा है, बस देखें कि क्या यह "गद्य" (prose) के बजाय एक "नियम" (rule) जैसा दिखता है। आधिकारिक तुलना बहुत व्यावहारिक है, मैंने इसे एक तालिका में संकलित किया है:

❌ अस्पष्ट गद्य (बेकार)	✅ विशिष्ट नियम (उपयोगी)
कोड अपेक्षाकृत साफ़ होना चाहिए	फ़ंक्शन 50 पंक्तियों से अधिक नहीं होना चाहिए, यदि यह अधिक हो जाता है, तो इसे विभाजित किया जाना चाहिए
परीक्षण लिखने का प्रयास करें	प्रत्येक नए जोड़े गए फ़ंक्शन में एक संबंधित यूनिट टेस्ट होना चाहिए
सुरक्षा पर ध्यान दें	उपयोगकर्ता इनपुट को डेटाबेस में क्वेरी करने से पहले sanitize() से गुजरना चाहिए
legacy निर्देशिका बहुत महत्वपूर्ण नहीं है	legacy/ निर्देशिका में किसी भी फ़ाइल को संशोधित करना निषिद्ध है
pnpm का उपयोग करना बेहतर है	निर्भरता प्रबंधन के लिए केवल pnpm का उपयोग करें, npm और yarn निषिद्ध हैं

बाईं ओर के शब्द कुछ न कहने के बराबर हैं—"साफ़", "प्रयास", "ध्यान" सभी व्यक्तिपरक शब्द हैं, जिन्हें Claude सत्यापित नहीं कर सकता है, और स्वाभाविक रूप से उन्हें स्थिर रूप से निष्पादित नहीं कर सकता है। दाईं ओर प्रत्येक आइटम विशिष्ट रूप से सत्यापन योग्य है: 50 पंक्तियाँ, परीक्षण होना चाहिए, एक निश्चित फ़ंक्शन पास करना चाहिए। आधिकारिक शब्द है "सत्यापित करने के लिए पर्याप्त विशिष्ट निर्देश लिखें"।

CLAUDE.md लिखते समय, आप एक कठिन आदत भी विकसित कर सकते हैं: प्रत्येक नियम लिखने के बाद, खुद से पूछें "क्या इस नियम का उल्लंघन होने पर एक नज़र में देखा जा सकता है?" यदि आप न्याय नहीं कर सकते, तो इसका मतलब है कि यह बहुत अस्पष्ट रूप से लिखा गया है, वापस जाएं और इसे विशिष्ट बनाएं।

💡 एक वाक्य में सारांश: यदि आप आसानी से एक नियम जोड़ना चाहते हैं, तो Claude को "इसे CLAUDE.md में जोड़ने" के लिए कहें या इसे संपादित करने के लिए /memory का उपयोग करें; पुराने और परस्पर विरोधी नियमों को नियमित रूप से हटा दें; अच्छे नियम "एक नज़र में सत्यापित होने वाले नियमों" की तरह दिखते हैं, न कि "साफ़, प्रयास" जैसे गद्य की तरह।

---

07 करके देखें: एक टॉय प्रोजेक्ट के लिए एक योग्य CLAUDE.md कॉन्फ़िगर करें

केवल बात करना और अभ्यास न करना बेकार है। नीचे हम "फ़ाइल बनाना → नियम लिखना → लोडिंग सत्यापित करना" की पूरी प्रक्रिया से गुजरने के लिए एक न्यूनतम प्रोजेक्ट का उपयोग करेंगे। साथ-साथ टाइप करें, यह पांच मिनट में हो जाएगा।

चरण 1: एक टॉय प्रोजेक्ट बनाएं और git प्रारंभ करें (Mac / Linux)

mkdir claude-md-demo
cd claude-md-demo
git init
echo 'def add(a, b):
    return a + b' > main.py

अपेक्षा: claude-md-demo निर्देशिका में एक main.py और एक .git निर्देशिका है। git को इनिशियलाइज़ करना इसलिए है ताकि यह CLAUDE.md वर्ज़न कंट्रोल (टीम शेयरिंग के लिए पूर्वापेक्षा) में प्रवेश कर सके।

चरण 2: एक सुव्यवस्थित प्रोजेक्ट-स्तरीय CLAUDE.md हाथ से लिखें

अपने पसंदीदा संपादक का उपयोग करके, प्रोजेक्ट रूट निर्देशिका में CLAUDE.md बनाएं, और निम्नलिखित में पेस्ट करें (ध्यान दें कि इसमें केवल कुछ पंक्तियाँ हैं—ऐसा ही एक अच्छा CLAUDE.md दिखना चाहिए):

# add-demo — प्रदर्शन के लिए एक न्यूनतम Python प्रोजेक्ट

केवल एक `add` फ़ंक्शन है, जिसका उपयोग यह प्रदर्शित करने के लिए किया जाता है कि CLAUDE.md कैसे लिखें।

## सामान्य आदेश
- `python -m pytest` —— परीक्षण चलाएं

## प्रोग्रामिंग कन्वेंशन
- सभी फ़ंक्शंस में टाइप एनोटेशन होना चाहिए
- स्ट्रिंग्स के लिए हमेशा डबल कोट्स का उपयोग करें

## सावधानियां
- `main.py` में `add` के फ़ंक्शन हस्ताक्षर (signature) को संशोधित न करें, केवल आंतरिक रूप से तर्क (logic) जोड़ें

अपेक्षा: CLAUDE.md प्रोजेक्ट रूट डायरेक्टरी में दिखाई देता है, और सामग्री बिल्कुल वैसी ही है जैसी ऊपर दिए गए अनुभागों में है। पूरा पाठ 15 पंक्तियों से कम है—इस लंबाई को ध्यान में रखें, और वास्तविक प्रोजेक्ट्स को नियंत्रण से बाहर न होने दें।

चरण 3: Claude प्रारंभ करें और सत्यापित करें कि इसने वास्तव में इसे पढ़ा है

प्रोजेक्ट निर्देशिका में प्रारंभ करें:

claude

शुरू करने के बाद, लोडिंग स्थिति की पुष्टि करने के लिए इस आदेश को टाइप करें:

/memory

अपेक्षा: आप सूची में आपके द्वारा अभी-अभी लिखा गया ./CLAUDE.md देख सकते हैं। जब तक यह सूची में है, इसका मतलब है कि Claude ने वास्तव में इसे इस सत्र के संदर्भ में डाल दिया है। यह कदम आधिकारिक तौर पर अनुशंसित समस्या निवारण विधि है—यदि किसी नियम का पालन नहीं किया जाता है, तो सबसे पहली बात यह जाँचना है कि /memory का उपयोग करके फ़ाइल लोड की गई थी या नहीं।

चरण 4: इसे "कन्वेंशन पर कदम रखने" वाला काम करने दें, और देखें कि क्या यह नियमों का पालन करता है

/memory से बाहर निकलें और इनपुट बॉक्स पर वापस लौटें, टाइप करें:

add फ़ंक्शन में टाइप एनोटेशन जोड़ें

अपेक्षा: Claude द्वारा दिए गए diff में, प्रकार एनोटेशन प्रोजेक्ट द्वारा सहमत लेखन विधि का उपयोग करता है, और यह उस फ़ंक्शन हस्ताक्षर के बाहर उन भागों को नहीं छुएगा जिन्हें संशोधित करने से मना किया गया है। यदि यह ईमानदारी से CLAUDE.md में आपके "फ़ंक्शन में टाइप एनोटेशन होना चाहिए" के अनुसार इसे संशोधित करता है—बधाई हो, यह ऑनबोर्डिंग मैनुअल प्रभावी हो गया है।

⚠️ अगर आपको लगता है कि यह CLAUDE.md का पालन नहीं कर रहा है: पहले /memory से पुष्टि करें कि फ़ाइल लोड हो गई है; फिर जांचें कि क्या नियम बहुत अस्पष्ट है (जैसे "साफ़"); अंत में, देखें कि क्या दो नियमों में टकराव है। ये तीन चरण आधिकारिक तौर पर दिए गए मानक समस्या निवारण अनुक्रम हैं, और उनका पालन करने से मूल रूप से समस्या का पता चल जाएगा।

💡 एक वाक्य में सारांश: "फ़ाइल बनाएँ → 15 पंक्तियों से कम के सुव्यवस्थित नियम लिखें → लोडिंग की पुष्टि करने के लिए /memory का उपयोग करें → इसे यह सत्यापित करने के लिए काम करने दें कि क्या यह नियमों का पालन करता है" प्रक्रिया से गुजरें। यदि यह काम नहीं करता है, तो समस्या निवारण के लिए /memory → अस्पष्टता की जाँच करें → संघर्ष की जाँच करें के आधिकारिक अनुक्रम का पालन करें।

---

08 सारांश

इस लेख में, आपने CLAUDE.md, "Claude की प्रोजेक्ट मेमोरी" को शुरू से अंत तक समझ लिया है:

आयाम	मुख्य निष्कर्ष
यह क्या है	हर सत्र के लिए आवश्यक ऑनबोर्डिंग मैनुअल, "मजबूत सुझाव" स्तर, लोहे का नियम नहीं
कितने स्तर	उपयोगकर्ता स्तर (व्यक्तिगत) / प्रोजेक्ट स्तर (टीम, git में जाता है) / उपनिर्देशिका स्तर (आवश्यकतानुसार)
लोडिंग क्रम	संयोजित, ओवरराइट नहीं किया गया, जितना करीब, उतना ही बाद में पढ़ा जाता है, संघर्ष में हावी होता है
क्या लिखें	अवलोकन / टेक स्टैक / आदेश / कन्वेंशन / निषिद्ध क्षेत्र, उन सभी चीज़ों को हटा दें जो कोड स्वयं साबित कर सकता है
@ संदर्भ	संरचना व्यवस्थित करने के लिए, संदर्भ (context) को नहीं बचाता है (अभी भी पूरी तरह से लोड है)
रखरखाव	Claude को "इसे CLAUDE.md में जोड़ने" के लिए कहें या /memory के साथ संपादित करें; नियमित रूप से पुरानी और परस्पर विरोधी जानकारी को हटा दें; गद्य के बजाय नियमों की तरह दिखना चाहिए

अब आपको सक्षम होना चाहिए: यह तय करना कि क्या कोई जानकारी CLAUDE.md में जानी चाहिए और इसे किस स्तर पर रखा जाना चाहिए; ऐसे नियम लिखना जो सत्यापन योग्य होने के लिए पर्याप्त विशिष्ट हों, न कि केवल खाली बातें; संदर्भ (context) लागत को जानते हुए बाहरी दस्तावेज़ों को संदर्भित करने के लिए @ का उपयोग करना; जब प्रोजेक्ट लंबे समय से चल रहा हो, तो जानना कि आसानी से नियम कैसे जोड़ें और नियमित रूप से कैसे पतला करें। एक वाक्य में—अब आप एक ऐसा CLAUDE.md लिख सकते हैं जिसे Claude वास्तव में सुनेगा, न कि तीन सौ पंक्तियों का ऐसा दस्तावेज़ जिसे कोई नहीं सुनता।

---

अगला लेख 19 "संदर्भ प्रबंधन (Context Management)"—इस लेख में बार-बार उल्लेख किया गया है कि "CLAUDE.md संदर्भ विंडो पर कब्ज़ा कर लेगा" और "@ संदर्भ अभी भी पूरी तरह से लोड है", तो यह संदर्भ विंडो (context window) आखिर क्या है? क्या होगा यदि यह भर जाए? /context और /compact का उपयोग कैसे करें? अगला लेख विशेष रूप से इस कार्यक्षेत्र (workspace) को अच्छी तरह से समझाएगा। सोचने के लिए एक छोटा सा प्रश्न: आपको क्या लगता है कि कौन सा अधिक टोकन की खपत करता है, CLAUDE.md द्वारा लिया गया हिस्सा या आपकी पूरी बातचीत?

---

अनुशंसित पाठन

• सामान्य समस्या निवारण (FAQ / Troubleshooting)
• चार सबसे आम कार्य: कोडबेस एक्सप्लोर करना, बग्स ठीक करना, रिफैक्टरिंग, परीक्षण लिखना
• Voice वॉयस मोड: प्रॉम्प्ट्स को टाइप करने के बजाय बोलें