Claude Code को विस्तारित करने वाले चार तंत्र प्रामाणिक रूप से अलग-अलग समस्याओं को हल करते हैं। एक skill Claude को सिखाती है कि आप कुछ कैसे चाहते हैं कि किया जाए। एक hook यह सुनिश्चित करता है कि कुछ होता है, चाहे Claude क्या निर्णय ले। एक subagent मुख्य बातचीत के संदर्भ को एक स्वच्छ साइड प्रक्रिया को केंद्रित कार्य सौंपकर सुरक्षित रखता है। एक MCP सर्वर Claude को एक ऐसी प्रणाली तक पहुँच देता है जिसे वह इसके बिना शाब्दिक रूप से नहीं पहुँच सकता। गलत चुनें और आप या तो एक "नियम" के साथ समाप्त होते हैं जिसे मॉडल चुप्पी से नज़रअंदाज़ कर सकता है, या एक MCP निर्भरता जहाँ सादे निर्देश काम कर गए होते।
कार्य के आधार पर एक तंत्र चुनें
एक एकल निदान प्रश्न से शुरू करें: वास्तव में क्या गायब है?
यदि उत्तर है "Claude नहीं जानता कि मैं यह कैसे चाहता हूँ," तो वह एक skill है। Commit संदेश प्रारूप, PR विवरण टेम्पलेट, lint नीति, समीक्षा चेकलिस्ट। यह सब पैकेज्ड जानकारी है, माँग पर लोड की जाती है जब यह प्रासंगिक हो, और यह किसी बाहरी निर्भरता के बिना आपके मौजूदा सत्र के अंदर चलता है।
यदि उत्तर है "कुछ एक निश्चित बिंदु पर होना चाहिए और मैं मॉडल पर विश्वास नहीं कर सकता कि वह याद रखेगा," तो वह एक hook है। Hooks PreToolUse या PostToolUse जैसी जीवनचक्र घटनाओं पर फायर करते हैं और Claude के संदर्भ के बाहर चलते हैं। मॉडल उन्हें ओवरराइड नहीं कर सकता। CodingNomads इसे अच्छी तरह समझाता है: hooks शून्य LLM निहितार्थ और शून्य संदर्भ लागत के साथ निर्धारक रूप से चलते हैं।
यदि उत्तर है "यह उप-कार्य मेरे मुख्य थ्रेड में 40 फ़ाइल पढ़ को खींच लेगा," तो वह एक subagent है। अलग संदर्भ विंडो, अपना टोकन बजट, एक सारांश रिपोर्ट करता है। शांत और केंद्रित।
यदि उत्तर है "Claude को वास्तव में एक ऐसी प्रणाली को छूना होगा जिसे वह नहीं पहुँच सकता," तो वह एक MCP सर्वर है। डेटाबेस पढ़ना, Slack पोस्ट, आंतरिक API, Notion पृष्ठ। ये ज्ञान समस्याएँ नहीं हैं, ये संपर्क समस्याएँ हैं, और केवल MCP उन्हें हल करता है।
और CLAUDE.md सभी के ऊपर हमेशा चलने वाली परत के रूप में बैठता है। प्रत्येक सत्र इसे स्वचालित रूप से पढ़ता है। इसे 200 लाइनों के तहत रखें, Anthropic के अपने मार्गदर्शन के अनुसार, अन्यथा महत्वपूर्ण बाधाएँ दबी हुई और नज़रअंदाज़ की जाती हैं।
निर्देश, टूल पहुँच, घटनाएँ और पृथक संदर्भ
प्रत्येक तंत्र वास्तव में क्या नियंत्रित करता है:
- Skills: निर्देश और संदर्भ, वर्तमान बातचीत में माँग पर लोड किए जाते हैं। कोई बाहरी कॉल नहीं। कोई घटना ट्रिगर नहीं। मॉडल अपने फ्रंटमैटर में विवरण के आधार पर तय करता है कि एक skill कब प्रासंगिक है।
- MCP सर्वर: टूल पहुँच। Claude MCP टूल्स को किसी भी टूल की तरह कॉल करता है, लेकिन निष्पादन JSON-RPC के माध्यम से एक अलग प्रक्रिया में होता है। एक MCP सर्वर Claude को बाहरी प्रणालियों से जोड़ता है; एक skill इसे बताता है कि एक बार जुड़ जाने के बाद उन्हें अच्छी तरह कैसे उपयोग करें।
- Hooks: जीवनचक्र घटनाएँ। SessionStart, PreToolUse, PostToolUse,
PreCompact। वे निर्धारक रूप से चलते हैं। एक hook जो एक विनाशकारी कमांड को रोकता है वह हर बार इसे रोकेगा, चाहे Claude को लगा हो कि यह एक अच्छा विचार था या नहीं। - Subagents: पृथक संदर्भ। आप एक subagent को एक ब्रीफ सौंपते हैं; यह स्वतंत्र रूप से काम करता है; यह एक परिणाम लौटाता है। एक परीक्षण-लेखन subagent को आपकी तैनाती पाइपलाइन के बारे में जानने की आवश्यकता नहीं है। एक दस्तावेज़ subagent को आपके डेटाबेस स्कीमा की आवश्यकता नहीं है। वह पृथक्करण पूरा मुद्दा है।
Skills और commands यहाँ एक संक्षिप्त नोट के योग्य हैं क्योंकि इन्हें संगलित करना आसान है। official skills documentation के अनुसार, कस्टम commands को skills में मोड़ा जाता है, एक अलग छठा सिस्टम नहीं। वे एक ही SKILL.md लेखन मॉडल साझा करते हैं। अगले भाग में इस पर अधिक।
Inventive HQ का विश्लेषण इसे स्पष्ट रूप से रखता है: "एक skill व्यवहार बदलता है, एक subagent संदर्भ की सुरक्षा करता है, एक MCP सर्वर क्षमता जोड़ता है, और एक hook एक घटना पर निर्धारक रूप से एक कार्य चलाने की गारंटी देता है, चाहे मॉडल क्या करने का फैसला करे।"
स्लैश कमांड्स स्किल्स में कहाँ फिट होते हैं
कस्टम स्लैश कमांड्स स्किल्स के साथ अलग तंत्र नहीं हैं। ये स्किल्स को invoke करने का सतह हैं। जब आप /deploy या /review टाइप करते हैं, तो आप किसी स्किल को नाम से trigger कर रहे होते हैं। वह स्किल निर्देश, कोई भी linked reference files, और इस बारे में context रखता है कि Claude को उस काम को कैसे handle करना चाहिए।
authoring task (अच्छे frontmatter descriptions के साथ SKILL.md लिखना), command lookup task (किस command name को expose करना है यह decide करना), और mechanism comparison task (स्किल्स और hooks के बीच चुनना) तीन अलग-अलग reader concerns हैं। ये एक ही file format share करते हैं, जो इसी वजह से confusion बनी रहती है।
अगर आप decide कर रहे हैं कि स्किल का इस्तेमाल करना है या नहीं, तो सवाल यह है: क्या यह ऐसा ज्ञान है जो मुझे अन्यथा फिर से type करना होता, या यह कुछ ऐसा है जो किसी event पर input की परवाह किए बिना fire होना चाहिए? पहला एक स्किल है, संभवतः command के तौर पर surface किया गया। दूसरा एक hook है।
इस बारे में गहरी समझ के लिए कि कैसे CLAUDE.md हर session में project context को feed करता है, agencies के लिए CLAUDE.md guide scoping और file structure को विस्तार से cover करता है।
एक Repository Task के लिए Mechanisms को Compose करें
ज्यादातर real-world setups एक mechanism को pick नहीं करते और बस खत्म कर देते हैं। वे दो या तीन को compose करते हैं। यहाँ एक illustrative scenario है जो दिखाता है कि यह PR workflow के लिए कैसे काम करता है:
| Task | Mechanism | Reason |
|---|---|---|
| PR description format को enforce करें | Skill | Packaged know-how; Claude PR लिखते समय load होता है |
| Linear से ticket context fetch करें | MCP server | बाहरी system जिस तक Claude natively नहीं पहुँच सकता |
| impact analysis के लिए >20 files को scan करें | Subagent | main thread को clean रखता है; एक focused summary return करता है |
| अगर tests fail हों तो commits को block करें | Hook | Deterministic guarantee; model द्वारा argue नहीं किया जा सकता |
| हमेशा-चालू branch naming rule | CLAUDE.md | कभी शर्तबद्ध नहीं; हर सत्र में आवश्यक |
| फ़ाइल लिखने से पहले लिंटर को स्वचालित रूप से चलाएँ | PreToolUse पर हुक करें | Claude के निर्णय पर नहीं, किसी घटना पर चलना चाहिए |
लिंटर का उदाहरण रुकने लायक है। Moeed का विश्लेषण इसे साफ़ पकड़ता है: "'लिंटर चलाएँ' का हिस्सा एक कौशल है, Claude यह कर सकता है, आप बस सुसंगतता चाहते हैं। 'केवल तभी commit करें जब यह पास हो' का हिस्सा एक हुक है, यह गारंटी है, दिशानिर्देश नहीं। वे एक-दूसरे को जोड़ते हैं।"
यही व्यावहारिक मानसिक मॉडल है। कौशल और हुक अक्सर एक ही कार्य पर अलग-अलग कोणों से काम करते हैं।
सामान्य गलत विकल्प और उन्हें ठीक कैसे करें
कुछ पैटर्न बार-बार दिखते हैं:
- किसी ऐसी चीज़ के लिए MCP सर्वर जो केवल ज्ञान थी। अगर आप अपनी स्टाइल गाइड को "ऐक्सेस" करने के लिए एक MCP सर्वर शुरू करते हैं, तो रुकें। यह एक कौशल है। MCP लाइव सिस्टम से जुड़ने के लिए है, मार्कडाउन दस्तावेज़ लोड करने के लिए नहीं।
- CLAUDE.md नियम जो वास्तव में एक हुक है। CLAUDE.md में "कभी
rm -rfन चलाएँ" डालना एक सुझाव है जिसे मॉडल तकनीकी रूप से काम कर सकता है।PreToolUseहुक जो उस पैटर्न पर Bash टूल को ब्लॉक करता है, वह एक कड़ी मनाही है। अगर किसी नियम की गारंटी दी जानी चाहिए, तो यह context में नहीं, हुक में होना चाहिए। - एक कार्य के लिए कौशल जिसे अपने स्वयं के context budget की आवश्यकता है। यदि काम में दर्जनों फ़ाइलें पढ़ना शामिल है, तो आपके मुख्य सत्र में टोकन का रिसाव तेज़ी से बढ़ता है। एक subagent को spawn करें। इसे एक focused prompt मिलता है, काम करता है, और एक summary लौटाता है। आपका मुख्य context coherent रहता है।
- किसी ऐसी चीज़ के लिए Subagent जिसे केवल एक निर्देश की आवश्यकता थी। Subagent की overhead होती है। अगर Claude को बस अपनी migration convention जानने की ज़रूरत है, तो एक कौशल लिखें। ज्ञान की समस्या के लिए एक अलग worker को spin up न करें।
- अधिभारित CLAUDE.md। 200 लाइनों के बाद, Anthropic की अपनी guidance कहती है कि महत्वपूर्ण constraints खो जाती हैं। संदर्भ content को कौशल में move करें या
.claude/rules/फ़ाइलों में बाँटें जो path matching के आधार पर सशर्त रूप से load हों।
अगर आप scratch से एक Claude Code workflow बना रहे हैं और एक structured starting point चाहते हैं, तो Claude Code workflow guide दिखाता है कि एक real repository setup के लिए इन परतों को कैसे order दें।
प्रासंगिक Implementation Guide को Follow करें
एक बार जब आपने सही mechanism की पहचान कर ली, implementation paths clearly split हो जाते हैं। यह post एक navigation और comparison layer है, setup tutorial नहीं। यहाँ अगला कदम है, mechanism के आधार पर:
- Hooks setup: Claude Code hooks guide lifecycle events, handler types, और shell व HTTP handlers को deterministically लिखना cover करता है।
- Subagents: Claude Code subagents guide explain करता है कि subagent को कैसे brief दें, इसके tool permissions को कैसे scope करें, और parent session में result को कैसे handle करें।
- MCP servers: अगर आप एक production stack के लिए MCP servers बना रहे या integrate कर रहे हैं, तो MCP servers production guide server types, transport, और reliability patterns cover करता है।
- Skills: official skills documentation से शुरू करें, जो SKILL.md structure, frontmatter descriptions, और कैसे custom commands skill files से map होते हैं, को cover करता है।
चारों को एक साथ पढ़ने की कोशिश मत करो इससे पहले कि तुम फैसला कर लो कि कौन सी mechanism लागू होती है। यही वह तरीका है जिससे तुम hook configuration में तीन घंटे गहराई तक चले जाते हो जब तुम्हें सिर्फ दो लाइन का कौशल चाहिए था।
FAQ
क्या CLAUDE.md एक mechanism है जिसे मुझे इस फैसले में शामिल करना चाहिए?
हाँ, लेकिन यह एक अलग तरह का फैसला है। CLAUDE.md को task time पर select नहीं किया जाता। यह हर session automatically लोड होता है। CLAUDE.md के लिए सवाल यह है: "क्या Claude को यह information हर एक बार, बिना शर्त के चाहिए?" अगर हाँ, तो इसे वहाँ रखो। अगर instruction सिर्फ कुछ खास tasks के लिए महत्वपूर्ण है, तो यह एक specific frontmatter description के साथ एक skill में होना चाहिए।
क्या एक skill कोई MCP server call trigger कर सकता है?
हाँ। एक skill Claude को instruct कर सकता है कि workflow के हिस्से के रूप में available MCP tools का उपयोग करे। Skill बताता है कि कैसे (क्या माँगना है, किस क्रम में, किन formatting expectations के साथ) और MCP server access प्रदान करता है। ये एक-दूसरे के प्रतिद्वंद्वी नहीं हैं, बल्कि पूरक हैं।
एक subagent और एक agent team के बीच अंतर क्या है?
एक subagent एक worker है जिसे तुम main session से किसी focused sub-task को handle करने के लिए भेजते हो। एक agent team peer sessions का एक समूह है जो एक-दूसरे से सीधे communicate कर सकते हैं, genuinely parallel collaborative work के लिए उपयुक्त। अधिकांश repository tasks के लिए, एक subagent सही चुनाव है। Agent teams तब समझदारी से काम आते हैं जब कई independent workstreams को coordinate करने की जरूरत हो, न कि एक session downward delegate कर रहा हो।
क्या hooks को Claude के context तक पहुँच है?
नहीं। यही तो बात है। Hooks Claude के context के बाहर run होते हैं और model उन्हें override नहीं कर सकता। यह उन्हें hard guarantees के लिए सही tool बनाता है: security checks, mandatory linting passes, blocked file patterns। Trade-off यह है कि एक hook उस बात के आधार पर nuanced decisions नहीं ले सकता जो Claude task के बारे में समझता है। यह event पर fire होता है और अपना handler चलाता है।
सभी चार mechanisms को एक साथ उपयोग करने का अर्थ कब होता है?
जब तुम्हारे पास एक workflow हो जिसमें कई अलग-अलग failure modes हों: एक knowledge gap (skill), एक connectivity requirement (MCP), एक context-bleed risk (subagent), और कम से कम एक action जो guaranteed होना चाहिए भले ही model की judgment कुछ और कहे (hook)। अधिकांश simple tasks को एक या दो mechanisms की जरूरत होती है। हर task पर चारों के लिए पहुँचना overhead जोड़ता है benefit के बिना।
इस पूरी comparison में सबसे तीव्र अंतर: एक skill एक suggestion है जो Claude पढ़ता है और follow करता है; एक hook एक rule है जिसे harness enforce करता है चाहे Claude सहमत हो या नहीं। अगर तुम इसे गलत समझोगे तो तुम्हारा "safety rule" सिर्फ एक शिष्ट request बन जाएगा।