सबसे बेहतर CLAUDE.md लिखना: Claude Code के लिए एक पूर्ण मार्गदर्शिका

Claude Code का सिस्टम प्रॉम्प्ट आपका सत्र शुरू होने से पहले ही लगभग 50 निर्देश ले लेता है। फ्रंटियर LLMs पर शोध दिखाता है कि लगभग 150 से 200 कुल निर्देशों पर निर्देश-पालन में गिरावट शुरू हो जाती है, जिससे आपके पास अपने प्रोजेक्ट के लिए Claude को बताने लायक हर चीज़ के लिए लगभग 100 से 150 स्लॉट बचते हैं। 

CLAUDE.md वह फ़ाइल है जो इन स्लॉट्स को भरती है। यह एक मार्कडाउन फ़ाइल है जिसे Claude Code हर सत्र की शुरुआत में पढ़ता है, जिससे उसे आपके कोडबेस का स्थायी संदर्भ मिल जाता है और आपको बार-बार वही बातें नहीं दोहरानी पड़तीं। लेकिन Claude सक्रिय रूप से उस सामग्री को फ़िल्टर करता है जिसे वह मौजूदा कार्य से अप्रासंगिक मानता है। फूली हुई फ़ाइल केवल जगह ही नहीं घेरती; यह आपके वास्तविक नियमों से प्रतिस्पर्धा करती है।

यह ट्यूटोरियल बताता है कि ऐसा CLAUDE.md कैसे बनाएं जिसकी हर पंक्ति की कीमत वसूल हो: क्या शामिल करना है, क्या बाहर रखना है, टीमों के लिए इसे कैसे संरचित करना है, और समय के साथ इसे उपयोगी कैसे रखना है।

मैं यह भी सुझाव दूंगा कि आप हमारे अन्य हालिया Claude Code मार्गदर्शकों पर नज़र डालें:

• Claude Code Plan Mode
• Docker में Claude Code
• Claude Code प्लगइन्स कैसे बनाएं
• Ollama लोकल मॉडलों के साथ Claude Code का उपयोग

CLAUDE.md फ़ाइल क्या है?

CLAUDE.md एक मार्कडाउन फ़ाइल है जिसे Claude Code हर बातचीत की शुरुआत में अपने आप लोड करता है। यह आपके प्रोजेक्ट रूट पर रहती है और Claude को तरह-तरह के प्रासंगिक तथ्यों पर स्थायी निर्देश देती है: 

• आप कौन-सा टेक स्टैक उपयोग करते हैं
• आप टेस्ट कैसे चलाते हैं
• कौन‑सी परंपराएँ मायने रखती हैं
• किसे नहीं छेड़ना है

इसके बिना हर सत्र शून्य से शुरू होता है। आप वही संदर्भ फिर समझाते हैं, वही मान्यताएँ सुधारते हैं, और Claude को वही गलतियाँ करते देखते हैं जो उसने कल की थीं। CLAUDE.md इसे आपके प्रोजेक्ट ज्ञान को एक बार एनकोड करके ठीक करता है।

यह Claude Code द्वारा उपयोग किए जाने वाले कई संदर्भ तंत्रों में से एक है, और प्रत्येक अलग तरह का काम संभालता है:

/init चलाने पर आपका कोडबेस, बिल्ड सिस्टम, टेस्ट फ़्रेमवर्क और कोड पैटर्न विश्लेषित करके एक स्टार्टर CLAUDE.md बनता है। अगर फ़ाइल पहले से मौजूद है, तो यह ओवरराइट करने के बजाय सुधार सुझाता है। यह शुरू करने के लिए ठीक बिंदु है, पर फ़ाइल इतनी महत्वपूर्ण है कि इसे ऑटोपायलट पर छोड़ना उचित नहीं।

एक और ज़रूरी बात: CLAUDE.md की सामग्री /compact के बाद भी बनी रहती है। जब सत्र के बीच में संदर्भ कंप्रेस होता है, Claude फ़ाइल को डिस्क से फिर पढ़ता है और उसे ताज़ा इंजेक्ट करता है।

फ़ाइल स्थान और प्राथमिकता

CLAUDE.md फ़ाइलें चार स्थानों पर रह सकती हैं, व्यापक से विशेष क्रम में:

• मैनेज्ड पॉलिसी (संगठन-स्तरीय): macOS पर /Library/Application Support/ClaudeCode/CLAUDE.md। मशीन के सभी उपयोगकर्ताओं पर लागू और किसी सेटिंग से बाहर नहीं की जा सकती। Linux/WSL पर /etc/claude-code/CLAUDE.md, और Windows पर C:\Program Files\ClaudeCode\CLAUDE.md।

• उपयोगकर्ता-स्तर: ~/.claude/CLAUDE.md। आपकी मशीन के हर प्रोजेक्ट पर लागू निजी निर्देश।

• प्रोजेक्ट-स्तर: रेपो रूट पर ./CLAUDE.md या ./.claude/CLAUDE.md। यही वह है जिसे आप git में कमिट करते हैं और टीम के साथ साझा करते हैं।

• सबडायरेक्टरी: ./subdir/CLAUDE.md। केवल उसी डायरेक्टरी तक सीमित, और Claude वहां की फ़ाइलें पढ़ते समय ऑन-डिमांड लोड होता है, सत्र शुरू होने पर नहीं।

जितनी अधिक विशिष्ट फ़ाइल, उतनी अधिक प्राथमिकता। यदि आपकी प्रोजेक्ट CLAUDE.md कहती है "tabs का उपयोग करें" और आपकी उपयोगकर्ता-स्तरीय फ़ाइल कहती है "spaces का उपयोग करें," तो प्रोजेक्ट फ़ाइल मान्य होगी।

ऐसी निजी प्राथमिकताएँ जो वर्शन कंट्रोल में नहीं जानी चाहिएँ, उनके लिए CLAUDE.local.md बनाएँ और उसे .gitignore में जोड़ें। एडिटर की आदतें, पसंदीदा कमिट शैली, या अस्थायी ओवरराइड साझा फ़ाइल को दूषित करने के बजाय यहाँ रखें।

यह जान लेने के बाद कि फ़ाइल कहाँ रहती है और किससे प्रतिस्पर्धा करती है, अगला प्रश्न है कि भीतर वास्तव में क्या होना चाहिए।

अपने CLAUDE.md में क्या शामिल करें

एक CLAUDE.md तीन परतों में बँटता है: 

1. प्रोजेक्ट क्या है
2. यह इस तरह क्यों काम करता है
3. इसमें Claude को कैसे काम करना चाहिए

यदि आपने Claude Code Best Practices पढ़ा है, तो आप इसे एक ही सिद्धांत का संकुचित सतह पर लागू होना पहचानेंगे। (यदि नहीं, तो यह लेख पढ़ने के बाद ज़रूर देखें!)

उच्च‑संकेत वाला प्रोजेक्ट अवलोकन

एक या दो पंक्तियों के प्रोजेक्ट वर्णन और अपने टेक स्टैक (संस्करणों सहित) से शुरुआत करें। Claude आपका कोड पढ़कर बहुत कुछ अनुमान लगा सकता है, लेकिन यह नहीं मानेगा कि आप Next.js 14 नहीं बल्कि 15 पर हैं, या आपने Prisma के बजाय Drizzle चुना है।

डायरेक्टरी संरचना का मानचित्र शामिल करें। हर फ़ाइल नहीं, बस शीर्ष‑स्तरीय लेआउट संक्षिप्त विवरणों के साथ:

src/
  data/        # Data loading and preprocessing pipelines
  models/      # Model definitions and training loops
  evaluation/  # Metrics, validation, experiment tracking
  api/         # FastAPI endpoints for model serving
  tests/       # Co-located with source, test_*.py

आम कमांड्स को कोड ब्लॉक्स में रखें। बिल्ड, टेस्ट, लिंट और डेव सर्वर स्टार्टअप। कोड फेंस के भीतर का कमांड वैसा ही है जैसा Claude चलाएगा। वाक्य में लिखा कमांड एक सुझाव है जिस पर वह मनमानी कर सकता है।

उद्देश्य और बाधाएँ

आपके आर्किटेक्चरल फैसले फ़ाइल में होने चाहिए, वरना Claude अपने कर लेगा। यदि आपने किसी कारणवश SQLite को Postgres पर चुना है, तो उसे लिखें। यदि आपकी API लेयर किसी विशिष्ट पैटर्न का पालन करती है, तो उसका तर्क समझाएँ।

यहाँ तर्क असल काम करता है। "कभी force push न करें" एक सपाट निर्देश है जिसे Claude दबाव में अनदेखा कर सकता है। "कभी force push न करें। यह साझा इतिहास को फिर लिखता है और सहयोगियों के लिए अपरिवर्तनीय है," Claude को पर्याप्त संदर्भ देता है कि वह सामान्यीकरण कर सके। वह केवल git push --force से ही नहीं बचेगा। वह साझा ब्रांच पर git reset --hard करने से पहले भी हिचकेगा।

Claude के लिए कार्यात्मक निर्देश

यह उन परंपराओं को कवर करता है जो कोड पढ़कर Claude नहीं सीख सकता। यदि आप Conventional Commits (feat:, fix:, docs:) अपनाते हैं, तो बताइए। यदि ब्रांच initials/description जैसी नामकरण शैली का पालन करती हैं, तो उसे भी लिखें।

अनोखियाँ और जाल यहाँ भी होने चाहिए। हर कोडबेस में होते हैं: बिल्ड से पहले चलने वाली माइग्रेशन स्क्रिप्ट, टेस्ट पास होने से पहले विशेष मान वाला env वेरिएबल, वह मॉड्यूल जो गलत क्रम में इम्पोर्ट करने पर टूट जाता है। Claude हर सत्र में नया टीम‑मेंबर है, और ये वही बातें हैं जिन पर नया व्यक्ति पहले दिन ठोकर खाता है।

क्या छोड़ सकते हैं: वह सब जो भाषा से Claude पहले ही जानता है। आधुनिक JavaScript में async/await उपयोग करने या Python 3 में pathlib को तरजीह देने की जरूरत नहीं बतानी। यदि कोई परंपरा भाषा का डिफ़ॉल्ट है, तो उसे लिखना शोर है जो वास्तव में मायने रखने वाले निर्देशों को धकेल देता है।

CLAUDE.md फ़ाइल कैसे लिखें

सामग्री सही करना अपेक्षाकृत आसान है। कठिन हिस्सा है ऐसे निर्देश लिखना जिनका Claude सच में पालन करे, और यह जानना कि क्या काटना है।

प्रभावी निर्देश लिखना

हर बार स्पष्टता इरादे पर भारी पड़ती है। "कोड को ठीक से फ़ॉर्मैट करें" Claude को कुछ नहीं बताता। "2‑स्पेस इंडेंटेशन, सेमीकोलन नहीं, सिंगल कोट्स उपयोग करें" उसे ठोस, जाँचने योग्य निर्देश देता है।

हर पंक्ति पर यह कसौटी लगाएँ: "क्या इसे हटाने से Claude गलतियाँ करेगा?" यदि जवाब नहीं है, तो पंक्ति हटाएँ। आधिकारिक सिफारिश प्रति फ़ाइल 200 पंक्तियों से कम है, और कुछ अनुभवी टीमें 60 से कम पर काम करती हैं। यह महज़ न्यूनतावाद नहीं है: छोटी फ़ाइल का अधिक हिस्सा पढ़ा जाता है।

हेडिंग स्तर अधिकतम तीन रखें। README प्रथाओं से पहचाने जाने वाले सेक्शन नाम इस्तेमाल करें: Commands, Structure, Conventions, Testing। रचनात्मक सेक्शन नाम घर्षण बढ़ाते हैं क्योंकि Claude ने लाखों READMEs देखे हैं और उसे कड़ी अपेक्षाएँ हैं कि क्या कहाँ रहता है।

जब कोई नियम फ़ाइल में होने के बावजूद अनदेखा होता रहे, तो उसके इर्द‑गिर्द अधिक शब्द मत जोड़ें। उसे IMPORTANT: या YOU MUST से प्रीफ़िक्स करें। पर इसे कम उपयोग करें, क्योंकि जोर का असर स्केल नहीं होता—हर नियम "महत्वपूर्ण" होगा तो जोर अदृश्य हो जाएगा।

क्या बाहर रखें

कोड स्टाइल एन्फोर्समेंट सबसे बड़ा जाल है। फ़ॉर्मैटिंग, इंडेंटेशन, इम्पोर्ट ऑर्डरिंग: ये निर्धारक समस्याएँ हैं जिनके निर्धारक समाधान हैं। Biome, ESLint, या Ruff जैसे लिंटर्स और फ़ॉर्मैटर्स इन्हें तेज़, सस्ते और 100% संगति के साथ सँभालते हैं। स्टाइल नियमों पर निर्देश बजट खर्च करना बेकार है: वही काम प्री‑कमिट हुक मुफ़्त में कर देता है।

मानक भाषा परंपराएँ भी बहिष्करण सूची में हों, क्योंकि Claude पहले से TypeScript पैटर्न और Python मुहावरों को जानता है। पूरी API डॉक्यूमेंटेशन पेस्ट करने के बजाय लिंक करें। कार्य‑विशिष्ट निर्देश जो केवल कुछ वर्कफ़्लोज़ पर लागू होते हैं, उन्हें skills में रखें—वे हर सत्र में जगह घेरने के बजाय आवश्यकता पड़ने पर लोड होंगे।

एक पैटर्न उल्लेखनीय है: केवल निषेध वाले निर्देश। "कभी --legacy-peer-deps का उपयोग न करें" Claude को निर्भरता संघर्ष पर अटका देता है। हर निषेध के साथ दिशा जोड़ें: "कभी --legacy-peer-deps का उपयोग न करें; संघर्षों को पैकेज को संगत संस्करण में अपडेट करके सुलझाएँ।" यदि आपने Cursor Rules या समान AI कॉन्फ़िगरेशन फ़ाइलों के साथ काम किया है, तो पाएँगे कि यह सिद्धांत टूल्स भर में लागू होता है।

पहले और बाद में: एक लघु वास्तविक उदाहरण

व्यवहार में फर्क इस तरह दिखता है। बाएँ तरफ़ एक सामान्य ऑटो‑जनरेटेड CLAUDE.md सेक्शन है जो ऐसे सामान्य सुझावों से भरा है जिन्हें Claude पहले से जानता है। दाएँ तरफ़ वही सेक्शन विशिष्टता की कसौटी पर कसा हुआ है: केवल प्रोजेक्ट‑विशिष्ट तथ्य बचे हैं।

दूसरा संस्करण छोटा है और Claude को वे बातें बताता है जिन्हें वह कोडबेस से नहीं समझ सकता।

शुरू से फ़ाइल बनाना

अपने प्रोजेक्ट रूट में /init चलाएँ और जनरेटेड शुरुआती बिंदु लें। हर पंक्ति पढ़ें, जो स्पष्ट है उसे काटें, और जो आपकी टीम के वास्तविक काम करने के तरीके से गायब है, उसे जोड़ें। /init के आउटपुट से शुरू करना खाली फ़ाइल से तेज़ है, लेकिन ऑटो‑जनरेटेड सामग्री बिना समीक्षा शिप नहीं होनी चाहिए।

यदि आप शून्य से लिखना पसंद करते हैं, तो पाँच सेक्शन से शुरू करें: 

1. प्रोजेक्ट अवलोकन
2. डायरेक्टरी मानचित्र
3. कमांड्स
4. परंपराएँ
5. अनोखियाँ

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

दो संकेत बताते हैं कि फ़ाइल को रखरखाव चाहिए: 

• Claude किसी मौजूद निर्देश को मिस करने के लिए माफ़ी माँगता है: वाक्यविन्यास अस्पष्ट है, निर्देश फिर से लिखें।
• वही नियम कई सत्रों में टूटता है: फ़ाइल बहुत लंबी है और Claude उसे फ़िल्टर कर रहा है, इसलिए छोटा करें।

दोनों का एक ही उपचार है: कम शब्द, स्पष्ट संरचना।

टीमों के लिए CLAUDE.md फ़ाइलों का स्केलिंग

एकल‑डेवलपर फ़ाइल अनिश्चितकाल तक इतनी सुथरी रह सकती है। टीम जुड़ते ही फ़ाइल को अलग तरह की संरचना चाहिए।

वर्शन कंट्रोल और साझा स्वामित्व

आपकी प्रोजेक्ट‑स्तरीय CLAUDE.md git में होनी चाहिए। यह साझा दस्तावेज़ीकरण है जो साथियों की अपनी गलतियों से निकले नियमों के योगदान से बेहतर होता जाता है। इसमें बदलावों को कोड PRs जैसा मानें: समीक्षा करें, पूछें कि क्या हर नई पंक्ति अपनी जगह वसूलती है।

जब परंपराएँ एक फ़ाइल की सीमा से बढ़ने लगें, तो उन्हें .claude/rules/ में ले जाएँ। हर Markdown फ़ाइल एक विषय कवर करे, वर्णनात्मक फ़ाइलनामों के साथ: testing.md, api-design.md, database-migrations.md। Claude इन्हें रिकर्सिवली खोजता है और मुख्य CLAUDE.md के समान प्राथमिकता से लोड करता है।

पाथ‑स्कोप्ड नियम इसे और लक्षित बनाते हैं। YAML फ्रंटमैटर जोड़ें, और नियम तभी लोड होगा जब Claude मिलती‑जुलती फ़ाइलों पर काम करेगा:

---
paths:
  - "src/api/**/*.ts"
---
# API conventions go here

आपकी फ्रंटएंड परंपराएँ बैकएंड काम के दौरान निर्देश बजट नहीं जलाएँगी, और इसके उलट भी।

ऐसे मोनोरिपोज़ जहाँ टीमों की परंपराएँ टकराती हैं, वहाँ claudeMdExcludes विशिष्ट फ़ाइलों को लोड होने से रोकता है:

{
  "claudeMdExcludes": [
    "**/other-team/.claude/rules/**"
  ]
}

इसे .claude/settings.local.json में रखें ताकि यह वर्शन कंट्रोल से बाहर रहे।

प्रोग्रेसिव डिस्क्लोज़र और मॉड्यूलराइज़ेशन

एक CLAUDE.md को स्केल करते समय अक्सर केंद्रीकरण की इच्छा जगती है: एक बड़ी फ़ाइल जिसमें सब कुछ हो। यह गलत दिशा है। मोनोरिपो के CLAUDE.md को सेवा‑स्तरीय फ़ाइलों में बाँटना कुल शब्द गणना को 80% तक घटा सकता है जबकि Claude के नियम‑पालन में सुधार करता है; प्रति सत्र कम पढ़ना मतलब कम फ़िल्टरिंग।

सिद्धांत: एम्बेड नहीं, संकेत करें। @path/to/big-doc.md (जो हर सत्र में पूरी फ़ाइल लोड कर देता है) के बजाय लिखें "माइग्रेशन प्रक्रियाओं के लिए देखें docs/migrations.md।" Claude को जानकारी चाहिए होगी तभी वह इसे पढ़ेगा। @ इम्पोर्ट सिन्टैक्स छोटे फ़ाइलों के लिए ठीक है, पर किसी भी बड़ी चीज़ को एम्बेड करने से बेहतर संदर्भित करना है।

सबडायरेक्टरी CLAUDE.md इस पैटर्न को पूरा करती हैं। frontend/CLAUDE.md जिसमें React परंपराएँ हों, वह तभी लोड होगी जब Claude उस डायरेक्टरी की फ़ाइलों को छुएगा। बैकएंड नियम फ्रंटएंड काम के दौरान रास्ते से हटे रहेंगे।

अपनी CLAUDE.md फ़ाइल का रखरखाव

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

फ़ाइल को वर्तमान रखना

नियमों को जितना सोचते हैं उससे धीमी गति से जोड़ें। नई पंक्ति तभी फ़ाइल में हो जब Claude ने कोई वास्तविक गलती की हो जिसे वह पंक्ति रोक देती। हर नियम किसी वास्तविक घटना से जुड़ना चाहिए, न कि किसी कल्पनात्मक से।

उल्टी दिशा भी उतनी ही अहम है: यदि Claude बिना बताए पहले से ही किसी परंपरा का पालन करता है, तो वह नियम बेकार भार है। उसे हटा दें और ऐसे नियमों के लिए निर्देश बजट खाली करें जो व्यवहार बदलते हैं।

एक कम‑मेहनत वाली आदत है Claude से हर कुछ हफ़्तों में कहना, "इस CLAUDE.md की समीक्षा करें और सुधार सुझाएँ"। यह नियमों के बीच विरोधाभास पकड़ता है, ओवरलैपिंग निर्देशों को चिह्नित करता है, और कसने योग्य वाक्यविन्यास पहचानता है। 

आप फ़ाइल में ही एक स्थायी निर्देश भी जोड़ सकते हैं: "सत्र के दौरान कोई गलत मान्यता मिले तो CLAUDE.md सुधार का सुझाव दें।" इससे एक फीडबैक लूप बनेगा जिसमें फ़ाइल सामान्य उपयोग से ही बेहतर होती जाएगी।

किन एंटी‑पैटर्न्स से बचें

सबसे आम विफलता संचय है। हर निराशाजनक सत्र के बाद नियम बढ़ते जाते हैं, कोई उन नियमों को नहीं हटाता जो अब मायने नहीं रखते, और अंततः फ़ाइल इतनी लंबी हो जाती है कि Claude उसका आधा फ़िल्टर कर देता है। जब Claude बार‑बार किसी नियम को अनदेखा करे, तो फूली हुई फ़ाइल पर जोर बढ़ाने से सुधार नहीं होगा। छंटाई से होगा।

यदि आप बड़ी फ़ाइलों के लिए @ इम्पोर्ट्स उपयोग कर रहे हैं, तो यह जाँचने लायक दूसरी समस्या है। @ के साथ इम्पोर्ट किया 500‑लाइन का आर्किटेक्चर डॉक हर सत्र में पूरा दस्तावेज़ एम्बेड कर देता है, आपके निर्देश बजट को पहली वास्तविक नियम प्रसंस्करण से पहले ही जला देता है। इसके बजाय संदर्भित करें।

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

कई फ़ाइलों में विरोधाभासी नियम अप्रत्याशित व्यवहार कराते हैं। जब दो नियम टकराते हैं, Claude बिना बताए किसी एक को चुन लेता है। यह उन प्रोजेक्ट्स में और बिगड़ता है जो रूट CLAUDE.md को कई .claude/rules/ फ़ाइलों के साथ मिलाते हैं। सभी निर्देश फ़ाइलों की समय‑समय पर समीक्षा ही एकमात्र रोकथाम है।

हर गलती नए नियम की हक़दार नहीं। कुछ विफलताएँ एक‑बार की होती हैं। हर एज‑केस के लिए नियम जोड़ने से फ़ाइल शर्तों से भरे निर्देशों से पट जाती है जो संकरे हालात में मदद करते हैं और अधिकांश सत्रों में नुकसान। लक्ष्य शुरू से एक ही रहा है: छोटी फ़ाइल, जहाँ हर पंक्ति व्यवहार बदलती है।

निष्कर्ष

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

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

सही अगला कदम: आज ही अपना रेपो ऑडिट करें और एक बेसलाइन ड्राफ़्ट बनाएं। पाँच सेक्शन से शुरू करें, इसे 60 पंक्तियों के भीतर रखें, और आगे की हर जोड़ वास्तविक गलतियों से प्रेरित होने दें।

यदि आप Anthropic API का उपयोग करने वाले टूल बनाना चाहते हैं, तो हमारा Introduction to Claude Models कोर्स पूरे मॉडल परिवार को कवर करता है और सिखाता है कि उनका प्रभावी उपयोग कैसे करें।