प्रोजेक्ट संरचना: Claude Code आपके प्रोजेक्ट में क्या रखता है

📚 सीरीज़ नेविगेशन: पिछला लेख 12 प्रोजेक्ट इनिशियलाइज़ेशन आपको /init रन करवाता है, प्रोजेक्ट के लिए पहला CLAUDE.md जनरेट करता है। इस लेख में आगे देखते हैं—/init के बाद, आपके प्रोजेक्ट में चुपचाप आया .claude/ फ़ोल्डर, आख़िर इसमें क्या है, यह किसके कंट्रोल में है, और क्या इसे git में कमिट करना चाहिए।

हर कोई कहता है कि .claude फ़ोल्डर की "चिंता मत करो, यह खुद को संभालता है", लेकिन सच कहूँ तो, इसे समझना ही यह है कि आप वास्तव में Claude Code का उपयोग करना जानते हैं।

मैं ऐसा क्यों कह रहा हूँ? क्योंकि इस टूल के लगभग सभी "उन्नत तरीके"—कस्टम कमांड, अनुमति नियंत्रण, उप-एजेंट (subagents), कौशल (skills)—जब डिस्क पर आते हैं, तो वे सभी .claude/ में मौजूद कुछ फ़ाइलें और डायरेक्टरीज़ होते हैं। यदि आप इसकी संरचना को नहीं समझते हैं, और "मेरी कॉन्फ़िगर की गई अनुमतियाँ लागू क्यों नहीं हुईं" या "टीम के साथियों ने कोड पुल किया लेकिन मेरी कमांड्स नहीं हैं" जैसी समस्याओं का सामना करते हैं, तो आप केवल असहाय रह जाएंगे।

जब मैंने शुरुआत की थी, तब मैंने एक मूर्खतापूर्ण काम किया था: आसानी के लिए, मैंने एक डेटाबेस पासवर्ड वाला कॉन्फ़िगरेशन सीधे .claude/settings.json में लिख दिया, और इसे git push के साथ पुश कर दिया। जब मुझे एहसास हुआ, तब तक रहस्य (secret) पहले ही रिपॉजिटरी इतिहास में जा चुका था—अंत में मुझे पासवर्ड बदलना पड़ा, इतिहास को फिर से लिखना पड़ा, और आधे घंटे से अधिक समय बर्बाद हुआ। बाद में मुझे समझ में आया कि ऐसी चीज़ों को settings.local.json में रखा जाना चाहिए था, उस फ़ाइल को Claude Code डिफ़ॉल्ट रूप से आपके लिए gitignore कर देता है। एक फ़ाइल गलत जगह रखने से इतना बड़ा अंतर आ सकता है।

यह लेख आपको यह नहीं सिखाएगा कि प्रत्येक फ़ाइल को गहराई से कैसे कॉन्फ़िगर किया जाए (वे बाद के समर्पित लेखों के लिए हैं), यह केवल एक काम करता है: आपको एक पैनोरमिक मैप देना, ताकि आप किसी फ़ाइल को देखकर जान सकें कि "यह क्या करती है, इसे कहाँ रखना है, यह प्रोजेक्ट की है या मेरी है, और क्या इसे कमिट करना चाहिए"।

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

.claude/ डायरेक्टरी का एक पैनोरमिक मैप: प्रत्येक फ़ाइल / सबडायरेक्टरी क्या प्रबंधित करती है
"प्रोजेक्ट-स्तरीय (Project)" और "उपयोगकर्ता-स्तरीय (User)" कॉन्फ़िगरेशन के बीच बुनियादी अंतर (प्रोजेक्ट के साथ जाता है vs आपके साथ जाता है)
एक चीट शीट: किन चीज़ों को git में कमिट करना चाहिए, और किन चीज़ों को .gitignore में होना चाहिए
एक त्वरित हैंड्स-ऑन अनुभव, जिससे आप खुद देख सकें कि ये दोनों स्तर की डायरेक्टरीज़ कैसी दिखती हैं

01 पहले एक बात समझें: Claude Code के "दो घर" हैं

पहले निष्कर्ष देते हैं: Claude Code के कॉन्फ़िगरेशन को दो भागों में रखा जाता है—एक भाग प्रोजेक्ट के साथ जाता है, दूसरा भाग आपके साथ जाता है। अगर आप यह समझ गए, तो बाकी सब आसान हो जाएगा।

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

डिस्क पर इसका मतलब दो स्थान हैं:

यह भाग	कहाँ है	किसको प्रभावित करता है	किसके साथ जाता है
प्रोजेक्ट-स्तरीय (Project)	प्रोजेक्ट में `./.claude/`	इस रिपॉजिटरी के सभी सहयोगियों (collaborators) को	प्रोजेक्ट के साथ (git में कमिट होता है, टीम के साथ शेयर होता है)
उपयोगकर्ता-स्तरीय (User)	आपकी होम डायरेक्टरी में `~/.claude/`	आपको, आपके सभी प्रोजेक्ट्स में	आपके साथ (आपकी मशीन पर, कभी कमिट नहीं होता)

यहाँ दो शब्द हैं जिन्हें पहले स्पष्ट करना चाहिए:

प्रोजेक्ट-स्तरीय (Project scope): कॉन्फ़िगरेशन रिपॉजिटरी में सेव होता है, git में जाता है, और पूरी टीम के साथ शेयर होता है। यदि आप नियम बदलते हैं और कमिट करते हैं, तो टीम के साथी जब पुल करेंगे तो यह लागू हो जाएगा।

उपयोगकर्ता-स्तरीय (User scope): कॉन्फ़िगरेशन आपकी होम डायरेक्टरी ~/.claude/ में सेव होता है, यह केवल आप पर लागू होता है, और कभी भी किसी रिपॉजिटरी में नहीं जाता है। यदि आप कंपनी के किसी भी प्रोजेक्ट पर जाते हैं, तो यह सेट आपके साथ रहता है।

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

💡 संक्षेप में: Claude Code के "दो घर" हैं—प्रोजेक्ट में ./.claude/ (प्रोजेक्ट के साथ जाता है, git में जाता है, टीम शेयर करती है) और होम डायरेक्टरी में ~/.claude/ (आपके साथ जाता है, git में नहीं जाता है, केवल आप पर लागू होता है)।

02 प्रोजेक्ट-स्तरीय `.claude/` खोलें: इसमें क्या है

अब प्रोजेक्ट में उस ./.claude/ फ़ोल्डर को खोलकर देखते हैं। उपयोग में आ रहे एक प्रोजेक्ट की संरचना कुछ इस तरह दिखती है:

text

your-project/
├── CLAUDE.md                ← प्रोजेक्ट मैनुअल (इसे .claude/CLAUDE.md में भी रखा जा सकता है)
├── CLAUDE.local.md          ← आपकी व्यक्तिगत प्रोजेक्ट प्राथमिकताएँ (.gitignore में जाती हैं)
├── .mcp.json                ← टीम का साझा MCP सर्वर कॉन्फ़िगरेशन (git में जाता है)
└── .claude/
    ├── settings.json        ← टीम साझा कॉन्फ़िगरेशन: अनुमतियाँ, हुक्स (hooks), मॉडल डिफ़ॉल्ट्स
    ├── settings.local.json  ← आपका व्यक्तिगत कॉन्फ़िगरेशन ओवरराइड (स्वचालित रूप से gitignore)
    ├── commands/            ← कस्टम स्लैश कमांड्स, प्रत्येक .md एक /command है
    ├── rules/               ← मॉड्यूलर प्रोजेक्ट नियम (CLAUDE.md से अलग किए गए)
    ├── skills/              ← कौशल (Skills): जिन्हें / द्वारा कॉल किया जा सकता है या Claude द्वारा स्वचालित रूप से उपयोग किया जा सकता है
    └── agents/              ← उप-एजेंट (Subagents): स्वतंत्र संदर्भ (context) वाले विशेष सहायक

आइए एक-एक करके बताएं कि वे क्या करते हैं, इस लेख में केवल "वे क्या हैं, उन्हें कौन प्रबंधित करता है" इस पर चर्चा की जाएगी, उन्नत उपयोग के लिए अलग-अलग लेख हैं:

CLAUDE.md —— प्रोजेक्ट मैनुअल। जब भी Claude प्रोजेक्ट में प्रवेश करता है तो वह सबसे पहले इसी फ़ाइल को पढ़ता है। प्रोजेक्ट क्या है, इसे कैसे चलाना है, इसके क्या कन्वेंशन हैं, सब कुछ यहाँ लिखा होता है। इसमें और .claude/settings.json में एक मूलभूत अंतर है: CLAUDE.md Claude के लिए एक "गाइड" (निर्देश) है (वह इसे पढ़ता है और इसका पालन करने की कोशिश करता है, लेकिन यह कोई सख्त बाधा नहीं है), जबकि settings.json एक "कॉन्फ़िगरेशन" है जिसे Claude Code सख्ती से लागू करता है।

आधिकारिक दस्तावेज़ में एक विवरण है: CLAUDE.md को प्रोजेक्ट की रूट डायरेक्टरी में रखें, या .claude/CLAUDE.md में रखें—बाद वाला तरीका प्रोजेक्ट की रूट डायरेक्टरी को थोड़ा साफ़ रखने में मदद करता है।

CLAUDE.local.md —— आपकी व्यक्तिगत प्रोजेक्ट प्राथमिकताएँ। यह CLAUDE.md के ऊपर लागू होता है, और केवल आपसे संबंधित निर्देश हैं, जैसे "मेरा लोकल डेटाबेस 5433 पोर्ट पर है"। इसे मैन्युअल रूप से .gitignore में जोड़ना होगा (जब आप /init चलाते हैं और व्यक्तिगत विकल्प चुनते हैं तो यह आपके लिए इसे जोड़ देगा)।

settings.json —— टीम का साझा कॉन्फ़िगरेशन सेंटर। यह नियंत्रित करता है कि क्या Claude कुछ विशिष्ट ऑपरेशन्स कर सकता है (अनुमतियाँ), किन समयों पर आपके स्क्रिप्ट चलाने हैं (hooks), और इस प्रोजेक्ट के लिए डिफ़ॉल्ट रूप से किस मॉडल का उपयोग करना है। यह git में जाता है, यह टीम की सुरक्षा बेसलाइन है।

settings.local.json —— आपका व्यक्तिगत कॉन्फ़िगरेशन ओवरराइड। यह ऊपर वाले के समान JSON फ़ॉर्मेट है, लेकिन यह केवल आप पर लागू होता है, और कमिट नहीं होता है। यदि आप किसी अनुमति को अस्थायी रूप से देना चाहते हैं, लेकिन टीम के साथियों को प्रभावित नहीं करना चाहते हैं, तो इसे यहाँ लिखें। जब Claude Code पहली बार इस फ़ाइल को लिखता है, तो वह स्वचालित रूप से git को इसे इग्नोर करने के लिए कॉन्फ़िगर कर देगा—यह वही फ़ाइल है जिसका उपयोग किया जाना चाहिए था लेकिन छूट गई, जिसका उल्लेख मैंने शुरुआत में किया था।

यहाँ एक आधिकारिक विवरण है: यह इग्नोर रूल को आपके ग्लोबल ~/.config/git/ignore (न कि प्रोजेक्ट के .gitignore) में जोड़ता है, इसलिए यदि आप प्रोजेक्ट के .gitignore को देखते हैं, तो आपको यह लाइन नहीं मिलेगी। यदि आप चाहते हैं कि पूरी टीम इसे इग्नोर करे, तो आपको इसे प्रोजेक्ट के .gitignore में स्वयं जोड़ना होगा।

commands/ —— कस्टम स्लैश कमांड्स। इस डायरेक्टरी में प्रत्येक .md फ़ाइल, एक /फ़ाइलनाम कमांड बन जाती है। उस निर्देश को सेव करें जिसे आप बार-बार टाइप करते हैं, अगली बार आप उसे कॉल करने के लिए / टाइप कर सकते हैं। आधिकारिक तौर पर commands/ और skills/ को एक ही अंतर्निहित तंत्र में एकीकृत कर दिया गया है, नई कमांड्स बनाने के लिए skills/ का उपयोग करने की सिफारिश की जाती है (जो अटैच्ड फ़ाइलों की पैकेजिंग का समर्थन करता है), commands/ कम्पैटिबिलिटी के लिए रहेगा लेकिन अब अनुशंसित पथ नहीं है।

rules/ —— मॉड्यूलर प्रोजेक्ट नियम। जब CLAUDE.md बहुत लंबा हो जाता है (आधिकारिक रूप से इसे 200 पंक्तियों के भीतर रखने की सलाह दी जाती है), तो नियमों को विषय के अनुसार rules/ के अंतर्गत कई फ़ाइलों में विभाजित करें, जैसे testing.md, api-design.md।

skills/ —— कौशल (Skills)। प्रत्येक कौशल एक सबडायरेक्टरी है जिसमें एक SKILL.md होता है। इसे आप मैन्युअल रूप से /कौशल_का_नाम द्वारा कॉल कर सकते हैं, या कार्य के आधार पर Claude स्वचालित रूप से निर्णय ले सकता है कि इसका उपयोग करना है या नहीं।

agents/ —— उप-एजेंट (Subagents)। प्रत्येक .md एक विशेष सहायक को परिभाषित करता है जिसमें एक स्वतंत्र संदर्भ विंडो (context window) होता है, जिससे मुख्य वार्तालाप गंदा नहीं होता। यह समानांतर रूप से काम करने या कार्यों को अलग करने के लिए उपयुक्त है।

.mcp.json —— टीम का साझा MCP सर्वर कॉन्फ़िगरेशन। इसे प्रोजेक्ट के रूट में रखा जाता है, .claude/ के साथ। MCP (Model Context Protocol) सर्वर को दो स्थानों पर कॉन्फ़िगर किया जा सकता है: यहाँ का .mcp.json git में कमिट होता है और पूरी टीम के साथ शेयर होता है, जैसे कि डेटाबेस टूल्स या आंतरिक API जो टीम को चाहिए; जबकि व्यक्तिगत MCP कॉन्फ़िगरेशन (जैसे वे टूल्स जो केवल आप उपयोग कर रहे हैं) ~/.claude.json में सहेजे जाते हैं, जो किसी रिपॉजिटरी में नहीं जाएंगे। दोनों के बीच का अंतर है: प्रोजेक्ट-साझा बनाम व्यक्तिगत उपयोग।

💡 संक्षेप में: प्रोजेक्ट-स्तरीय .claude/ में, CLAUDE.md / rules/ Claude के लिए "निर्देश" हैं, settings.json "सख्ती से लागू किया गया कॉन्फ़िगरेशन" है, और commands/ skills/ agents/ आपके द्वारा जोड़े गए "एक्सटेंशन्स" हैं।

03 वही डायरेक्टरीज़, `~/.claude/` में भी एक सेट है

यह शुरुआती लोगों को सबसे ज़्यादा कन्फ्यूज़ करने वाला हिस्सा है, लेकिन असल में सबसे सरल है: ऊपर दिए गए डायरेक्टरी नाम, उपयोगकर्ता-स्तरीय ~/.claude/ में लगभग वैसे ही मौजूद होते हैं।

commands/、rules/、skills/、agents/、CLAUDE.md、settings.json——ये प्रोजेक्ट में हैं, और ~/.claude/ में भी हैं। केवल एक ही अंतर है:

(उपयोगकर्ता-स्तरीय ~/.claude/ में कुछ अनोखी डायरेक्टरीज़ भी हैं जो प्रोजेक्ट स्तर पर नहीं हैं—themes/, keybindings.json, output-styles/, workflows/ आदि, इन्हें बाद के लेखों में एक-एक करके पेश किया जाएगा।)

~/.claude/ के अंतर्गत रखी गई चीज़ें, आपके सभी प्रोजेक्ट्स पर लागू होती हैं; प्रोजेक्ट के ./.claude/ के अंतर्गत रखी गई चीज़ें, केवल उसी एक प्रोजेक्ट पर लागू होती हैं।

दो उपयोग के उदाहरण आपको समझा देंगे:

एक /commit-hi कमांड (हिंदी में कमिट मैसेज जनरेट करने के लिए), जिसे ~/.claude/commands/ में रखा गया है——इस तरह इसे किसी भी प्रोजेक्ट में इस्तेमाल किया जा सकता है, हर प्रोजेक्ट में इसे फिर से कॉन्फ़िगर करने की ज़रूरत नहीं है।
लेकिन "कंपनी के टेस्ट एनवायरनमेंट में डिप्लॉय करें" जैसी कमांड, जो स्पष्ट रूप से केवल उस एक प्रोजेक्ट से संबंधित है, इसे प्रोजेक्ट के .claude/commands/ में रखें, और पूरी टीम के उपयोग के लिए कमिट करें।

इन "जुड़वां" डायरेक्टरीज़ के अलावा, ~/ होम डायरेक्टरी में दो और फ़ाइलें हैं जो केवल उपयोगकर्ता स्तर पर दिखाई देती हैं, और जिन्हें आपको आमतौर पर मैन्युअल रूप से छूने की आवश्यकता नहीं होती, बस उन्हें पहचान लें:

फ़ाइल / डायरेक्टरी	कहाँ है	क्या है	क्या आपको इसे प्रबंधित करना है
`~/.claude.json`	होम डायरेक्टरी	एप्लिकेशन स्थिति: लॉगिन स्थिति (OAuth session), थीम, व्यक्तिगत MCP सर्वर, प्रत्येक प्रोजेक्ट के लिए विश्वास रिकॉर्ड और UI प्राथमिकताएँ	लगभग कभी नहीं छूते, `/config` के माध्यम से बदलते हैं
`~/.claude/projects/`	उपयोगकर्ता-स्तरीय	प्रत्येक प्रोजेक्ट के वार्तालाप रिकॉर्ड; स्वचालित मेमोरी (auto memory) इसी के `<प्रोजेक्ट>/memory/` सबडायरेक्टरी में रखी जाती है	लिखने की आवश्यकता नहीं, यह खुद को मेंटेन करता है

यहाँ स्वचालित मेमोरी (auto memory) के बारे में एक बात जोड़ते हैं: यह और CLAUDE.md दो अलग-अलग चीज़ें हैं। CLAUDE.md आपके द्वारा Claude के लिए लिखे गए निर्देश हैं; स्वचालित मेमोरी Claude द्वारा खुद के लिए लिखे गए नोट्स हैं (जैसे कि उसने आपकी बिल्ड कमांड्स को समझ लिया है, या जिन गड्ढों में वह गिरा है), जो ~/.claude/projects/<प्रोजेक्ट>/memory/ के तहत सहेजे जाते हैं, और सेशन्स के बीच पुन: उपयोग किए जाते हैं। इन दोनों में कन्फ्यूज़ न हों: एक आप लिखते हैं, एक वह लिखता है।

💡 संक्षेप में: commands/ skills/ जैसी डायरेक्टरीज़ के प्रोजेक्ट-स्तरीय और उपयोगकर्ता-स्तरीय दोनों सेट हैं, अंतर केवल "एक प्रोजेक्ट को प्रबंधित करने" या "आपके सभी प्रोजेक्ट्स को प्रबंधित करने" में है; ~/.claude.json और ~/.claude/projects/ उपयोगकर्ता के लिए विशिष्ट हैं, और आपको आमतौर पर इन्हें मैन्युअल रूप से नहीं छूना चाहिए।

04 किसे git में जाना चाहिए, किसे कभी कमिट नहीं करना चाहिए

यह अनुभाग सबसे व्यावहारिक है, शुरुआत में जो सीक्रेट लीक होने का उल्लेख किया गया था, वह यहीं की गलती थी। पहला और सबसे कड़ा नियम: 'local' नाम वाली या सीक्रेट्स वाली कोई भी चीज़ git में नहीं जाएगी।

कुछ चीज़ें क्यों कमिट की जाती हैं और कुछ क्यों नहीं? तर्क बहुत सरल है—जो टीम के साथ साझा करना है उसे कमिट करें, जो केवल आपसे या आपकी इस मशीन से संबंधित है उसे कमिट न करें।

उपमा: प्रोजेक्ट फ़ाइल कैबिनेट में जो चीज़ें हैं, उन्हें इन्वेंट्री में दर्ज किया जाना चाहिए (git में), आपके डेस्क दराज में व्यक्तिगत सामान को सौंपने की आवश्यकता नहीं है।

प्रोजेक्ट में सामान्य फ़ाइलों को इस आधार पर वर्गीकृत करें कि "क्या उन्हें कमिट किया जाना चाहिए", इस टेबल का पालन करें और आपसे गलती नहीं होगी:

फ़ाइल / डायरेक्टरी	git में?	क्यों
`CLAUDE.md`	✅ कमिट करें	टीम साझा प्रोजेक्ट मैनुअल
`.claude/settings.json`	✅ कमिट करें	टीम की साझा अनुमतियाँ / कॉन्फ़िगरेशन बेसलाइन
`.claude/commands/*.md`	✅ कमिट करें	टीम द्वारा पुन: उपयोग की जाने वाली मानकीकृत कमांड्स
`.claude/rules/*.md`	✅ कमिट करें	टीम के साझा मॉड्यूलर नियम
`.claude/skills/`、`.claude/agents/`	✅ कमिट करें	टीम के साझा कौशल और उप-एजेंट
`.claude/settings.local.json`	❌ कमिट न करें	व्यक्तिगत ओवरराइड; Claude Code स्वचालित रूप से आपके लिए इसे gitignore कर देता है
`CLAUDE.local.md`	❌ कमिट न करें	व्यक्तिगत प्रोजेक्ट प्राथमिकताएँ; आपको मैन्युअल रूप से `.gitignore` में जोड़ना होगा
कोई भी फ़ाइल जिसमें सीक्रेट्स / टोकन / पासवर्ड हों	❌ कभी कमिट न करें	रिपॉजिटरी इतिहास में जाने का मतलब है लीक होना

कुछ व्यावहारिक अनुस्मारक:

settings.local.json के लिए gitignore की चिंता न करें। आधिकारिक तौर पर यह स्पष्ट रूप से लिखा गया है: जब Claude Code इस फ़ाइल को बनाता है, तो यह स्वचालित रूप से git को इसे इग्नोर करने के लिए कॉन्फ़िगर करेगा। यदि आप स्थानीय रूप से किसी अनुमति को अस्थायी रूप से खोलना चाहते हैं, तो इसे यहाँ लिखना सबसे सुरक्षित है।

CLAUDE.local.md के लिए आपको खुद .gitignore जोड़ना होगा। यह settings.local.json जैसा नहीं है, यह स्वचालित रूप से इग्नोर नहीं किया जाएगा—/init चलाते समय "व्यक्तिगत" विकल्प चुनने पर यह आपके लिए जोड़ दिया जाएगा, अन्यथा मैन्युअल रूप से एक लाइन जोड़ना न भूलें।

सीक्रेट्स को कभी भी कॉन्फ़िगरेशन फ़ाइलों में हार्डकोड न करें। आधिकारिक रूप से अनुशंसित तरीका है कॉन्फ़िगरेशन में पर्यावरण चर (environment variables) का उपयोग करना, जैसे ${GITHUB_TOKEN} लिखना न कि टोकन को प्लेनटेक्स्ट में पेस्ट करना—जब Claude Code शुरू होता है तो यह इसे आपके शेल वातावरण से पढ़ता है, टोकन फ़ाइल में कभी नहीं होता है। इस सलाह का सख्ती से पालन करें।

💡 संक्षेप में: टीम-साझा (जैसे CLAUDE.md, settings.json, commands/ आदि) git में जाते हैं; "local" वाली और कोई भी सीक्रेट्स वाली फ़ाइलें कभी कमिट न करें—settings.local.json सिस्टम द्वारा स्वचालित रूप से इग्नोर किया जाता है, CLAUDE.local.md को आपको मैन्युअल रूप से जोड़ना होगा।

05 कॉन्फ़िगरेशन में टकराव होने पर किसकी सुनें: प्राथमिकता का एक चार्ट

आपने शायद एक समस्या के बारे में सोचा होगा: यदि उपयोगकर्ता-स्तरीय settings.json और प्रोजेक्ट-स्तरीय settings.json दोनों में एक ही सेटिंग है, तो किसकी मानी जाएगी?

आधिकारिक रूप से दी गई प्राथमिकता का क्रम इस प्रकार है (उच्चतम से निम्नतम):

text

Managed (संगठन द्वारा प्रबंधित, सबसे अधिक, कोई इसे ओवरराइड नहीं कर सकता)
  ↓
कमांड लाइन पैरामीटर (जैसे --permission-mode, केवल वर्तमान सत्र के लिए)
  ↓
Local (settings.local.json)
  ↓
Project (प्रोजेक्ट settings.json)
  ↓
User (उपयोगकर्ता ~/.claude/settings.json, सबसे कम)

याद रखने का तरीका: जो जितना अधिक "विशिष्ट" है, और "वर्तमान ऑपरेशन के जितना करीब" है, उसकी प्राथमिकता उतनी ही अधिक होगी। संगठन का नियम > आपने इस बार कमांड लाइन में क्या निर्दिष्ट किया > इस प्रोजेक्ट में आपका स्थानीय > प्रोजेक्ट का साझा > आपका वैश्विक डिफ़ॉल्ट।

.claude डायरेक्टरी: प्रोजेक्ट-स्तरीय vs उपयोगकर्ता-स्तरीय

यह चित्र दोनों पेड़ों को एक साथ दिखाता है: बाईं ओर प्रोजेक्ट-स्तरीय ./.claude/ (प्रोजेक्ट के साथ जाता है, टीम साझा करने के लिए आवश्यकतानुसार git में जाता है), दाईं ओर उपयोगकर्ता-स्तरीय ~/.claude/ (आपके साथ जाता है, आपके सभी प्रोजेक्ट्स को प्रबंधित करता है)—यह याद रखें कि कौन सा पेड़ क्या प्रबंधित करता है, तो बाद में कॉन्फ़िगरेशन कहाँ रखना है, इसमें कोई भ्रम नहीं होगा।

लेकिन यहाँ एक बहुत आसानी से होने वाली गलती है, जिसे अलग से बताना ज़रूरी है—सभी सेटिंग्स "ओवरराइड" लॉजिक का पालन नहीं करती हैं:

सेटिंग का प्रकार	जब एकाधिक स्कोप एक साथ मौजूद हों	उदाहरण
स्केलर मान (Scalar, एकल मान)	सबसे विशिष्ट वाले को लेता है, ओवरराइड (Override)	`model`: प्रोजेक्ट में सेट है तो प्रोजेक्ट वाले का उपयोग होगा
ऐरे मान (Array, सूची)	स्कोप्स के पार मर्ज (Merge) होता है, ओवरराइड नहीं	`permissions.allow`: उपयोगकर्ता का + प्रोजेक्ट का + स्थानीय का अध्यारोपण (superposition)

इस अंतर से नुकसान होना बहुत आसान है: मैं खुद एक बार इसमें फंस गया था—मैंने उपयोगकर्ता-स्तरीय settings.json में किसी कमांड को deny कर दिया था, यह सोचकर कि यह अब विश्व स्तर पर अक्षम (disabled) है, लेकिन जब मैंने एक प्रोजेक्ट में काम किया तो वह कमांड बिना किसी रोक-टोक के चल गई, मैं कॉन्फ़िगरेशन को काफी देर तक घूरता रहा लेकिन समझ नहीं पाया। बाद में मुझे समझ में आया कि, अनुमति नियम मर्ज होते हैं, ओवरराइड नहीं, अगर प्रोजेक्ट-स्तर पर allow किया गया है, तो यह उपयोगकर्ता-स्तरीय नियमों के साथ ओवरलैप होगा और मूल्यांकन किया जाएगा। इसलिए उपयोगकर्ता-स्तर पर अनुमतियों को "पूरी तरह से ब्लॉक" करने की उम्मीद न करें, मर्जिंग नियमों को समझना ज़रूरी है।

💡 संक्षेप में: प्राथमिकता उच्चतम से निम्नतम है: Managed → कमांड लाइन → Local → Project → User; लेकिन यह अंतर समझें—model जैसे स्केलर "ओवरराइड" होते हैं, जबकि permissions.allow जैसे ऐरे "मर्ज और अध्यारोपित" होते हैं।

06 हैंड्स-ऑन: इन दो स्तरों की डायरेक्टरीज़ को अपनी आँखों से देखें

केवल तस्वीरें देखने से बेहतर है खुद एक्सप्लोर करना। नीचे दी गई कमांड्स का सेट केवल पढ़ने के लिए है, बहुत सुरक्षित है, इन्हें टाइप करके आप "दो घरों" को स्पष्ट रूप से समझ सकते हैं।

पहला कदम: अपनी होम डायरेक्टरी में उपयोगकर्ता-स्तरीय ~/.claude/ को देखें

टर्मिनल खोलें, और टाइप करें (Mac / Linux):

bash

ls -a ~/.claude

Windows PowerShell के लिए उपयोग करें:

powershell

dir $HOME\.claude

अपेक्षित परिणाम: आपको settings.json, projects, और शायद commands, skills आदि दिखाई देंगे—यह इस बात पर निर्भर करता है कि आप Claude Code का कितनी गहराई से उपयोग करते हैं। जब तक कुछ चीज़ें सूचीबद्ध हैं, इसका मतलब है कि उपयोगकर्ता-स्तरीय यह "घर" मौजूद है और काम कर रहा है।

दूसरा कदम: किसी प्रोजेक्ट में प्रोजेक्ट-स्तरीय .claude/ को देखें

किसी भी प्रोजेक्ट में cd करें जहाँ आपने Claude Code चलाया हो (यदि नहीं, तो /init का उपयोग करके एक बनाने के लिए पिछले लेख पर वापस जाएँ), और फिर:

bash

ls -a .claude

अपेक्षित परिणाम: कम से कम settings.local.json (यदि आपने पहले अनुमतियों को मंज़ूरी दी है) दिखाई देगा, और संभवतः settings.json भी। यह प्रोजेक्ट-स्तरीय "फ़ाइल कैबिनेट" है, जो होम डायरेक्टरी वाले से अलग है।

तीसरा कदम: सत्यापित करें कि settings.local.json वास्तव में git द्वारा इग्नोर किया गया है

इस प्रोजेक्ट में (यह एक git रिपॉजिटरी होनी चाहिए), टाइप करें:

bash

git check-ignore .claude/settings.local.json

अपेक्षित परिणाम: टर्मिनल इस फ़ाइल का पथ (path) आउटपुट करेगा (.claude/settings.local.json), जो यह साबित करता है कि इसे git द्वारा पहले ही इग्नोर कर दिया गया है—यही काम Claude Code ने आपके लिए स्वचालित रूप से किया है। यदि कुछ भी आउटपुट नहीं होता है, तो इसका मतलब है कि इसे इग्नोर नहीं किया गया है, और आपको मैन्युअल रूप से इस लाइन को .gitignore में जोड़ना चाहिए।

चौथा कदम (वैकल्पिक): प्रोजेक्ट मैनुअल पर एक नज़र डालें

bash

cat CLAUDE.md

(Windows PowerShell के लिए type CLAUDE.md का उपयोग करें)

अपेक्षित परिणाम: पिछले लेख के /init द्वारा जनरेट की गई सामग्री को प्रिंट करेगा। यह वह फ़ाइल है जिसे Claude प्रोजेक्ट में प्रवेश करते ही सबसे पहले पढ़ता है, अब आप जानते हैं कि यह कहाँ स्थित है।

⚠️ एक अनुस्मारक: git check-ignore का केवल git रिपॉजिटरी में अर्थ होता है। यदि इस प्रोजेक्ट में अभी तक git init नहीं किया गया है, तो यह कमांड fatal: not a git repository रिपोर्ट करेगा, परीक्षण करने से पहले इसे एक git रिपॉजिटरी बनाएं।

💡 संक्षेप में: ls -a ~/.claude उपयोगकर्ता-स्तर को देखने के लिए, ls -a .claude प्रोजेक्ट-स्तर को देखने के लिए, git check-ignore .claude/settings.local.json इग्नोरेंस को सत्यापित करने के लिए—ये तीन केवल-पढ़ने वाली कमांड्स, आपको "दो घरों" और "किसे git द्वारा इग्नोर किया गया है" को एक बार में स्पष्ट रूप से दिखा देंगी।

07 सारांश

इस लेख में हमने प्रोजेक्ट में Claude Code के "घर के सामान" को समझ लिया है। आइए इसे संक्षेप में देखें:

जो आपको याद रखना है	विशेष रूप से क्या है
दो घर	प्रोजेक्ट `./.claude/` (प्रोजेक्ट के साथ जाता है, git में जाता है) + होम डायरेक्टरी `~/.claude/` (आपके साथ जाता है, git में नहीं जाता)
निर्देश vs कॉन्फ़िगरेशन	`CLAUDE.md` / `rules/` Claude के लिए निर्देश हैं; `settings.json` सख्ती से लागू किया जाने वाला कॉन्फ़िगरेशन है
जुड़वां डायरेक्टरीज़	`commands/` `skills/` `agents/` प्रोजेक्ट और उपयोगकर्ता स्तर दोनों पर मौजूद हैं, अंतर यह है कि क्या यह एक प्रोजेक्ट को प्रबंधित करता है या सभी को
git की रेड लाइन	"local" वाली या सीक्रेट्स वाली कोई भी चीज़, कभी कमिट न करें; `settings.local.json` सिस्टम द्वारा स्वचालित रूप से इग्नोर किया जाता है
प्राथमिकता	Managed → कमांड लाइन → Local → Project → User; स्केलर ओवरराइड होते हैं, ऐरे मर्ज होते हैं

अब आप सक्षम होने चाहिए: किसी भी प्रोजेक्ट को खोलने और .claude/ में किसी फ़ाइल को देखकर जानने के लिए कि वह क्या करती है, क्या यह प्रोजेक्ट की है या आपकी, और क्या इसे कमिट किया जाना चाहिए; और यह भी कि कॉन्फ़िगरेशन में टकराव होने पर किसकी सुननी चाहिए। यह पैनोरमिक मैप बाद के सभी समर्पित लेखों के लिए बेस मैप है—बाद में जब आप सीखेंगे कि settings.json को बारीकी से कैसे कॉन्फ़िगर करें, CLAUDE.md को कैसे अच्छे से लिखें, कौशल और उप-एजेंट कैसे बनाएं, तो आप इस मैप पर उनके स्थान को ढूंढ पाएंगे।

अगला लेख 14 "इंटरफ़ेस और शॉर्टकट्स"—डायरेक्टरी संरचना का यह "स्टेटिक मैप" समझ में आ गया, इसके बाद हमें Claude Code के "ऑपरेशन पैनल" से परिचित होना होगा। अगला लेख आपको इंटरफ़ेस के प्रत्येक भाग से परिचित कराएगा, और सबसे अधिक उपयोग किए जाने वाले शॉर्टकट्स को आपकी मांसपेशियों की स्मृति (muscle memory) में डाल देगा, ताकि आप तेज़ी से और सटीकता से काम कर सकें।

प्रोजेक्ट संरचना: Claude Code आपके प्रोजेक्ट में क्या रखता है ​

01 पहले एक बात समझें: Claude Code के "दो घर" हैं ​

02 प्रोजेक्ट-स्तरीय .claude/ खोलें: इसमें क्या है ​

03 वही डायरेक्टरीज़, ~/.claude/ में भी एक सेट है ​

04 किसे git में जाना चाहिए, किसे कभी कमिट नहीं करना चाहिए ​

05 कॉन्फ़िगरेशन में टकराव होने पर किसकी सुनें: प्राथमिकता का एक चार्ट ​

06 हैंड्स-ऑन: इन दो स्तरों की डायरेक्टरीज़ को अपनी आँखों से देखें ​

07 सारांश ​

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

प्रोजेक्ट संरचना: Claude Code आपके प्रोजेक्ट में क्या रखता है

01 पहले एक बात समझें: Claude Code के "दो घर" हैं

02 प्रोजेक्ट-स्तरीय `.claude/` खोलें: इसमें क्या है

03 वही डायरेक्टरीज़, `~/.claude/` में भी एक सेट है

04 किसे git में जाना चाहिए, किसे कभी कमिट नहीं करना चाहिए

05 कॉन्फ़िगरेशन में टकराव होने पर किसकी सुनें: प्राथमिकता का एक चार्ट

06 हैंड्स-ऑन: इन दो स्तरों की डायरेक्टरीज़ को अपनी आँखों से देखें

07 सारांश

अनुशंसित पठन