मैंने बहुत सारी बुरी CLAUDE.md फ़ाइलें पढ़ी हैं। अधिकतर में एक ही समस्या है: वे एक विशबोर्ड हैं, कोई ब्रीफ नहीं। "कृपया साफ कोड लिखें" और "बेस्ट प्रैक्टिसेज़ का पालन करें" से भरे-भरे पेज — इतने सामान्य निर्देश कि कुछ भी नहीं बदलते। अगर आपकी CLAUDE.md धरती के किसी भी प्रोजेक्ट की हो सकती है, तो यह मृत भार है।
CLAUDE.md फ़ाइल वह नोट है जिसे Claude Code आपके रेपो में हर सेशन की शुरुआत में पढ़ता है। यह ऑटोमेटिकली लोड होती है। यह पर्सिस्टेंट कॉन्टेक्स्ट है। और यहां वह बात है जिसे लोग चूक जाते हैं: इसमें हर शब्द हर एकल रिक्वेस्ट पर token खर्च करता है। तो सवाल "मैं Claude को क्या बता सकता हूं?" नहीं है। यह है "इसके बिना Claude क्या गलत करता है जिसे सुधारते-सुधारते मैं थक गया हूं?"
यह दृष्टिकोण परिवर्तन सब कुछ बदल देता है। चलिए मैं आपको दिखाता हूं कि आपकी CLAUDE.md फ़ाइल में क्या डालना है।
उन चीजों से शुरू करें जो Claude अनुमान नहीं लगा सकता
Claude आपका कोड पढ़ सकता है। यह आपका मन नहीं पढ़ सकता। किसी भी CLAUDE.md में सबसे अधिक मूल्यवान लाइनें वे तथ्य हैं जो फ़ाइलों में खुद दिखाई नहीं देते।
## प्रोजेक्ट
यह App Router के साथ एक Next.js 14 ऐप है। हम Cloudflare Pages पर डिप्लॉय करते हैं।
पैकेज मैनेजर pnpm है — कभी npm या yarn नहीं।
## कमांड
- `pnpm dev` — :3000 पर लोकल सर्वर
- `pnpm test` — Vitest चलाता है, किसी भी commit से पहले पास होना चाहिए
- `pnpm typecheck` — किसी भी .ts फ़ाइल को एडिट करने के बाद यह चलाएं
वह कमांड ब्लॉक अकेले आपको हफ्ते में एक दर्जन सुधारों से बचाता है। उसके बिना, Claude खुशी-खुशी npm test चलाएगा और इसे फेल होते देखेगा, या उस typecheck को छोड़ देगा जिसे आप हमेशा चलाते हैं। उसके साथ, AI बिना बताए सही काम करता है।
ध्यान दीजिए मैंने "कभी npm या yarn नहीं" कहा। विशिष्टता vibes को मात देती है। "pnpm उपयोग करें" एक सुझाव है। "कभी npm या yarn नहीं" एक नियम है, और Claude इसे नियम की तरह मानता है।
उन परंपराओं को एनकोड करें जिन्हें आप बार-बार समझाते रहते हैं
अपने पिछले हफ्ते के सेशन वापस सोचें। आपने एक से अधिक बार क्या सुधारा? वे सुधार आपकी CLAUDE.md हैं।
## परंपराएं
- Components src/components में जाते हैं, प्रति component एक फ़ोल्डर।
- हम Tailwind उपयोग करते हैं। कोई CSS modules नहीं, कोई styled-components नहीं।
- API routes { data } या { error } रिटर्न करते हैं, कभी bare values नहीं।
- Dates हमेशा UTC ISO strings के रूप में store किए जाते हैं।
इनमें से प्रत्येक एक असली निर्णय है जो आपका codebase पहले से ले चुका है। इसे एक बार लिखने का मतलब है कि आप हर सेशन में इसे टाइप करना बंद कर देते हैं। यही पूरा खेल है — आवर्ती सुधार को अपने दिमाग से फ़ाइल में ले जाएं।
टोन निर्देशों के बारे में एक बात
आप आकार दे सकते हैं कि Claude कैसे काम करता है, न केवल वह क्या जानता है:
## काम करने का तरीका
- केवल वही बदलाव करें जो मांगा गया है। जब तक न कहा जाए adjacent code को refactor न करें।
- छोटे choices के लिए (variable names, file location), बस एक चुनें और नोट करें।
रुककर पूछें नहीं।
- एडिट करने के बाद, मुझे बताने से पहले typecheck और tests चलाएं।
वह मध्य लाइन सोना है अगर आप हाल के Claude model पर हैं। नए models डिफ़ॉल्ट रूप से अधिक सोच-समझकर काम करते हैं — वे बहुत सी छोटी decisions पर रुककर पूछेंगे। एक छोटा "बस एक चुनें" निर्देश उस समय को वापस लेता है बिना AI को महत्वपूर्ण चीजों पर लापरवाह बनाए।
क्या छोड़ें
अब deletions, जो उतनी ही महत्वपूर्ण हैं।
कुछ भी सामान्य काटें। "सुरक्षित, maintainable code लिखें" कुछ नहीं करता। Claude पहले से कोशिश करता है। आप default को दोहराने के लिए tokens खर्च कर रहे हैं।
कोड में जो कुछ भी है उसे काटें। अपनी पूरी package.json न पेस्ट करें या हर dependency सूचीबद्ध न करें। Claude फ़ाइल खोल सकता है। वह बताएं जो फ़ाइलें पढ़ने से स्पष्ट नहीं है — जैसे आपने कोई library क्यों चुनी, या जब दो काम कर सकते हैं तो कौन सा prefer करें।
उपन्यास काटें। मैंने 600-लाइन CLAUDE.md फ़ाइलें देखी हैं। लाइन 200 तक, signal-to-noise ratio इतनी खराब है कि महत्वपूर्ण नियम दब जाते हैं। एक तंग 40-लाइन फ़ाइल जिसे Claude वास्तव में follow करता है, एक बड़ी फ़ाइल जिसे वह आधा-अनदेखा करता है, को मात देती है। बेरहम बनें। अगर किसी लाइन ने एक असली गलती रोककर अपनी जगह नहीं कमाई, तो इसे हटाएं।
फ़ाइल कहाँ जाती है
CLAUDE.md को अपने repo root में डालें और Claude Code इसे ऑटोमेटिकली ढूंढ लेगा। आप एक subdirectory में भी एक nested कर सकते हैं — जैसे frontend/CLAUDE.md — और Claude उस folder में काम करते समय इसे ऊपर layer करेगा। Monorepos के लिए handy है जहां backend और frontend में वास्तव में अलग-अलग नियम हैं।
आपके home config directory में एक global file भी है जो हर प्रोजेक्ट पर apply होती है। मैं अपनी को लगभग खाली रखता हूं: बस कुछ personal preferences जो हर जगह सच हैं। Project-specific ज्ञान project में है, आपकी global file में नहीं।
एक template जिसे आप चुरा सकते हैं
# CLAUDE.md
## प्रोजेक्ट
[एक या दो वाक्य: यह क्या है, stack, यह कहाँ deploy होता है।]
## कमांड
- [dev command]
- [test command — नोट करें अगर commits से पहले pass होना ज़रूरी है]
- [कोई भी check जो आप हमेशा चलाते हैं]
## परंपराएं
- [एक निर्णय जो code से obvious नहीं है]
- [एक library preference]
- [एक pattern जो आप enforce करते हैं]
## काम करने का तरीका
- [कितना thorough/conservative होना है]
- [कब पूछना है बनाम कब decide करना है]
इसे fill करें, फिर एक हफ्ते के लिए इसके साथ रहें। जब आप खुद को तीसरी बार किसी चीज़ पर Claude को correct करते पाएं, वह एक missing line है — इसे add करें। जब आप notice करें कि एक line वास्तव में कभी matter नहीं किया, इसे delete करें।
CLAUDE.md फ़ाइल वह document नहीं है जिसे आप एक बार लिखते हैं। यह वह चीज़ है जिसे आप tune करते हैं। अच्छी वाली short, specific और एक समय में एक correction से earned होती हैं। छोटे से शुरू करें। इसे केवल वहां grow करने दें जहां यह ज़रूरी है।