अब तक के पाँच अध्यायों में हमने Claude Code इंस्टॉल किया, निर्देश दिए, अटकनों से निकले, और परमिशन डिज़ाइन की। यह अध्याय ख़ुद टूल को ही नए सिरे से गढ़ने की बात है। एक्सटेंशन के नाम याद कर लेने भर से वे इस्तेमाल नहीं होते। काम आती है वह तालिका जो बताए कि "अभी जो शिकायत है, वह किससे हल होगी"।
किसे कब चुनें ― चार सवालों से तय हो जाता है
एक्सटेंशन छह हैं, पर सोचने की बातें बस चार। गुज़ारिश से काम चल जाएगा क्या / पक्के तौर पर लागू करवाना है क्या / अलग संदर्भ में बाँटना है क्या / बाहर से जोड़ना है क्या ― इसी क्रम में ख़ुद से पूछ लें, तो जवाब लगभग हमेशा एक ही निकलता है।
कभी-कभार छूट भी जाए तो कोई बड़ी बात न हो, तो शब्द ही काफ़ी हैं। → CLAUDE.md (पूरे प्रोजेक्ट की मान्यताएँ) / Skills (किसी ख़ास काम का तरीक़ा)
एक बार भी छूट जाए तो दिक़्क़त हो, तो व्यवस्था से रोकिए। → hooks। ये मॉडल के विवेक से गुज़रे बिना हमेशा चलते हैं।
ढेर सारे आउटपुट से मुख्य धारा नहीं भरनी, तो काम बाहर करवाइए और सिर्फ़ नतीजा लीजिए। → subagents
वह जानकारी चाहिए जो AI को पता चल ही नहीं सकती (डेटाबेस की मौजूदा वैल्यू, इशू ट्रैकर का भीतरी हाल)। → MCP
पाँचवाँ सवाल है "क्या यह दूसरों को भी बाँटना है" ― बाँटना हो तो plugins। सबसे ज़्यादा घालमेल Q1 और Q2 में होता है, यानी CLAUDE.md, Skills और hooks में। ये तीनों एक जैसे दिखते हैं, पर इनका फ़र्क़ है कब पढ़े जाते हैं और चलाता कौन है।
CLAUDE.md ― न मिटने वाली याद। पर लंबी की तो मिट जाती है
CLAUDE.md प्रोजेक्ट की जड़ में रख दें तो वह ऐसी फ़ाइल बन जाती है जो हर सेशन में अपने आप पढ़ी जाती है (सारे प्रोजेक्ट में साझा करनी हो तो ~/.claude/CLAUDE.md)। फ़ाइल होने की वजह से, अध्याय 1 वाला "लंबा खिंचे तो शुरुआती हिस्सा भूल जाता है" इस पर लागू नहीं होता। यह उन बातों की जगह है जो आप हर बार समझाते रहते हैं।
"पढ़ लिया कहता है पर पालन नहीं करता" कोई आलस नहीं, ढाँचे की समस्या है, और इसकी तीन वजहें हैं।
- बीच का हिस्सा डूब जाता है ― लंबे टेक्स्ट के बीचोंबीच पड़े निर्देश आसानी से छूट जाते हैं, और आप जितना बढ़ाएँगे, बीच के नियम असल में उतने ही ग़ायब होते जाएँगे
- दबाव में सारांश बन जाता है ― जब कॉन्टेक्स्ट दबाया जाता है तो बारीक इस्तेमाल-नियम कुचल जाते हैं। पिछले हिस्से में उल्लंघन ज़्यादा दिखने की वजह यही है
- ताज़ा निर्देश जीत जाता है ― "अभी के अभी कमिट कर दो" कहने पर, सैकड़ों टर्न पहले पढ़ा गया पुष्टि का तरीक़ा यूँ ही छूट जाता है
इलाज है काटना। तजुर्बे से जो पक्के तौर पर काम करता है वह है क़रीब 100 से 150 लाइन तक। इससे ऊपर जाना पड़े तो सिर्फ़ जानलेवा नियम शुरू में रखिए और ब्योरा अलग फ़ाइल में डालिए (दोहराव फ़ासले पैदा करता है, इसलिए असली प्रति एक ही जगह रखिए)। जिन्हें गिराया ही नहीं जा सकता उन्हीं पर "CRITICAL" लगाइए, और उन्हें "ध्यान से लिखो" की तरह नहीं, "तीन लाइन के भीतर लिखो" की तरह बाहर से परखे जा सकने वाले रूप में लिखिए।
"मैंने पढ़ लिया" कोई सबूत नहीं है। परखने का आधार सिर्फ़ चलाने के बाद का बर्ताव है। जो नियम कितनी भी बार दोबारा लिखने पर भी नहीं माने जाते, वे लिखने के ढंग की समस्या नहीं हैं ― वह अगले अनुभाग का काम है।
hooks ― गुज़ारिश नहीं, पक्के तौर पर लागू
".env मत बदलना" ― CLAUDE.md में लिख दें तो नब्बे फ़ीसदी बार पालन हो जाएगा। दस फ़ीसदी छूटने से भी दिक़्क़त न हो तो वाक्य काफ़ी है। दिक़्क़त हो तो hooks ― यही बँटवारे की जगह है।
hooks वे शेल कमांड हैं जो तय मौक़ों पर अपने आप चलती हैं। इन्हें चलाता मॉडल नहीं, ख़ुद Claude Code (हार्नेस) है, इसलिए ये किसी विवेक का इंतज़ार किए बिना हमेशा चलती हैं। पूरी तस्वीर Claude Code hooks क्या हैं में है। जाने-पहचाने मौक़े नौ हैं।
SessionStart शुरू या दोबारा शुरू होने पर
UserPromptSubmit आपके भेजते ही [रोक सकता है]
PreToolUse टूल से ठीक पहले = द्वारपाल [रोक सकता है]
PostToolUse टूल के सफल होने के बाद = फ़ॉर्मैटिंग [रोक सकता है]
Notification इनपुट या मंज़ूरी का इंतज़ार
Stop जवाब का अंत [रोक सकता है]
SubagentStop सबएजेंट पूरा हुआ [रोक सकता है]
SessionEnd सेशन ख़त्म
PreCompact दबाव से पहले [रोक सकता है]
"रोक सकता है" का मतलब है कि उस जगह पर काम को रोका जा सकता है। PreToolUse पर ख़तरनाक कमांड को दरवाज़े से ही लौटा दीजिए, और PostToolUse पर अपने आप फ़ॉर्मैटिंग करवाइए ― यही दोनों घुसने के आम रास्ते हैं। सेटिंग settings.json की "hooks" कुंजी के नीचे जाती है, और फ़ाइल कहाँ रखी है इससे उसका दायरा तय होता है (~/.claude/ = आप, .claude/ = साझा, settings.local.json = सिर्फ़ आप)।
{ "hooks": {
"PostToolUse": [
{ "matcher": "Edit|Write",
"hooks": [ { "type": "command", "command": "..." } ] }
] } }
ढाँचा यह है ― इवेंट का नाम → मैचर और कमांड की एक सूची। matcher लक्ष्य टूल का नाम है (| से अलग किया हुआ, जैसे "Edit|Write"; छोड़ दें तो सब पर लगेगा)। कोई हुक स्टैंडर्ड इनपुट पर JSON लेता है और एग्ज़िट कोड से जवाब देता है ― 0 यानी सफल, 2 यानी रोक दो (स्टैंडर्ड एरर Claude को थमा दिया जाता है)। लक्ष्य फ़ाइल का पाथ भी उसी इनपुट JSON में होता है, इसलिए "पाथ यह हो तो रोक दो" लिखा जा सकता है।
हुक पाबंदी कस तो सकते हैं, ढीली नहीं कर सकते। वे अनुमति लौटा भी दें तो बस पुष्टि छूटती है, और मना करने वाले नियम हमेशा ऊपर रहते हैं। PreToolUse की मनाही उस मोड में भी असर करती है जो सारी मंज़ूरियाँ छोड़ देता है, इसलिए अध्याय 5 में जितनी ढील दी थी, उसके नीचे यह एक फ़र्श की तरह काम आती है।
क़ीमत भी पहले ही जान लीजिए। hooks आपके अपने अधिकारों के साथ कोई भी शेल कमांड अपने आप चला देते हैं। आधिकारिक दस्तावेज़ में भी साफ़ लिखा है कि "ज़िम्मेदारी पूरी तरह आपकी है"। सिर्फ़ भरोसेमंद चीज़ें सेट कीजिए, और इनपुट की जाँच कीजिए। सेटिंग सेशन शुरू होते वक़्त तय हो जाती है, इसलिए "ठीक तो कर दिया पर असर नहीं हो रहा" जैसी हालत में एक नया सेशन खोलिए।
subagents ― संदर्भ अलग करके सौंपना
टेस्ट का पूरा आउटपुट, या कोई विशाल लॉग ― वह ढेर सारा टेक्स्ट जिसे पढ़कर फेंक देना था जमा होता जाए, तो असली मान्यताएँ बाहर धकेल दी जाती हैं। subagents वह व्यवस्था है जो उस काम को किसी और कॉन्टेक्स्ट में चलाती है और आपको सिर्फ़ नतीजे का सारांश थमाती है। उनकी अपनी कॉन्टेक्स्ट विंडो, अपना सिस्टम प्रॉम्प्ट और अपनी टूल परमिशन होती है, और वे आपकी बातचीत का इतिहास देखते ही नहीं, इसलिए छानबीन का कचरा मुख्य सेशन में लौटता नहीं।
- अलग करना फ़ायदेमंद है ― चौड़ी छानबीन / ढेर सारा आउटपुट पैदा करने वाली जाँच / ऐसे अपने में पूरे काम जिनका बस नतीजा चाहिए
- अलग करना घाटे का है ― सिलसिलेवार काम / बार-बार की आवाजाही / एक ही फ़ाइल को छूने वाले समांतर काम / एक-दो चाल में निपट जाने वाले सुधार
यह एक मानक सुविधा है, इसलिए बिना किसी सेटिंग के इस्तेमाल हो जाती है। अपनी परिभाषा जोड़नी हो तो .claude/agents/<नाम>.md में (साझा करनी हो तो ~/.claude/agents/ में) YAML फ़्रंटमैटर के साथ name / description / tools / model लिखिए। संभालने के लिए /agents, और बुलाने के लिए @agent-<नाम>। शुरुआत मानक खोज वाले, प्लान वाले और सामान्य एजेंट से कीजिए।
description ही बुलावे की चाबी है। मुख्य एजेंट इसी को देखकर तय करता है कि काम सौंपे या नहीं, इसलिए यह धुँधला हुआ तो वह एक बार भी नहीं बुलाया जाएगा। क्या करता है और कब इस्तेमाल करना है ― दोनों ठोस लिखिए। यही जाल Skills में भी है।
इससे मिलता-जुलता एक Agent Teams भी है, जिसमें कई आज़ाद सेशन एक साझा टास्क लिस्ट के ज़रिए मिलकर काम करते हैं। यह प्रयोगात्मक है, ऑप्ट-इन है, और डिफ़ॉल्ट में बंद है (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1)। इसमें अलग इंस्टेंस चलते हैं, इसलिए टोकन की खपत बड़ी होती है, और इन्हें एक-दूसरे के भीतर भी नहीं रखा जा सकता। फ़र्क़ की तुलना subagents और Agent Teams का फ़र्क़ में की गई है। उलझन हो तो एक ही सेशन या subagents।
Skills ― तरीक़ों को पूँजी बना लेना
"हर बार इसी तरीक़े से" वाले तयशुदा कामों के लिए, Skills की ख़ूबी यह है कि वे सिर्फ़ ज़रूरत पड़ने पर खुलती हैं। असल में यह एक फ़ोल्डर है जिसके केंद्र में SKILL.md होती है। ऊपर name और description, उसके नीचे तरीक़ा Markdown में, और साथ में reference/ तथा scripts/ भी रखे जा सकते हैं। इसे बस .claude/skills/ (प्रोजेक्ट) या ~/.claude/skills/ (साझा) में रख देने भर से यह पहचान ली जाती है।
असल बात है चरणबद्ध खुलासा। सेशन शुरू होते वक़्त हर स्किल का सिर्फ़ छोटा-सा description पढ़ा जाता है, और अनुरोध से मेल खाने पर ही उसका मुख्य हिस्सा और सामग्री लोड होती है। इसीलिए आप दर्जनों डाल दें तब भी रोज़मर्रा का संदर्भ लगभग नहीं भरता ― CLAUDE.md से, जो हमेशा पूरी की पूरी चढ़ी रहती है, यही निर्णायक फ़र्क़ है। और इसका उलटा यह है कि मेल न खाए तो वह ज़िंदगी भर नहीं खुलेगी। description धुँधला हुआ, तो आपका लिखा तरीक़ा होने और न होने में कोई फ़र्क़ नहीं। लिखने का ढंग Claude Agent Skills क्या हैं में देखा गया है।
एक लाइन में। CLAUDE.md = वे मान्यताएँ जो हमेशा पढ़ी जाती हैं, Skills = वह मार्गदर्शिका जिसे Claude ख़ुद तय करके खोलता है, hooks = वह प्रक्रिया जो हमेशा चलती ही है।
MCP ― बाहर के सिस्टम तक हाथ बढ़ाना
अब तक के तीनों एक्सटेंशन तरीक़ा बदलते थे। सिर्फ़ MCP (Model Context Protocol) ऐसा है जो छूने का दायरा बढ़ाता है ― यह वह मानक है जो हाथ को वहाँ तक पहुँचाता है जहाँ AI ढाँचागत रूप से पहुँच ही नहीं सकता, जैसे डेटाबेस की मौजूदा वैल्यू या इशू ट्रैकर के टिकट। जुड़ने के रूप दो हैं, और दोनों में अटकने की जगह अलग है।
- लोकल (stdio) ― अपने ही कंप्यूटर पर सर्वर को एक सब-प्रोसेस के रूप में चलाना। यहाँ अटकता है चालू होना ख़ुद (पाथ, एनवायरनमेंट वेरिएबल, कमांड का हल होना)
- रिमोट (HTTP) ― क्लाउड पर मौजूद सर्वर से URL के ज़रिए जुड़ना। यहाँ अटकता है लगभग हमेशा प्रमाणीकरण, यानी 401 या 403 लौट रहा होता है
इसीलिए "जुड़ता नहीं" को एक ही ढेर में मत डालिए, पहले /mcp से स्टेटस देखिए। failed हो तो लोकल का चालू होना, needs authentication हो तो रिमोट का प्रमाणीकरण, और pending approval हो तो मंज़ूरी का इंतज़ार ― स्टेटस ही अगली चाल तय करता है। इलाज MCP सर्वर कनेक्शन एरर कैसे ठीक करें में समेटा गया है।
इसके अपने ख़ास जाल भी हैं। साझा सेटिंग वाली .mcp.json रिपॉज़िटरी की जड़ में होती है (न .claude/ के नीचे, न settings.json के भीतर), और API की हर सर्वर के अपने env में जाती है। Windows पर npx असल में एक बैच फ़ाइल है, इसलिए उसे cmd के ज़रिए /c npx ... की तरह थमाने पर काम चल जाता है।
जो सर्वर आपने जोड़े हैं वे कॉन्टेक्स्ट खाते हैं। टूल की परिभाषाएँ जमा होते जाने भर से संदर्भ पर दबाव पड़ता है। समझदारी इसी में है कि जिन सर्वर का इस्तेमाल नहीं हो रहा उन्हें बंद रखिए।
plugins ― पूरा सेट बाँधकर बाँटना
स्किल, सबएजेंट की परिभाषाएँ, हुक और MCP की सेटिंग ― ये सब बिखरने लगें, तो उन्हें बाँधकर बाँटने लायक़ रूप देना ही plugins है। ग़लती सबसे ज़्यादा डायरेक्टरी के नियमों में होती है। मैनिफ़ेस्ट .claude-plugin/plugin.json है, और .claude-plugin/ में सिर्फ़ वही जाता है। skills/, agents/, hooks/hooks.json और .mcp.json जड़ में रखे जाते हैं।
/plugin marketplace add owner/repo ← कैटलॉग दर्ज कीजिए
/plugin install name@marketplace ← उसमें से एक-एक करके इंस्टॉल कीजिए
/plugin list ← जो लगे हुए हैं उन्हें देखिए
इंस्टॉल दो चरणों में होता है। कैटलॉग दर्ज कीजिए, और उसके बाद एक-एक करके इंस्टॉल कीजिए ― सिर्फ़ जोड़ देने से कुछ भी नहीं लगता। दायरा user (सारे प्रोजेक्ट), project (सारे साथ काम करने वाले), local (सिर्फ़ आप) या managed (व्यवस्थापक की तरफ़ से बाँटा हुआ, बदला नहीं जा सकता) हो सकता है, और टीम में एक जैसा रखना हो तो project। ख़ुद बनाने का तरीक़ा plugins और marketplace क्या हैं में देखा गया है।
प्लगइन आपके अपने अधिकारों के साथ कोई भी कोड चला सकता है ― यह आधिकारिक दस्तावेज़ में साफ़ लिखा है। Anthropic तीसरे पक्ष के प्लगइन या उनके साथ आए MCP सर्वर की जाँच नहीं करता। सिर्फ़ भरोसेमंद प्रकाशकों की चीज़ें लगाइए। अध्याय 5 वाली परमिशन डिज़ाइन यहाँ दूसरों के लिखे कोड की शक्ल में लौटकर आ जाती है।
शुरुआत किससे करें ― क्रम की बात
हमने छह चीज़ें सामने रखीं, पर सब लगाने की ज़रूरत नहीं है। जब तक कोई दिक़्क़त ही न हो, तब लगा देने से सिर्फ़ सेटिंग की उलझन बढ़ती है। क्रम लक्षण से तय कीजिए।
- हर बार वही बात समझा रहे हैं → CLAUDE.md। सिर्फ़ किसी ख़ास काम की बात हो तो Skills
- लिख तो दिया पर पालन नहीं होता → पहले काटिए। जिनसे असल नुक़सान होता है सिर्फ़ उन्हें hooks में डालिए
- संदर्भ फ़ौरन भर जाता है → भारी छानबीन subagents को दीजिए, और बेकार MCP बंद कीजिए
- जानकारी तक AI पहुँच ही नहीं पाता → MCP। एक-एक करके जोड़िए, और एक के चलने के बाद ही अगला
- वही सेटिंग बाँटनी है → plugins। सिर्फ़ वही बाँधिए जो ख़ुद चलाकर देख चुके हैं
- कोई ख़ास दिक़्क़त नहीं है → कुछ भी मत लगाइए। यही सबसे अच्छी हालत है
आख़िरी लाइन मज़ाक़ नहीं है। एक्सटेंशन अटकने की वजहें भी बढ़ाते हैं ― "Claude Code कुछ अजीब हो गया है" की असलियत अक्सर वही परत निकलती है जो आपने ख़ुद जोड़ी थी। इसीलिए पहले अध्याय 4 वाली छानबीन।
सारांश
- चुनने का आधार हैं चार सवाल ― गुज़ारिश से काम चल जाएगा क्या (CLAUDE.md, Skills) / पक्के तौर पर लागू करवाना है क्या (hooks) / अलग संदर्भ में बाँटना है क्या (subagents) / बाहर से जोड़ना है क्या (MCP)। बाँटना हो तो plugins
- CLAUDE.md वह याद है जो सेशन पार कर जाती है। लंबी करेंगे तो बीच का हिस्सा डूबेगा, दबाव में पतली पड़ेगी, और ताज़ा निर्देश से हार जाएगी। काटिए और प्राथमिकता साफ़ कीजिए
- hooks हार्नेस चलाता है, इसलिए उनमें कोई विवेक बीच में नहीं आता। ये पाबंदी कस सकते हैं, ढीली नहीं कर सकते
- subagents किसी और कॉन्टेक्स्ट में काम करते हैं और सिर्फ़ सारांश लौटाते हैं। सिलसिलेवार काम और बार-बार की आवाजाही के लिए ये ठीक नहीं
- Skills तभी खुलती हैं जब
descriptionमेल खाए ― यही चरणबद्ध खुलासा है। इन्हें बढ़ाना सस्ता है, पर विवरण धुँधला हुआ तो वे बुलाई ही नहीं जाएँगी - MCP वह मानक है जो छूने का दायरा बढ़ाता है।
/mcpका स्टेटस ही अगली चाल तय करता है - plugins बाँटने का डिब्बा है। दूसरों का कोड आपके अपने अधिकारों से चलता है, इसलिए प्रकाशक जाँच लीजिए
- लगाने का क्रम लक्षण से तय होता है। दिक़्क़त पैदा होने के बाद, एक-एक करके
जितना बढ़ाते जाएँगे, खपत उतनी बढ़ेगी। आख़िर में हम उस संचालन की बात करेंगे जो इसे लंबे समय तक चलाते रहने के लिए चाहिए। अब अध्याय 7 "लागत और सीमाएँ" पर बढ़ें।