95% लोग इस फ़ाइल के बिना Claude Code का उपयोग करते हैं। यहाँ बताया गया है कि वे क्या चूक रहे हैं।

मैंने दर्जनों Claude Code कॉन्फ़िगरेशन का परीक्षण किया है।

एकमात्र चीज़ जिसने वास्तव में मेरे आउटपुट को बदला: एक 60-लाइन फ़ाइल जिसे CLAUDE.md कहा जाता है।

इसे बुकमार्क करके रखें 🔖

यहां बिल्कुल बताया गया है कि यह कैसे काम करता है, ज़्यादातर लोग इसे पूरी तरह से क्यों मिस करते हैं, और पूरा टेम्पलेट जिसे आप आज कॉपी कर सकते हैं:

Claude Code के बारे में कोई आपको क्या नहीं बताता

आपके पहले प्रॉम्प्ट से पहले। कोड की एक भी लाइन से पहले। आपके सत्र में कुछ भी होने से पहले।

Claude एक फ़ाइल पढ़ता है। बस एक।

CLAUDE.md।

और वह इसे पूरे सत्र के लिए पूर्ण सत्य मानता है। एक सुझाव के रूप में नहीं। दूसरे संदर्भों के बीच एक संदर्भ के रूप में नहीं। एक निर्णायक ब्रीफ के रूप में जो हर निर्णय को फ्रेम करता है।

यही कारण है कि यह फ़ाइल पूरे Claude Code स्टैक में सबसे कम आंका गया वेरिएबल है।

ज़्यादातर लोगों के पास यह बिल्कुल नहीं है। और जिनके पास है, उन्होंने दो गलतियों में से एक की है: या तो फ़ाइल में कोई सार नहीं है, या यह "एक अनुभवी सीनियर इंजीनियर बनें जो चरण-दर-चरण सोचता है" जैसी 300 लाइनें हैं।

दोनों बेकार हैं। अलग-अलग कारणों से।

अधिकांश CLAUDE.md फ़ाइलें काम क्यों नहीं करतीं: 3 असली कारण

कारण 1: बहुत लंबी

Claude प्रति सत्र लगभग 150 से 200 निर्देशों का विश्वसनीय रूप से पालन कर सकता है। यह एक संरचनात्मक बाधा है, सद्भावना का मामला नहीं।

समस्या: Claude Code के आंतरिक सिस्टम प्रॉम्प्ट में पहले से ही लगभग 50 निर्देश होते हैं। इसका मतलब है कि आपकी CLAUDE.md में वास्तव में 100 से 150 निर्देश स्लॉट हैं, उसके बाद Claude उन्हें छोड़ना शुरू कर देता है।

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

कारण 2: खराब सामग्री

अधिकांश CLAUDE.md फ़ाइलें उन चीज़ों से भरी होती हैं जिन्हें Claude खुद ही समझ सकता है या जो उसके व्यवहार को मापने योग्य तरीके से नहीं बदलतीं।

"सीनियर इंजीनियर की तरह कार्य करें।" → Claude पहले से जानता है कि इसका क्या मतलब है और यह किसी विशिष्ट व्यवहार को एंकर नहीं करता। "चरण-दर-चरण सोचें।" → यह उसके प्रशिक्षण में है। आप एक लाइन बर्बाद कर रहे हैं। "स्वच्छ और रखरखाव योग्य कोड लिखें।" → कोई ठोस मानदंड नहीं। Claude को नहीं पता कि आपके विशिष्ट संदर्भ में "स्वच्छ" का क्या मतलब है।

हर वह लाइन जो किसी विशिष्ट, ठोस त्रुटि को नहीं रोकती, वह उन निर्देशों से चुराई गई लाइन है जो वास्तव में मायने रखते हैं। परीक्षण सरल है: अगर आप इस लाइन को हटाते हैं, तो क्या Claude को कुछ विशिष्ट गलत मिलेगा? अगर जवाब नहीं है, तो लाइन वहाँ नहीं होनी चाहिए।

कारण 3: शून्य पदानुक्रम

ज़्यादातर लोग इस बात को नज़रअंदाज़ करते हैं कि Claude Code में तीन स्तरों के निर्देश हैं, और वे सब कुछ एक ही जगह पर ठूंस देते हैं।

• ~/.claude/CLAUDE.md → वैश्विक (आपकी सभी परियोजनाओं पर लागू होता है)
• .claude/CLAUDE.md → परियोजना (टीम के साथ साझा, git में)
• ./CLAUDE.local.md → स्थानीय (व्यक्तिगत ओवरराइड, gitignored)

वैश्विक स्तर उन नियमों के लिए है जिन्हें आप हर प्रोजेक्ट में दोहराएंगे। परियोजना स्तर आपके स्टैक और टीम के लिए विशिष्ट संदर्भ के लिए है। स्थानीय स्तर आपकी व्यक्तिगत प्राथमिकताओं के लिए है जिन्हें साझा करने की आवश्यकता नहीं है।

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

एक प्रभावी CLAUDE.md बनाने वाले 5 अनुभाग

प्रोडक्शन में दर्जनों CLAUDE.md फ़ाइलों — ओपन-सोर्स प्रोजेक्ट, आधिकारिक Anthropic डॉक्स, सामुदायिक सर्वोत्तम अभ्यास भंडार — को छानने के बाद, यहाँ वे 5 अनुभाग हैं जो सभी प्रभावी फ़ाइलों में समान हैं:

अनुभाग 1: महत्वपूर्ण आदेश

Claude हर सत्र बिना यह जाने शुरू करता है कि आपके प्रोजेक्ट को कैसे बनाना है, आपके परीक्षण कैसे चलाने हैं, या लिंट त्रुटियों को कैसे ठीक करना है। वह अनुमान लगाएगा। और उसके अनुमान आपको टर्न खर्च करने पर मजबूर करेंगे।

उसे बताएं कि वास्तव में क्या टाइप करना है:

Commands

• Build: npm run build
• Dev: npm run dev
• Test single file: npm test -- path/to/file
• Full test: npm test
• Lint + fix: npm run lint:fix
• Type check: npx tsc --noEmit

छोटा। सटीक। सीधे उपयोग करने योग्य।

इस अनुभाग के बिना, Claude npm test करने की कोशिश करेगा जब आपका प्रोजेक्ट pnpm vitest पर चलता है। वह एक कमांड समस्या को डीबग करने में तीन टर्न बर्बाद करेगा जो कभी काम नहीं करने वाली थी। तीन टर्न जिनका उपयोग आप वास्तविक काम पर कर सकते थे।

अनुभाग 2: आर्किटेक्चर मैप

Claude हर सत्र आपके कोडबेस के शून्य ज्ञान के साथ शुरू करता है। बिल्कुल शून्य। वह नहीं जानता कि आपका बिज़नेस लॉजिक कहाँ रहता है। वह नहीं जानता कि आपके घटक स्टेटलेस होने चाहिए या नहीं। वह नहीं जानता कि आपके API रूट्स में बिज़नेस लॉजिक नहीं होना चाहिए।

उसे एक नक्शा दें:

Architecture

• src/lib/services/ → सभी बिज़नेस लॉजिक
• src/components/ → केवल स्टेटलेस UI घटक
• src/lib/store/ → वैश्विक स्थिति (Zustand)
• src/app/api/ → API रूट्स, यहाँ कोई बिज़नेस लॉजिक नहीं
• DB तक पहुंच केवल Server Actions या API रूट्स के माध्यम से

आपकी ट्री संरचना की एक विस्तृत सूची नहीं। बस इतना काफी है कि Claude को पता चले कि चीज़ें कहाँ रहती हैं और, इससे भी महत्वपूर्ण, उन्हें कहाँ नहीं जाना चाहिए।

यह अंतर… कहाँ जाता है बनाम कहाँ नहीं जाता… वह है जो सबसे लगातार आर्किटेक्चरल त्रुटियों को रोकता है।

अनुभाग 3: कठोर नियम

यह पूरी फ़ाइल का सबसे महत्वपूर्ण अनुभाग है। बिना किसी अपवाद के।

यहाँ प्रत्येक नियम को एक ही प्रश्न का उत्तर देना चाहिए: "अगर मैं इस लाइन को हटा दूं, तो क्या Claude एक ठोस त्रुटि करेगा?"

अगर हाँ → नियम रहता है। अगर नहीं → उसका यहाँ कोई काम नहीं।

उच्च-मूल्य वाले नियमों का उदाहरण:

Rules

• NEVER commit .env files or secrets
• All async calls must be wrapped in a try/catch
• Functional components only, zero class components
• Mandatory commit prefixes: feat:, fix:, docs:, refactor:
• Every PR must pass npm run verify before merge
• Static export only, no SSR (deployed on S3)
• IMPORTANT: run type check after every code modification

इस सूची के बारे में दो बातें ध्यान देने योग्य हैं।

पहला, नकारात्मक नियम सकारात्मक नियमों जितने ही महत्वपूर्ण हैं। ".env फ़ाइलें कभी कमिट न करें" एक ऐसा नियम है जो केवल तब तक स्पष्ट लगता है जब तक Claude ऐसा नहीं करता। इसे डालें।

दूसरा, जोर देने वाले मार्कर जैसे IMPORTANT या YOU MUST वास्तव में काम करते हैं।

यह किस्सा नहीं है। Anthropic अपने स्वयं के दस्तावेज़ीकरण में इसकी पुष्टि करता है: किसी नियम से पहले IMPORTANT या YOU MUST जोड़ने से उस नियम के प्रति Claude के पालन में मापने योग्य सुधार होता है।

इनका संयम से उपयोग करें: उन नियमों के लिए आरक्षित रखें जिनके अनदेखा किए जाने पर सबसे गंभीर परिणाम होते हैं।

इस अनुभाग में 15 से कम नियम रखें। इससे अधिक होने पर, आप उन नियमों पर ध्यान केंद्रित करना कम कर देते हैं जो मायने रखते हैं।

अनुभाग 4: वर्कफ़्लो प्राथमिकताएँ

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

यह अनुभाग इसे रोकता है:

Workflow

• Ask clarifying questions before starting complex tasks
• Make minimal changes, do not refactor unrelated code
• Run tests after every change, fix failures before continuing
• Create separate commits per logical change, not one giant commit
• In case of uncertainty between two approaches, explain both and let me choose

यहाँ हर लाइन एक ठोस दर्द बिंदु का जवाब देती है। 47-फ़ाइल का विशाल कमिट। अनुरोधित पूर्ण पुनर्लेखन। वास्तु निर्णय जो Claude अकेले लेता है जब उसे आपसे पूछना चाहिए था।

अनुभाग 5: अपनी CLAUDE.md में क्या न डालें

यह अनुभाग अन्य अनुभागों जितना ही महत्वपूर्ण है। शायद इससे भी अधिक।

Do NOT include:

• Personality instructions ("be a senior engineer")
• Formatting rules that your linter already handles
• @ imports that pull entire docs into every session
• Duplicate rules (if global says "run tests", the project doesn't repeat it)
• Anything Claude learns on its own via auto-memory

यह अंतिम बिंदु व्यापक रूप से कम आंका गया है।

Claude अपने स्वयं के नोट्स ~/.claude/projects/<project>/memory/ में रखता है। अपने सत्र में /memory चलाकर देखें कि उसने आपके प्रोजेक्ट के बारे में पहले से क्या सीखा है। कुछ सत्रों के बाद, आपको अक्सर एहसास होगा कि Claude ने पहले ही वह जानकारी कैप्चर कर ली है जिसे आप अपनी CLAUDE.md में हाथ से लिखने वाले थे।

अपने सीमित निर्देशों को उन चीज़ों पर बर्बाद न करें जिन्हें Claude ने अपने आप याद कर लिया है।

पूरा टेम्पलेट 60 लाइनों से कम, उपयोग के लिए तैयार

अपने प्रोजेक्ट पर लागू न होने वाले अनुभागों को हटा दें। लक्ष्य सब कुछ भरना नहीं है। लक्ष्य केवल वही रखना है जो Claude के व्यवहार को मापने योग्य तरीके से बदलता है।

वे लाइनें जिनका मेरे आउटपुट पर सबसे अधिक प्रभाव पड़ा: ठोस परिणाम

दर्जनों कॉन्फ़िगरेशन का परीक्षण करने के बाद, यहाँ पाँच लाइनें हैं जिन्होंने सबसे अधिक दृश्यमान अंतर पैदा किया:

IMPORTANT: run type check after every code modification → Claude को स्पष्ट रूप से जांचने के लिए प्रेरित किए बिना टूटे हुए प्रकारों वाला कोड देने से रोकता है।

Make minimal changes, do not refactor unrelated code → पूरी फ़ाइलों के अनुरोधित पूर्ण पुनर्लेखन को रोकता है।

Create separate commits per logical change, not one giant commit → 47 मिश्रित फ़ाइलों के अपठनीय विशाल कमिट को रोकता है।

In case of uncertainty between two approaches, explain both and let me choose → Claude को अकेले वास्तु निर्णय लेने से रोकता है जो आपके होने चाहिए थे।

Static export only, no SSR → Claude को S3 पर स्थिर रूप से तैनात प्रोजेक्ट में सर्वर कोड जोड़ने से रोकता है।

इन पाँच लाइनों में क्या समानता है: प्रत्येक डीबग समय में एक विशिष्ट, लगातार और महंगी त्रुटि को रोकता है।

यह आपकी CLAUDE.md की हर लाइन के लिए अंतिम परीक्षण है।

मूलभूत त्रुटि और यह इतना व्यापक क्यों है

लोग अपनी CLAUDE.md को एक इच्छा सूची या व्यक्तित्व प्रॉम्प्ट की तरह मानते हैं।

"सीनियर बनें।" "संपूर्ण बनें।" "विशेषज्ञ की तरह सोचें।"

यह कोई ब्रीफ नहीं है। यह जादुई सोच है।

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

फ़ाइल को 80 लाइनों से कम रखें। हर बार जब Claude कोई त्रुटि करता है जिसे आप रोक सकते थे, तो इसे संशोधित करें।

और सबसे बढ़कर: समझें कि यह फ़ाइल समय के साथ क्या बन जाती है।

पहले महीने में एक अच्छी CLAUDE.md हर सत्र में आपका समय बचाती है। तीसरे महीने तक, इसने आपके कन्वेंशन और स्टैक को इतनी सटीकता से कैप्चर कर लिया है कि Claude लगभग एक टीम सदस्य की तरह काम करता है।

छठे महीने तक, इसमें वह हर त्रुटि शामिल होती है जो Claude ने इस प्रोजेक्ट पर कभी की है और उन सभी को स्वचालित रूप से रोकता है।

फ़ाइल पूंजीकृत होती है। यह हर सुधार के साथ बेहतर होती है। यह धीरे-धीरे सबसे अच्छा ऑनबोर्डिंग ब्रीफ बन जाती है जो आपने कभी लिखा है।

Claude के लिए नहीं। आपके लिए।