फ़ीचर कैसे चुनें: CLAUDE.md vs Skill vs Hook vs MCP vs Subagent
📚 सीरीज नेविगेशन: पिछला लेख 29 Agent teams 智能体团队 आपको Agent teams का उपयोग करके मल्टी-एजेंट समानांतर सहयोग चलाना सिखाता है। यह लेख पूरे चौथे समूह को समेटता है—CLAUDE.md, Skill, Hook, MCP, Subagent को एक साथ सीखने के बाद, सब कुछ दिमाग में जमा हो जाने पर गलत विकल्प चुनना आसान हो जाता है। मैं आपको एक निर्णय तालिका (decision table) और एक निर्णय वृक्ष (decision tree) दूंगा, बस अपनी 'आवश्यकता' के अनुसार सीधे देखें कि 'किसका उपयोग करना है', और कोई उलझन नहीं रहेगी।
दोस्तों, यहाँ तक सीखने के बाद, आपके पास पहले से ही कई एक्सटेंशन पॉइंट जमा हो गए हैं।
CLAUDE.md, Skill, Hook, MCP, Subagent और हर जगह दिखने वाले स्लैश कमांड (slash command), ये पांच-छह शब्द हैं,軐हें अलग से देखने पर हर कोई समझ जाता है। लेकिन जब बात आती है कि "मेरी इस आवश्यकता के लिए मुझे किसका उपयोग करना चाहिए", तो दस में से नौ बार लोग अटक जाते हैं। जिन लोगों ने अभी-अभी इसे सीखा है, वे अक्सर पूछते हैं, "क्या इसके लिए Skill का उपयोग करें या Subagent का?" "क्या मैं इसे CLAUDE.md में लिख सकता हूँ?"
साफ शब्दों में कहें तो, यह ज्ञान की कमी नहीं है, बल्कि "आवश्यकता → समाधान" का मैपिंग स्थापित न होना है। आपने प्रत्येक एक्सटेंशन पॉइंट का आधिकारिक परिचय पढ़ा है, लेकिन वे इस आधार पर व्यवस्थित हैं कि "यह क्या है", न कि "आप क्या करना चाहते हैं"। यह लेख इसके विपरीत काम करता है—आपकी आवश्यकता से शुरू करके, पीछे की ओर जाकर यह तय करता है कि किसका उपयोग करना है।
इसे इस तरह समझें: पिछले नौ लेखों में आपके हाथ में एक-एक करके पांच हथियार सौंपे गए थे, और यह लेख आपको सिखाता है कि मैदान में उतरने पर कौन सा हथियार निकालना है।
इस लेख को पढ़ने के बाद, आपको मिलेगा:
- पांच प्रमुख एक्सटेंशन पॉइंट (और slash command) में से प्रत्येक के लिए "यह क्या हल करता है, इसे कब चुनना है, और इसे कब इस्तेमाल नहीं करना है" की एक-पंक्ति की स्थिति
- एक "आवश्यकता → अनुशंसित समाधान" निर्णय तालिका, अपनी समस्या के अनुसार समाधान खोजने के लिए
- एक निर्णय वृक्ष जिसे आप फ़ॉलो कर सकते हैं, तीन-चार प्रश्नों के बाद यह स्पष्ट हो जाएगा कि किसका उपयोग करना है
- कुछ सबसे आसानी से भ्रमित होने वाली तुलनाएं (Skill vs Subagent, CLAUDE.md vs Skill, Hook vs अनुमति नियम) जिन्हें एक बार में स्पष्ट किया जाएगा
- यह जानना कि इन एक्सटेंशन पॉइंट्स को कैसे संयोजित किया जाए और उन्हें एक plugin में कैसे पैक किया जाए
01 पहले एक समग्र ढांचा बनाएं: छह एक्सटेंशन पॉइंट "एजेंट लूप" में विभिन्न स्थानों पर प्लग किए गए हैं
चुनने से पहले, अपने दिमाग में एक समग्र ढांचा तैयार करें। ये एक्सटेंशन पॉइंट छह समानांतर विकल्प नहीं हैं, बल्कि Claude कार्यप्रवाह के विभिन्न चरणों में प्लग किए गए छह हुक हैं।
लेख 03 में चर्चा किए गए "एजेंट लूप" को याद करें—Claude का काम "सोचना → करना → देखना" का एक चक्र है। ये छह एक्सटेंशन पॉइंट (CLAUDE.md, Skill, slash command, MCP, Subagent, Hook) इस चक्र में विभिन्न स्थानों पर ठीक से प्लग किए गए हैं: कुछ "सोचने" से पहले पृष्ठभूमि में जोड़े जाते हैं, कुछ "करने" के दौरान बाहरी कनेक्शन या क्लोन बनाते हैं, और कुछ एक निश्चित समय पर स्वचालित रूप से ट्रिगर होते हैं। आधिकारिक वाक्य बहुत सटीक है और इसे याद रखने योग्य है:
एक्सटेंशन एजेंट लूप के विभिन्न हिस्सों में इंसर्ट होते हैं।
एनालॉजी: अस्पताल का ट्राइएज डेस्क (triage desk)。 जब आप अस्वस्थ महसूस करते हैं और अस्पताल जाते हैं, तो आप सीधे किसी विभाग में नहीं जाते हैं, बल्कि पहले ट्राइएज डेस्क पर जाकर अपने "लक्षण" बताते हैं—सिरदर्द के लिए न्यूरोलॉजी, पेट दर्द के लिए गैस्ट्रोएंटरोलॉजी, और एक्स-रे के लिए रेडियोलॉजी। ट्राइएज डेस्क इलाज नहीं करता है, यह आपके लक्षणों के आधार पर आपको सही विभाग में निर्देशित करता है। इस लेख में, मैं आपके लिए इस ट्राइएज डेस्क के रूप में काम कर रहा हूँ: आप अपनी "आवश्यकता" बताएं, और मैं आपको सही "एक्सटेंशन पॉइंट" पर ले जाऊंगा।
वास्तविक परिदृश्यों में, आप अक्सर इन्हीं बातों को लेकर उलझते हैं: "मैं चाहता हूँ कि यह हर बार किसी नियम का पालन करे", "जरूरत पड़ने पर यह स्वचालित रूप से किसी विशेष विशेषज्ञता को कॉल करे", "किसी विशेष समय पर स्वचालित रूप से कुछ हो", "इसे बाहरी डेटा या सेवाओं से जोड़ा जाए"। एक बार आवश्यकता स्पष्ट हो जाने पर, सही विभाग चुनना बहुत कठिन नहीं होता। निम्नलिखित अनुभागों में, प्रत्येक "विभाग" का विस्तार से परिचय दिया जाएगा, और अंत में आपको एक समग्र तालिका और एक निर्णय वृक्ष दिया जाएगा।
💡 एक-पंक्ति का सारांश: छह एक्सटेंशन पॉइंट छह में से एक चुनने वाले समानांतर विकल्प नहीं हैं, बल्कि "सोचना → करना → देखना" के विभिन्न चरणों में प्लग किए गए हुक हैं; चुनने की कुंजी यह नहीं है कि "कौन सा शक्तिशाली है", बल्कि यह है कि "आपकी आवश्यकता को कहाँ प्लग किया जाना चाहिए"。
02 छह विभाग, एक वाक्य में प्रत्येक के "मुख्य उपचार" को पहचानें
पहले एक वाक्य में छह एक्सटेंशन पॉइंट्स के "मुख्य कार्यक्षेत्र" को समझें। यह अनुभाग आधारशिला है, और नीचे दी गई निर्णय तालिका पूरी तरह से इसी पर निर्मित है। मैं आधिकारिक फ़ीचर तालिका के विवरण के अनुसार प्रत्येक के लिए सबसे विशिष्ट परिदृश्य प्रदान करूँगा।
CLAUDE.md —— वे नियम जिन्हें यह "हर बार याद रखे"。 परियोजना समझौते, बिल्ड कमांड, "हमेशा pnpm का उपयोग करें, npm का नहीं", "सबमिट करने से पहले परीक्षण चलाएं" जैसे नियम जो हमेशा प्रभावी रहते हैं। यह प्रत्येक सत्र (session) में स्वचालित रूप से लोड होता है, और Claude काम शुरू करते ही इसे देख सकता है।
Skill —— वह विशेष क्षमता जिसे यह "आवश्यकता होने पर स्वचालित रूप से कॉल करे"。 पुनः प्रयोज्य ज्ञान या प्रक्रियाएं: एक API शैली गाइड, एक परिनियोजन (deployment) चेकलिस्ट, एक डिबगिंग पैटर्न। सामान्यतः यह केवल विवरण पाठ (description text) लेता है, और उपयोग किए जाने पर ही पूरी सामग्री लोड की जाती है; आप /<name> का उपयोग करके भी इसे सक्रिय रूप से कॉल कर सकते हैं।
slash command —— एक निश्चित प्रक्रिया जिसे आप "سक्रिय रूप से एक-क्लिक से ट्रिगर करते हैं"。 यह वास्तव में Skill का ही एक उपयोग है (वह जो /<name> के साथ ट्रिगर होता है)। अंतर केवल इस बात में है कि "इसे कौन शुरू करता है": Claude स्वचालित रूप से यह तय कर सकता है कि Skill का उपयोग करना है या नहीं, जबकि slash command वह है जहाँ आप सक्रिय रूप से /deploy टाइप करके इसे कॉल करते हैं。
MCP —— इसे "बाहरी दुनिया से जोड़ने" वाला इंटरफ़ेस。 आपके डेटाबेस की जांच करना, Slack पर संदेश भेजना, ब्राउज़र को नियंत्रित करना—वह सब कुछ जो Claude के अंतर्निहित (built-in) टूल की पहुंच से बाहर है और जिसके लिए बाहरी सेवाओं या डेटा से जुड़ने की आवश्यकता होती है, वह MCP के माध्यम से होता है (विवरण के लिए लेख 22 देखें)。
Subagent —— कठिन काम करने के लिए इसे एक "स्वतंत्र क्लोन" देना。 जब दर्जनों फ़ाइलें पढ़ने, बड़े पैमाने पर खोज करने की आवश्यकता हो, लेकिन आप केवल एक निष्कर्ष चाहते हैं और नहीं चाहते कि मध्यवर्ती प्रक्रिया मुख्य बातचीत को भर दे, तो एक Subagent भेजें (विवरण के लिए लेख 23 देखें)。यह अलग संदर्भ (context) में काम करता है और काम पूरा होने पर केवल सारांश वापस भेजता है。
Hook (हुक) —— एक निश्चित समय पर "स्वचालित रूप से ट्रिगर होना"。 Hook का मतलब है "कोई घटना घटित होने पर स्वचालित रूप से चलने वाली क्रियाओं का एक समूह"。जैसे ही कोई लाइफसाइकल इवेंट ट्रिगर होता है (जैसे "हर बार फ़ाइल को संशोधित करने के बाद" या "हर बार सत्र शुरू होने पर"), यह बिना किसी असफलता के निष्पादित होता है—linter चलाना, खतरनाक कमांड को अस्वीकार करना, या अधिसूचना भेजना。यह Claude की सोच पर निर्भर नहीं करता है, इसका ट्रिगर होना सुनिश्चित है।
Hook की इस अवधारणा पर पहले विस्तार से चर्चा नहीं की गई है, यहाँ बस एक बुनियादी समझ बना लें: यह "घटना-ट्रिगर स्वचालित क्रिया" है。इसका पूरा सिंटैक्स और यह किन घटनाओं को सुन सकता है, इसे लेख 33 में विस्तार से समझाया जाएगा।
केवल शब्दों से भ्रमित होना आसान है, इसलिए यहाँ एक तुलनात्मक तालिका दी गई है जिससे यह तुरंत स्पष्ट हो जाएगा:
| एक्सटेंशन पॉइंट | एक-पंक्ति का मुख्य बिंदु | कौन ट्रिगर करता है | क्या यह स्थायी संदर्भ लेता है |
|---|---|---|---|
| CLAUDE.md | परियोजना के नियम जिनका हर बार पालन किया जाना चाहिए | स्वचालित, प्रति सत्र लोड | हाँ (पूरी सामग्री स्थायी रहती है) |
| Skill | आवश्यकतानुसार बुलाई जाने वाली विशेष जानकारी / प्रक्रिया | Claude स्वचालित रूप से निर्णय लेता है या आप /<name> | कम (आमतौर पर केवल विवरण स्थान लेता है) |
| slash command | सक्रिय रूप से एक-क्लिक से ट्रिगर होने वाली निश्चित प्रक्रिया | आप /xxx | कम (Skill की तरह) |
| MCP | बाहरी सेवाओं / डेटा को जोड़ना | जब Claude टूल का उपयोग करता है | कम (शुरू में केवल टूल नाम लेता है) |
| Subagent | अलग संदर्भ / समानांतर विशेष कार्य | आप या Claude काम सौंपते हैं | मुख्य विंडो में नहीं (स्वतंत्र संदर्भ) |
| Hook | विशिष्ट घटनाओं पर स्वचालित रूप से चलने वाली निश्चित क्रिया | लाइफसाइकल इवेंट | शून्य (जब तक कि यह आउटपुट वापस न करे) |
आपको इस तालिका को याद रखने की आवश्यकता नहीं है, लेकिन "कौन ट्रिगर करता है" और "क्या यह स्थायी संदर्भ लेता है" ये दो कॉलम भविष्य के सभी निर्णयों के लिए विभाजक रेखा हैं—एक यह तय करता है कि "क्या यह आपकी पहल है या इसकी स्वचालित प्रतिक्रिया", और दूसरा यह तय करता है कि "क्या इसे हमेशा चालू रखना सार्थक है"。
💡 一句话总结：六个扩展点的「主治」各不相同——规矩进 CLAUDE.md、专长做 Skill、一键流程是 slash command、外部连接靠 MCP、隔离干活派 Subagent、固定时机自动跑用 Hook。
03 निर्णय तालिका: आवश्यकता बताएं, समाधान पाएं
अब जब हमारे पास समग्र ढांचा है और मुख्य कार्यक्षेत्र स्पष्ट हैं, तो आइए इस लेख के मुख्य भाग पर आते हैं—"आश्यकता → अनुशंसित समाधान" निर्णय तालिका。इसका उपयोग करना बहुत सरल है: बाएं कॉलम में वह आवश्यकता खोजें जो आपके दिमाग में चल रही बात से सबसे अधिक मिलती-जुलती हो, दायां कॉलम अनुशंसित एक्सटेंशन पॉइंट दिखाएगा, और अंतिम कॉलम बताएगा कि "यह क्यों चुना गया है, और इसे किसी अन्य विकल्प के साथ भ्रमित क्यों नहीं किया जाना चाहिए"。
| आपकी आवश्यकता (आपके दिमाग की बात) | अनुशंसित समाधान | यह क्यों है / गलत विकल्प न चुनें |
|---|---|---|
| "हमेशा हमारे समझौते का पालन करें" (pnpm का उपयोग करें, सबमिट करने से पहले टेस्ट चलाएं) | CLAUDE.md | नियम जो हमेशा प्रभावी रहते हैं, ताकि यह इसे हर सत्र में देख सके |
| "यह API दस्तावेज़ / शैली गाइड जरूरत पड़ने पर उपलब्ध होना चाहिए" | Skill | संदर्भ सामग्री, सामान्यतः संदर्भ स्थान नहीं लेती, आवश्यकता होने पर ही कॉल की जाती है |
"मैं बस /deploy टाइप करके पूरा परिनियोजन प्रवाह चलाना चाहता हूँ" | slash command (एक प्रकार का Skill) | आपके द्वारा सक्रिय रूप से ट्रिगर की जाने वाली निश्चित बहु-चरणीय प्रक्रिया |
| "इसे हमारी कंपनी के डेटाबेस की जांच करने / Slack संदेश भेजने दें" | MCP | बाहरी सेवाओं और डेटा से जुड़ने की आवश्यकता है, अंतर्निहित टूल वहां तक नहीं पहुंच सकते |
| "इसे दर्जनों फ़ाइलें पढ़ने दें और मुझे केवल निष्कर्ष दें" | Subagent | संदर्भ अलगाव की आवश्यकता है, मध्यवर्ती प्रक्रिया को मुख्य विंडो को भरने से रोकने के लिए |
| "बिना किसी निर्भरता के इन कई चीजों की एक साथ जांच करें" | Subagent (समानांतर में कई) | समानांतर विशेष कार्य, प्रत्येक अपना काम करता है और केवल सारांश लौटाता है |
| "हर बार फ़ाइल को संशोधित करने के बाद स्वचालित रूप से ESLint चलाएं" | Hook (PostToolUse) | निश्चित समय पर स्वचालित क्रिया, इसके लिए सोचने की आवश्यकता नहीं है |
"rm -rf / जैसी कमांड्स को पूरी तरह से ब्लॉक करें" | Hook (PreToolUse) या अनुमति नियम | यह "सुनिश्चित" करना होगा कि इसे ब्लॉक किया जाए, केवल संकेतों (prompts) पर भरोसा नहीं किया जा सकता |
| "यह किसी समझौते को बार-बार भूल जाता है, इसे दो बार याद दिलाया जा चुका है" | CLAUDE.md | बार-बार होने वाली गलतियाँ, स्थायी नियमों में लिखी जानी चाहिए, न कि चैट में अस्थायी रूप से सुधारी जानी चाहिए |
| "मैं हर दिन वही प्रारंभिक संकेत (prompt) मैन्युअल रूप से टाइप करता हूँ" | Skill | बार-बार इनपुट किए जाने वाले संकेत, जिन्हें कॉल करने योग्य Skill के रूप में सहेजा जा सकता है |
| "मैं इस कॉन्फ़िगरेशन को हूबहू दूसरे प्रोजेक्ट में ले जाना चाहता हूँ" | Plugin (पैकेजिंग लेयर) | Skill / Hook / Subagent / MCP को एक साथ बांधकर ले जाने के लिए |
मैंने आधिकारिक "समय के साथ अपनी सेटिंग्स बनाएं" ट्रिगर तालिका की भावना को भी इसमें शामिल किया है: कई आवश्यकताएं वास्तव में "दोहराव" के कारण पैदा होती हैं—वही संकेत तीसरी बार टाइप करना, वही गलती दूसरी बार सुधारना, यह एक संकेत है कि इसे संबंधित एक्सटेंशन पॉइंट में "ठोस" कर दिया जाना चाहिए, न कि हमेशा बातचीत के दौरान निर्देश देने पर भरोसा किया जाए।
यहाँ एक सबसे आम जाल है जिसमें लोग फंसते हैं। सुविधा के लिए, लगभग तीन सौ पंक्तियों की API इंटरफ़ेस सूची को सीधे CLAUDE.md में डाल देना बहुत आसान है, यह सोचते हुए कि "इसे हमेशा याद रखना कितना आसान होगा"। परिणाम—हर बार सत्र शुरू होने पर यह संदर्भ (context) का एक बड़ा हिस्सा खा जाता है, और वास्तविक काम शुरू होने से पहले ही वर्कस्पेस का एक बड़ा हिस्सा भर जाता है; इससे भी बदतर, Claude अक्सर उन मुख्य समझौतों को नहीं पकड़ पाता जिन पर आप वास्तव में जोर देना चाहते हैं, क्योंकि वह इंटरफ़ेस विवरणों के ढेर में खो जाता है। इंटरफ़ेस सूची को एक Skill में ले जाएं, और CLAUDE.md में केवल एक पंक्ति छोड़ें: "इंटरफ़ेस विनिर्देशों के लिए api-skill देखें", और दुनिया तुरंत शांत हो जाएगी。यह वही बात है जिसे आधिकारिक तौर पर बार-बार दोहराया जाता है:
保持 CLAUDE.md 在 200 行以下。如果它在增长，将参考内容移到 skills。
💡 一句话总结：拿不准时，先把需求翻译成「心里那句话」，再来这张表对号入座；尤其记住「始终生效→CLAUDE.md、按需参考→Skill、外部连接→MCP、隔离干活→Subagent、固定时机→Hook」。
04 एक निर्णय वृक्ष: तीन-चार प्रश्नों के बाद, सीधे समाधान प्राप्त करें
तालिका तब काम आती है जब "आवश्यकता ज्ञात हो और समाधान खोजना हो", लेकिन कभी-कभी आपकी आवश्यकताएं स्वयं स्पष्ट नहीं होती हैं। ऐसे मामलों में, एक निर्णय वृक्ष (decision tree) का उपयोग करना अधिक सहज होता है—बस कुछ हाँ/ना प्रकार के प्रश्नों का उत्तर देते हुए नीचे जाएं, और अंतिम पत्ता (leaf) आपका उत्तर होगा。
मैंने निर्णय के क्रम को नीचे दिए गए पेड़ के रूप में डिज़ाइन किया है। इसके मूल में केवल चार प्रश्न हैं, और इस क्रम में पूछने पर आप लगभग कभी गलत नहीं होंगे:
यह आरेख "मेरी एक आवश्यकता है, मुझे किस एक्सटेंशन पॉइंट का उपयोग करना चाहिए" को ऊपर से नीचे के प्रश्न-उत्तर पथ में विभाजित करता है—पहले पूछें "क्या इसके लिए कड़े आश्वासन की आवश्यकता है या बाहरी कनेक्शन की", फिर पूछें "क्या इसे स्वचालित रूप से होना चाहिए या आपके द्वारा ट्रिगर किया जाना चाहिए", और अंत तक शाखाओं का अनुसरण करें, जहाँ प्रत्येक लीफ़ नोड एक विशिष्ट एक्सटेंशन पॉइंट का प्रतिनिधित्व करता है।
इस पेड़ को शब्दों में समझने पर, आप पाएंगे कि निर्णय लेने का क्रम वास्तव में बहुत स्वाभाविक है:
पहला प्रश्न: क्या इसके लिए "बाहरी सेवाओं या डेटा से जुड़ने" की आवश्यकता है?
हाँ—उदाहरण के लिए, डेटाबेस की जांच करना, Slack संदेश भेजना, या ब्राउज़र को नियंत्रित करना—तो सीधे MCP का उपयोग करें, और बात यहीं समाप्त होती है। इसे पहचानना सबसे आसान है, इसलिए इसे पहले ही फ़िल्टर कर दें।
दूसरा प्रश्न: क्या यह ऐसी चीज़ है जो "हर बार होनी चाहिए और इसे Claude के स्व-अनुशासन पर नहीं छोड़ा जा सकता"?
यदि आपको "आश्वासन" स्तर के प्रवर्तन (enforcement) की आवश्यकता है—जैसे कि ".env को संपादित करने की अनुमति बिल्कुल नहीं है", "rm -rf / को ब्लॉक किया जाना चाहिए", "हर बार फ़ाइल को संशोधित करने के बाद lint चलाना आवश्यक है"—तो Hook का उपयोग करें (या अनुमति नियम, अगला अनुभाग देखें)। मुख्य शब्द है "आश्वासन": Hook अपनी घटना पर हमेशा ट्रिगर होता है, यह निश्चित है; जबकि CLAUDE.md में लिखना केवल एक "अनुरोध" है, जिसका पालन Claude कर भी सकता है और भूल भी सकता है।
तीसरा प्रश्न: क्या यह कार्य "एक बार का कठिन काम है जिसे आप अलग रखना चाहते हैं"?
यदि आपको बहुत सारी फ़ाइलें पढ़नी हैं, बड़े पैमाने पर खोज करनी है, और आप केवल निष्कर्ष चाहते हैं, बिना इस प्रक्रिया से मुख्य बातचीत को भरे, या यदि आप कई चीजों को समानांतर में चलाना चाहते हैं—तो Subagent भेजें। यह एक स्वतंत्र संदर्भ में काम करता है और पूरा होने पर केवल सारांश वापस भेजता है।
यदि आप यहाँ तक पहुँच गए हैं और अभी तक कोई विकल्प नहीं चुना है, तो यह "ज्ञान / नियम / प्रक्रिया" में से कोई एक है, अब अंतिम प्रश्न पूछें:
चौथा प्रश्न: क्या इसे "हर बार दिखाई देना चाहिए", या "केवल आवश्यकता होने पर ही देखा जाना चाहिए"?
- नियम जिन्हें हर बार देखा जाना चाहिए (समझौते, बिल्ड कमांड, कभी न किया जाने वाला काम X) → CLAUDE.md。
- ज्ञान या प्रक्रियाएं जिन्हें केवल आवश्यकता होने पर ही देखा जाना चाहिए (API दस्तावेज़, परिनियोजन चेकलिस्ट, डिबगिंग पैटर्न) → Skill。
- इसके भीतर, "वह बहु-चरणीय प्रक्रिया जिसे आप सक्रिय रूप से एक-क्लिक से ट्रिगर करना चाहते हैं", उस Skill को
/<name>दें और इसे slash command के रूप में उपयोग करें।
चार प्रश्न, "पहचानने में सबसे आसान बाहरी कनेक्शन" से लेकर "ज्ञान बनाम नियम के सूक्ष्म अंतर" तक, एक-एक करके फ़िल्टर करते हुए अंततः उत्तर तक पहुँचते हैं。एक्सटेंशन पॉइंट चुनते समय, मूल रूप से अपने दिमाग में इन चार वाक्यों को दोहराएं।
💡 一句话总结：决策树的顺序是「连外部？→ 要硬保证？→ 要隔离？→ 每次看还是按需看？」，四问下来直达叶子，比死记一堆定义好用得多。
05三个最容易混淆的配对，一次讲透
केवल निर्णय वृक्ष होना ही पर्याप्त नहीं है, हमेशा कुछ ऐसे जोड़े होते हैं जो एक जैसे दिखते हैं और चुनने में उलझन पैदा करते हैं।मैंने शुरुआती लोगों द्वारा सबसे अधिक पूछे जाने वाले तीन जोड़ों को चुना है और उन्हें विस्तार से समझाया है। इन तीनों को स्पष्ट करने के बाद, निर्णय तालिका बिना किसी विरोधाभास के काम करेगी।
Skill vs Subagent
ये दोनों सबसे आसानी से भ्रमित होने वाले हैं क्योंकि "दोनों ही एक प्रक्रिया को समाहित कर सकते हैं"। लेकिन वे मौलिक रूप से अलग समस्याओं का समाधान करते हैं।
एनालॉजी: मैनुअल (manual) बनाम आउटसोर्सिंग (outsourcing)。 Skill एक साझा मैनुअल की तरह है जिसे कोई भी ज़रूरत पड़ने पर देख सकता है, और पढ़ने के बाद इसकी सामग्री आपके वर्तमान "कार्य नोट्स" में जुड़ जाती है; Subagent किसी व्यक्ति को काम पर बाहर भेजने जैसा है, जो काम पूरा होने के बाद केवल निष्कर्ष की रिपोर्ट करने वापस आता है, और उसने बाहर कितनी सामग्री पढ़ी है, इससे आपका कोई सीधा संबंध नहीं होता।
मुख्य अंतर केवल एक शब्द का है: संदर्भ (context)。
| तुलना का आयाम | Skill | Subagent |
|---|---|---|
| यह क्या है | पुनः प्रयोज्य ज्ञान / प्रक्रिया | स्वतंत्र संदर्भ के साथ एक अलग कार्यकर्ता |
| सामग्री कहाँ जाती है | आपकी मुख्य विंडो में लोड होती है | इसके अपने विंडो का उपयोग करती है, और केवल परिणाम मुख्य विंडो में वापस आते हैं |
| क्या मुख्य चैट प्रभावित होती है | मुख्य संदर्भ स्थान लेता है | अलग रहता है, मुख्य विंडो में लगभग कोई स्थान नहीं लेता |
| सबसे उपयुक्त | संदर्भ सामग्री, कॉल करने योग्य प्रक्रियाएं | बहुत सारी फ़ाइलें पढ़ने का काम, समानांतर कार्य, विशिष्ट कार्यकर्ता |
एक-पंक्ति में अंतर: यदि आप चाहते हैं कि "सामग्री यहाँ लोड हो और उपयोग की जाए" तो Skill चुनें, यदि आप चाहते हैं कि "प्रक्रिया यहाँ के वातावरण को प्रदूषित न करे और केवल निष्कर्ष मिले" तो Subagent चुनें。इन दोनों को मिलाया भी जा सकता है—Subagent शुरू होने पर निर्दिष्ट Skill को प्री-लोड कर सकता है, जो कि "बाहरी भेजे गए व्यक्ति के पास अपनी विशेष मैनुअल होने" जैसा है।
CLAUDE.md vs Skill
ये दोनों ही "निर्देशों को सहेजने" के लिए हैं, अंतर केवल लोड करने के तरीके में है।
| तुलना का आयाम | CLAUDE.md | Skill |
|---|---|---|
| यह कब लोड होता है | प्रत्येक सत्र में, स्वचालित रूप से | आवश्यकतानुसार (केवल उपयोग किए जाने पर लोड होता है) |
| क्या यह कार्यप्रवाह ट्रिगर कर सकता है | नहीं | हाँ, /<name> का उपयोग करके |
| सबसे उपयुक्त | "हमेशा X करें" वाले नियम | संदर्भ सामग्री, कॉल करने योग्य प्रक्रियाएं |
आधिकारिक निर्णय सूत्र बहुत सरल है: जो "Claude को हमेशा पता होना चाहिए" वह CLAUDE.md में जाता है, और जिसकी "केवल कभी-कभी जांच करने की आवश्यकता होती है" वह Skill में जाता है।धारा 03 में उल्लिखित "तीन सौ पंक्तियों के इंटरफ़ेस को CLAUDE.md में डालने" की गलती मूल रूप से उस चीज़ को CLAUDE.md में रखने के कारण हुई थी जो Skill में जानी चाहिए थी।
Hook vs अनुमति नियम
इस जोड़े में उलझन यह है: "किसी खतरनाक ऑपरेशन को ब्लॉक करने" के लिए आखिरकार Hook का उपयोग करें या अनुमति नियमों का (जिसकी चर्चा लेख 20 में deny के रूप में की गई है)?
पहले समानता की बात करते हैं: दोनों ही "प्रवर्तन" स्तर के कड़े प्रतिबंध हैं और Claude के स्व-अनुशासन पर निर्भर नहीं करते हैं—इस मामले में वे दोनों एक ही तरफ हैं, और "CLAUDE.md में लिखे गए अनुरोधों" से पूरी तरह से अलग हैं। आधिकारिक वाक्य ने इस मुख्य बिंदु को स्पष्ट किया है:
CLAUDE.md 或 skill 中的「永远不要编辑
.env」之类的说明是请求，而不是保证。阻止编辑的PreToolUsehook 是强制执行。
अंतर इस बात में है कि "प्रबंधन का दायरा कितना विस्तृत है और की जाने वाली क्रियाएं कितनी विविध हैं":
- अनुमति नियम: घोषणात्मक (declarative), विशेष रूप से यह प्रबंधित करते हैं कि "यह टूल / यह कमांड स्वीकार्य है या नहीं"。在 deny 规则里写一条
Bash(rm -rf *)（即 settings.json 的"deny": ["Bash(rm -rf *)"]）就拦死，简洁，适合纯粹的「准入判断」。 - Hook: एक स्क्रिप्ट चला सकता है, और "ब्लॉक करने" के अलावा अन्य काम भी कर सकता है—ब्लॉक करने के साथ ही एक लॉग रिकॉर्ड करना, एक अधिसूचना भेजना, या मापदंडों (parameters) को स्वचालित रूप से फिर से लिखना। यह "ब्लॉक करने + अतिरिक्त क्रियाओं" या जटिल निर्णयों के लिए उपयुक्त है जिन्हें अनुमति नियमों द्वारा व्यक्त नहीं किया जा सकता है।
एक उपयोगी व्यावहारिक नियम: "स्वीकार्य है या नहीं" जैसे स्पष्ट निर्णयों के लिए, अनुमति नियमों को प्राथमिकता दें, जो एक पंक्ति में काम पूरा कर देते हैं; यदि आप ब्लॉक करने के समय कुछ अतिरिक्त करना चाहते हैं (लॉगिंग, अधिसूचना, पुनः लिखना), तो Hook का उपयोग करें।दोनों में कोई टकराव नहीं है और इन्हें अक्सर एक साथ उपयोग किया जाता है—अनुमति नियम बुनियादी ढांचा तय करते हैं, और Hook उन कार्यों को पूरा करता है जहाँ "ब्लॉक करने के बाद कुछ और करने" की आवश्यकता होती है।
💡 一句话总结：Skill 进我上下文 / Subagent 隔离只给结论；CLAUDE.md 每次看 / Skill 按需看；权限规则管「准不准」黑白判断 / Hook 管「拦截 + 附带动作」——三组分清，选择不再打架。
06 संयोजन ही सामान्य स्थिति है: एकाधिक विकल्पों को एक साथ जोड़ना याद रखें
यहाँ तक पहुँचने के बाद, आप सोच सकते हैं कि एक्सटेंशन पॉइंट चुनना एक "एकल विकल्प" प्रश्न है। इसके ठीक विपरीत—वास्तविक परियोजनाओं में लगभग हमेशा इनका संयोजन होता है। प्रत्येक एक्सटेंशन पॉइंट वह काम करता है जिसमें वह सबसे अच्छा है, और उन्हें एक साथ जोड़कर ही "उपकरणों" का एक पूरा सेट बनता है।
आधिकारिक तौर पर दिए गए कुछ क्लासिक संयोजनों को मैं वास्तविक परिदृश्यों में अनुवाद करके समझाता हूँ:
| संयोजन | वे कैसे सहयोग करते हैं | वास्तविक रूप में यह कैसा दिखता है |
|---|---|---|
| Skill + MCP | MCP "कनेक्ट करने" के लिए ज़िम्मेदार है, और Skill "इसे अच्छी तरह से उपयोग करना सिखाने" के लिए | MCP डेटाबेस से कनेक्ट होता है, और Skill आपकी तालिका संरचना (table structure) और सामान्य क्वेरी पैटर्न को स्पष्ट करता है |
| Skill + Subagent | Skill के भीतर समानांतर में काम करने के लिए Subagent शुरू करना | एक /audit Skill एक ही समय में सुरक्षा, प्रदर्शन और शैली की जांच करने के लिए तीन Subagents भेजता है |
| CLAUDE.md + Skill | CLAUDE.md स्थायी नियमों को रखता है, और Skill आवश्यकतानुसार विवरण रखता है | CLAUDE.md में "हमारे API समझौतों का पालन करें" लिखा है, और Skill में वह पूरी शैली गाइड शामिल है |
| Hook + MCP | घटना ट्रिगर होने पर Hook, MCP के माध्यम से कुछ बाहरी काम करता है | महत्वपूर्ण फ़ाइलों को संशोधित करने के बाद, Hook स्वचालित रूप से MCP के माध्यम से Slack पर एक अधिसूचना भेजता है |
"Skill + MCP" संयोजन को देखकर आप समझ सकते हैं कि इसका क्या लाभ है: केवल MCP होने पर, Claude डेटाबेस से कनेक्ट तो हो सकता है, लेकिन वह यह नहीं समझता कि आपकी तालिकाओं को कैसे डिज़ाइन किया गया है और सबसे बेहतर तरीके से कैसे क्वेरी की जाए; केवल Skill होने पर, वह पैटर्न तो समझता है लेकिन डेटाबेस से कनेक्ट नहीं हो पाता।दोनों को मिलाने पर ही यह "कनेक्ट भी हो सकता है और अच्छी तरह उपयोग भी कर सकता है" बनता है। एक सामान्य कॉन्फ़िगरेशन इसी तरह बनाया जाता है—MCP डेटाबेस को कनेक्ट करता है, और Skill इस जानकारी से भरा होता है कि "उपयोगकर्ता ऑर्डर खोजने के लिए किस तालिका का उपयोग करना है, सांख्यिकीय माप कौन सा फ़ील्ड है", जिससे Claude द्वारा लिखी गई क्वेरीज़ में लगभग किसी संशोधन की आवश्यकता नहीं होती।
उस संयोजित कॉन्फ़िगरेशन को किसी अन्य प्रोजेक्ट में कैसे ले जाएं, या सहकर्मियों के साथ कैसे साझा करें? उत्तर है Plugin (प्लगइन) —— यह वह लेयर है जो इन सभी को "पैक करके ले जाती है"。
एनालॉजी: सूटकेस。 जब आप बाहर जाते हैं, तो आप अपनी शर्ट, रेज़र और चार्जर को अलग-अलग अपने हाथों में नहीं रखते, बल्कि उन सभी को एक सूटकेस में व्यवस्थित करके अपने साथ ले जाते हैं। Plugin वही सूटकेस है—यह Skill, Hook, Subagent, MCP server को एक ही इंस्टॉल करने योग्य यूनिट में पैक करता है। जब किसी दूसरे प्रोजेक्ट को उसी सेट की आवश्यकता होती है, तो बस इस plugin को इंस्टॉल करें और काम हो गया; इसके भीतर के Skill में नेमस्पेस भी होता है (जैसे /my-plugin:review), इसलिए एक से अधिक प्लगइन इंस्टॉल होने पर भी नाम नहीं टकराते। आधिकारिक तौर पर इसे बहुत स्पष्ट रूप से कहा गया है:
Plugin 将 skills、hooks、subagents 和 MCP servers 捆绑到单个可安装单元中。
Plugin के निर्माण की विशिष्ट प्रक्रिया लेख 24 में बताई गई है, यहाँ आपको बस सिस्टम में इसकी स्थिति याद रखनी है: अन्य पांच "फ़ंक्शन" हैं, और plugin "उन फ़ंक्शंस को पैकेज और वितरित करने" वाली लेयर है।
💡 一句话总结：挑扩展点不是单选题——真实配置几乎都是组合（Skill+MCP、CLAUDE.md+Skill…）；想把一整套搬到别处或分享，用 Plugin 打成一个箱子带走。
07 व्यावहारिक अभ्यास: वास्तविक आवश्यकता सूची की जांच करें
केवल तालिका देखना ही पर्याप्त नहीं है, आपको वास्तव में "ट्राइएज" (विभाग आवंटन) का अभ्यास करना होगा। नीचे एक सिम्युलेटेड वास्तविक आवश्यकता सूची दी गई है—ये ऐसे विचार हैं जो किसी प्रोजेक्ट में आ सकते हैं। आपका कार्य: प्रत्येक आइटम को पिछले निर्णय वृक्ष के अनुसार सही विभाग में आवंटित करना है। इस अनुभाग में किसी कमांड को टाइप करने की आवश्यकता नहीं है, यह पूरी तरह से एक मानसिक अभ्यास है, लेकिन यह दस परिभाषाओं को याद रखने से अधिक उपयोगी है।
पहला चरण: इस सूची को अपने नोट्स में कॉपी करें (या बस अपने दिमाग में इसके बारे में सोचें)
आवश्यकता सूची (प्रत्येक आइटम के लिए एक एक्सटेंशन पॉइंट चुनें):
A. टीम का समझौता "हमेशा pnpm का उपयोग करें, npm पर प्रतिबंध लगाएं", उम्मीद है कि यह हर बार इसका पालन करेगा
B. कंपनी के आंतरिक PostgreSQL डेटाबेस की जांच कराना चाहते हैं
C. एक कमांड के साथ पूरा रिलीज प्रोसेस "टैग बनाना → चैंजलॉग संशोधित करना → पुश करना" चलाना चाहते हैं
D. हर बार फ़ाइल संपादित करने के बाद, स्वचालित रूप से prettier स्वरूपण (formatting) चलाएं
E. इसे एक बार में पूरे utils निर्देशिका को पढ़ने दें, और मुझे केवल यह बताएं कि कौन से फ़ंक्शन उपयोग में नहीं हैं
F. "आंतरिक त्रुटि कोड तुलना तालिका" की एक लंबी सूची, जिसे इसे कभी-कभी जांचने की आवश्यकता होती है
G. "उत्पादन डेटाबेस की माइग्रेशन स्क्रिप्ट, इसे निष्पादित करने की बिल्कुल अनुमति नहीं है", इसे पूरी तरह से ब्लॉक करना होगादूसरा चरण: निर्णय वृक्ष का स्वयं अनुसरण करें और प्रत्येक आइटम के पीछे उत्तर लिखें
नीचे देखने की जल्दी न करें, पहले धारा 04 के उन चार प्रश्नों (बाहरी कनेक्शन? कड़ा आश्वासन चाहिए? अलग करना है? हर बार देखना है या आवश्यकतानुसार?) का उपयोग करके स्वयं निर्णय लें।
तीसरा चरण: उत्तरों की जांच करें
नीचे संदर्भ उत्तर और निर्णय के कारण दिए गए हैं। यह महत्वपूर्ण नहीं है कि आपके कितने उत्तर सही हैं, बल्कि यह महत्वपूर्ण है कि "क्यों" वे सही हैं:
| आवश्यकता | उपयोग किया जाना चाहिए | निर्णय का कारण (निर्णय वृक्ष के किस पथ पर चला) |
|---|---|---|
| A हमेशा pnpm का उपयोग करें | CLAUDE.md | कोई बाहरी कनेक्शन नहीं, किसी स्क्रिप्ट आश्वासन की आवश्यकता नहीं, कोई अलगाव नहीं; यह एक "हर बार देखा जाने वाला" नियम है |
| B आंतरिक डेटाबेस की जांच करें | MCP | पहला प्रश्न ही हिट हुआ: बाहरी सेवाओं और डेटा से जुड़ने की आवश्यकता है |
| C वन-क्लिक रिलीज | slash command | आपके द्वारा सक्रिय रूप से ट्रिगर की जाने वाली निश्चित बहु-चरणीय प्रक्रिया, Skill को /release नाम दें |
| D संपादन के बाद स्वचालित स्वरूपण | Hook (PostToolUse) | निश्चित समय, हर बार चलाना आवश्यक है, इसके लिए सोचने की आवश्यकता नहीं है |
| E मृत कोड खोजने के लिए पूरी निर्देशिका पढ़ें | Subagent | बहुत सारी फ़ाइलें पढ़ने का काम, केवल निष्कर्ष चाहिए, मुख्य चैट को भरने से रोकने के लिए अलग रखा गया |
| F कभी-कभी त्रुटि कोड तालिका की जांच करें | Skill | संदर्भ सामग्री जो आवश्यकतानुसार देखी जाती है, इसे CLAUDE.md में न डालें |
| G माइग्रेशन स्क्रिप्ट चलाने पर प्रतिबंध | अनुमति नियम / Hook | ब्लॉक करना "सुनिश्चित" करना होगा, केवल संकेतों पर भरोसा नहीं किया जा सकता; शुद्ध प्रवेश निर्णयों के लिए अनुमति नियमों को प्राथमिकता दी जाती है |
अपेक्षा: यदि आपने A और F को भ्रमित नहीं किया (एक CLAUDE.md में गया, दूसरा Skill में), D और G को भ्रमित नहीं किया (एक Hook स्वचालित रूप से चलता है, दूसरा अनुमति नियम ब्लॉक करता है), और E के लिए आपने Skill के बजाय Subagent चुना—तो आपका "ट्राइएज" लॉजिक स्थापित हो गया है, और भविष्य में वास्तविक आवश्यकताएं आने पर आप इस प्रक्रिया का पालन कर सकते हैं।
यदि आप किसी आइटम पर अटक जाते हैं, तो धारा 05 पर वापस जाएं और संबंधित तुलना को देखें, संभवतः वही जोड़ा स्पष्ट नहीं था। इस निर्णय प्रक्रिया को मांसपेशी स्मृति (muscle memory) बनाने में कुछ समय लगता है—पहली कुछ बार आप आसानी से "Subagent के काम को जबरदस्ती Skill में डाल सकते हैं", लेकिन जब आप इसे दो बार चलाते हैं और पाते हैं कि मुख्य चैट मध्यवर्ती प्रक्रियाओं से भर गई है, तो आपको याद आएगा कि "जब केवल निष्कर्ष चाहिए, तो क्लोन भेजना चाहिए"。
💡 一句话总结：拿一份真实需求清单逐条走决策树分诊，比背定义有用一百倍；卡住的那条，回去翻对应的「易混对比」基本就通了。
08 सारांश
इस लेख ने चौथे समूह को समेट दिया है—एक्सटेंशन के जिन पांच प्रमुख पॉइंट्स (और slash command) को आपने सीखा है, उन्हें "वे क्या हैं" से बदलकर "आवश्यकता आने पर किसका उपयोग करना है" में बदल दिया गया है।
मुख्य बिंदुओं की समीक्षा करने के लिए उन्हें एक साथ जोड़ें:
| आपके दिमाग की बात | आवंटित विभाग | एक-पंक्ति का मुख्य बिंदु |
|---|---|---|
| "हर बार पालन किया जाना चाहिए" | CLAUDE.md | नियम जो हमेशा प्रभावी रहते हैं, प्रति सत्र स्वचालित रूप से लोड होते हैं, 200 पंक्तियों के भीतर रखें |
| "आवश्यकता होने पर स्वचालित रूप से कॉल करें / मेरे द्वारा एक-क्लिक से ट्रिगर" | Skill / slash command | आवश्यकतानुसार ज्ञान और प्रक्रियाएं, आमतौर पर संदर्भ स्थान नहीं लेतीं |
| "बाहरी सेवाओं और डेटा को जोड़ना" | MCP | वे चीज़ें जो अंतर्निहित टूल की पहुंच से बाहर हैं, बाहरी दुनिया से जुड़ने के लिए इसका उपयोग करें |
| "फ़ाइलों के ढेर को पढ़ें और मुझे केवल निष्कर्ष दें" | Subagent | संदर्भ को अलग करें, समानांतर में विशेष कार्य करें, केवल सारांश लौटाएं |
| "विशिष्ट समय पर स्वचालित रूप से चलना, सुनिश्चित करना आवश्यक है" | Hook | घटना-ट्रिगर निश्चित क्रियाएं, सुरक्षा कवच स्तर का प्रवर्तन |
| "पूरा सेट स्थानांतरित करना / दूसरों के साथ साझा करना" | Plugin | इन सभी को एक इंस्टॉल करने योग्य यूनिट में पैक करना |
अब आपको यह करने में सक्षम होना चाहिए: कोई भी आवश्यकता जैसे "मैं चाहता हूँ कि Claude..." मिलने पर, पांच या छह शब्दों को देखकर असमंजस में नहीं पड़ेंगे—अपने दिमाग में उन चार प्रश्नों (बाहरी कनेक्शन? कड़ा आश्वासन चाहिए? अलग करना है? हर बार देखना है या आवश्यकतानुसार?) को दोहराएं, निर्णय वृक्ष का पालन करते हुए पत्ते तक पहुँचें, और सीधे तय करें कि किसका उपयोग करना है; जब आप Skill vs Subagent, CLAUDE.md vs Skill, Hook vs अनुमति नियम जैसे भ्रमित करने वाले जोड़ों का सामना करते हैं, तो आप स्पष्ट रूप से बता सकते हैं कि उनके बीच क्या अंतर है। एक बार जब "आवश्यकता → समाधान" की यह मैपिंग स्थापित हो जाती है, तो पिछले नौ लेखों में सीखे गए घटक वास्तव में काम में आ जाते हैं और आवश्यकतानुसार उपयोग किए जा सकते हैं।
पूरा चौथा समूह (उन्नत फ़ीचर एक्सटेंशन) यहाँ समाप्त होता है। आपने पांचों हथियारों को छू लिया है, और आप जानते हैं कि मैदान में उतरने पर कौन सा हथियार निकालना है—अब केवल उन्हें सहजता से उपयोग करने का अभ्यास करना बाकी है।
अगले लेख से, हम पांचवें समूह "सिस्टम कॉन्फ़िगरेशन और ऑप्टिमाइज़ेशन" में प्रवेश करेंगे। हम 31 "settings.json: उपयोगकर्ता-स्तर / प्रोजेक्ट-स्तर कॉन्फ़िगरेशन" से शुरू करेंगे—इस यात्रा में आपने CLAUDE.md लिखा है, अनुमतियों को कॉन्फ़िगर किया है, और जल्द ही Hook भी कॉन्फ़िगर करेंगे। इन सेटिंग्स को आखिरकार किस फ़ाइल में लिखा जाना चाहिए, और उपयोगकर्ता-स्तर और प्रोजेक्ट-स्तर में से कौन सा पहले लागू होता है, अब इसे ठीक से व्यवस्थित करने का समय आ गया है। इसके बारे में सोचें: वही कॉन्फ़िगरेशन, आपकी मुख्य निर्देशिका में लिखने और आपके प्रोजेक्ट में लिखने पर, बिल्कुल विपरीत परिणाम दे सकता है—इसके पीछे के कारणों को अगले लेख में स्पष्ट किया जाएगा।