अब तक के पाँच अध्यायों में हमने Claude Code इंस्टॉल किया, निर्देश दिए, अटकनों से निकले, और परमिशन डिज़ाइन की। यह अध्याय ख़ुद टूल को ही नए सिरे से गढ़ने की बात है। एक्सटेंशन के नाम याद कर लेने भर से वे इस्तेमाल नहीं होते। काम आती है वह तालिका जो बताए कि "अभी जो शिकायत है, वह किससे हल होगी"।
किसे कब चुनें ― चार सवालों से तय हो जाता है
एक्सटेंशन छह हैं, पर सोचने की बातें बस चार। गुज़ारिश से काम चल जाएगा क्या / पक्के तौर पर लागू करवाना है क्या / अलग संदर्भ में बाँटना है क्या / बाहर से जोड़ना है क्या ― इसी क्रम में ख़ुद से पूछ लें, तो जवाब लगभग हमेशा एक ही निकलता है।
कभी-कभार छूट भी जाए तो कोई बड़ी बात न हो, तो शब्द ही काफ़ी हैं। → CLAUDE.md (पूरे प्रोजेक्ट की मान्यताएँ) / Skills (किसी ख़ास काम का तरीक़ा)
एक बार भी छूट जाए तो दिक़्क़त हो, तो व्यवस्था से रोकिए। → hooks। कमांड-प्रकार के hooks सक्रिय होने पर तय इवेंट और शर्तों से मेल खाने पर चलते हैं।
ढेर सारे आउटपुट से मुख्य धारा नहीं भरनी, तो काम बाहर करवाइए और सिर्फ़ नतीजा लीजिए। → subagents
वह जानकारी चाहिए जो AI को पता चल ही नहीं सकती (डेटाबेस की मौजूदा वैल्यू, इशू ट्रैकर का भीतरी हाल)। → MCP
पाँचवाँ सवाल है "क्या यह दूसरों को भी बाँटना है" ― बाँटना हो तो plugins। सबसे ज़्यादा घालमेल Q1 और Q2 में होता है, यानी CLAUDE.md, Skills और hooks में। ये तीनों एक जैसे दिखते हैं, पर इनका फ़र्क़ है कब पढ़े जाते हैं और चलाता कौन है।
CLAUDE.md ― लोड होना और पालन होना अलग जाँचें
CLAUDE.md लोड होने वाली जगह पर रखने से हर सेशन को प्रोजेक्ट का संदर्भ देती है। सभी प्रोजेक्ट के साझा निर्देश ~/.claude/CLAUDE.md में रखें। इसमें लिखित निर्देश होते हैं, कार्रवाई की परमिशन लागू करने वाली सेटिंग नहीं।
एजेंट फ़ाइल पढ़ने की बात कहे, लेकिन पालन न करे, तो इन तीन सवालों को अलग-अलग देखें।
- क्या फ़ाइल लोड हुई?
/contextके Memory files में देखें कि CLAUDE.md और नियम दिख रहे हैं या नहीं। शुरुआत की डायरेक्टरी और बाहर रखने की सेटिंग तय करती हैं कि कौन-सी फ़ाइलें शामिल हैं। सीधे लोड हुई AGENTS.md इस सूची में नहीं दिखती, इसलिए केवल उसका न दिखना, उसे न पढ़े जाने का प्रमाण नहीं है - क्या संपीड़न के बाद लौटी? प्रोजेक्ट की मूल CLAUDE.md
/compactके बाद डिस्क से दोबारा पढ़कर संदर्भ में जोड़ी जाती है। उपडायरेक्टरी की CLAUDE.md और पाथ-आधारित नियम मेल खाती फ़ाइल पढ़ने पर फिर लोड होते हैं। केवल बातचीत में रखे गए फैसले अलग तरह से संभाले जाते हैं - क्या कार्रवाई पर असर हुआ? फ़ाइल लोड हो चुकी हो, तब भी अस्पष्ट नियम और विरोधी निर्देश अलग जाँचें। यह न मानें कि सबसे नया निर्देश हमेशा जीतता है। दायरा और अपवाद की शर्तें स्पष्ट करें
आधिकारिक सलाह है हर CLAUDE.md फ़ाइल में 200 से कम पंक्तियाँ। यह न लोडिंग रुकने की सीमा है, न पालन की गारंटी। हर बार ज़रूरी नियम रखें और विवरण को पढ़ने की शर्तों सहित अलग करें। @path से सब कुछ इम्पोर्ट करने पर शुरुआती संदर्भ नहीं घटता। कभी-कभार की प्रक्रियाओं के लिए Skills और खास फ़ाइलों तक सीमित निर्देशों के लिए पाथ-आधारित नियम रखें।
यह आधिकारिक मेमोरी दस्तावेज़ पर आधारित है। इन्हें पहचानने के व्यावहारिक उदाहरण और टूल के अंतर के लिए AI एजेंट के नियम न मानने का कारण कैसे जाँचें देखें।
“पढ़ लिया” पालन का प्रमाण नहीं है। लोडिंग का प्रदर्शन, डिफ़ और टेस्ट परिणाम अलग जाँचें। अगला अनुभाग समझाता है कि यांत्रिक रूप से जाँची जा सकने वाली शर्तें hooks या CI में कैसे रखें। अनजाँचे हिस्से भी बताएँ।
hooks ― शर्तें मिलने पर जाँच चलाएँ
“.env मत बदलना” जैसा लिखित निर्देश पालन की दर की गारंटी नहीं दे सकता। कोई शर्त जाँचकर कार्रवाई को चलने से पहले रोकना हो, तो परमिशन सेटिंग और 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 = व्यक्तिगत)।
अब शुरुआत वाले “.env मत बदलना” को व्यवस्था में बदलकर देखते हैं। यह आधिकारिक मार्गदर्शिका के “सुरक्षित की गई फ़ाइलों का संपादन रोकने” वाले उदाहरण का .env तक सीमित रूप है। इसके लिए दो चीज़ें चाहिए: सेटिंग और स्क्रिप्ट।
① .claude/settings.json — Edit या Write बुलाए जाने से ठीक पहले स्क्रिप्ट चलवाता है।
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-env.sh"
}
]
}
]
}
}
② .claude/hooks/protect-env.sh — संपादित होने वाली फ़ाइल का नाम .env से शुरू हो (.env.local आदि भी), तो संपादन रोकता है। macOS और Linux पर chmod +x .claude/hooks/protect-env.sh से इसे चलाने की अनुमति दें।
#!/bin/bash
# .claude/hooks/protect-env.sh
command -v jq >/dev/null || { echo "jq नहीं मिला, इसलिए संपादन रोक दिया गया" >&2; exit 2; }
FILE_PATH=$(jq -r '.tool_input.file_path // empty')
FILE_PATH="${FILE_PATH//\\//}" # Windows के \ को / में बदलें
if [[ "${FILE_PATH##*/}" == .env* ]]; then
echo "Blocked: $FILE_PATH एक .env फ़ाइल है, इसलिए इसे संपादित नहीं किया जाएगा" >&2
exit 2
fi
exit 0
ढाँचा है इवेंट का नाम → मैचर और कमांड की सूची। matcher लक्ष्य टूल का नाम है; "Edit|Write" Edit या Write में से किसी एक से मेल खाता है (छोड़ने पर सभी टूल)। हुक स्टैंडर्ड इनपुट पर JSON लेता है, और Edit तथा Write में tool_input.file_path में संपादित होने वाली फ़ाइल का एब्सोल्यूट पाथ होता है। Windows पर इस पाथ में विभाजक \ होता है, इसलिए स्क्रिप्ट उसे पहले / में बदलकर तुलना करती है। एग्ज़िट कोड 2 से रोकने पर स्टैंडर्ड एरर का संदेश अस्वीकृति के कारण के रूप में Claude तक पहुँचता है, और Claude उसे पढ़कर दूसरा तरीका सोचता है। 1 न रोकने वाली त्रुटि मानी जाती है और कार्रवाई जारी रहती है, इसलिए रोकना हो तो 2 इस्तेमाल करें। 0 का अर्थ है कोई आपत्ति नहीं; इसके बाद सामान्य परमिशन जाँच होती है।
स्क्रिप्ट bash और jq इस्तेमाल करती है (आधिकारिक मार्गदर्शिका का उदाहरण भी jq मानकर चलता है)। Windows पर हुक Git Bash में चलते हैं और Git Bash न हो तो PowerShell में, इसलिए इस उदाहरण के लिए Git Bash चाहिए। jq न मिलने पर संपादन चुपचाप आगे न बढ़ जाए, इसलिए स्क्रिप्ट अपने पहले ही कदम में रोक देती है।
हुक पाबंदी कस तो सकते हैं, ढीली नहीं कर सकते। वे अनुमति लौटा भी दें तो बस पुष्टि छूटती है, और मना करने वाले नियम हमेशा ऊपर रहते हैं। PreToolUse की मनाही उस मोड में भी असर करती है जो सारी मंज़ूरियाँ छोड़ देता है, इसलिए अध्याय 5 में जितनी ढील दी थी, उसके नीचे यह एक फ़र्श की तरह काम आती है।
आज़माने का तरीका आधिकारिक मार्गदर्शिका जैसा ही है। Claude से कहें “.env में एक टिप्पणी की पंक्ति जोड़ो”; संपादन से पहले काम रुक जाएगा और Blocked: वाला संदेश Claude को लौटेगा। साथ ही यह भी आज़माएँ कि .env के अलावा दूसरी फ़ाइलें पहले की तरह संपादित हो रही हैं। स्क्रिप्ट का पाथ गलत लिखा हो, तो केवल Failed with non-blocking status code सूचना आती है और दरवाज़ा खुला ही रह जाता है, इसलिए इस सूचना पर भी ध्यान दें। यह उदाहरण केवल Edit और Write, इन दो टूल को रोकता है; Bash या PowerShell कमांड से होने वाले बदलाव अलग रास्ता हैं। जितना दायरा रोकना है, उसके अनुसार लक्ष्य बढ़ाएँ। आउटपुट के प्रारूप और इवेंट के अंतर आधिकारिक Hooks मार्गदर्शिका में हैं।
क़ीमत पहले समझें: कमांड-प्रकार के hooks आपके उपयोगकर्ता अधिकारों से शेल कमांड अपने आप चलाते हैं, और आपका खाता जिन फ़ाइलों तक पहुँचता है, उन्हें बदल या मिटा भी सकते हैं। आधिकारिक दस्तावेज़ भी कहते हैं कि जोड़ने से पहले हर कमांड पढ़ें और परखें। केवल भरोसेमंद कमांड रखें और इनपुट जाँचें। सेटिंग फ़ाइलों को सीधे संपादित करके किए गए बदलाव सामान्यतः अपने आप लागू हो जाते हैं। /hooks में पंजीकरण देखें; असर न दिखे, तो JSON और फ़ाइल की जगह जाँचकर सेशन दोबारा शुरू करें।
subagents ― संदर्भ अलग करके सौंपना
टेस्ट का पूरा आउटपुट और बड़े लॉग संदर्भ को ऐसे ढेर सारे टेक्स्ट से भर सकते हैं जिसे केवल सरसरी नज़र से देखना था, जिससे ज़रूरी बातें बाहर हो जाती हैं। सबएजेंट वह काम अलग संदर्भ में करते हैं और निष्कर्ष का सारांश लौटाते हैं। सामान्यतः उनका संदर्भ, निर्देश और टूल परमिशन अलग होते हैं, इसलिए मुख्य एजेंट को आवश्यक जानकारी स्पष्ट रूप से देनी चाहिए। बातचीत को fork करके मुख्य एजेंट का इतिहास पाने वाला निष्पादन अपवाद है; यह स्किल के context: fork से अलग है। रिपोर्ट सारांश होती है, इसलिए आवश्यक प्रमाण और अनसुलझे सवाल भी माँगें।
- अलग करना फ़ायदेमंद है ― चौड़ी छानबीन / ढेर सारा आउटपुट पैदा करने वाली जाँच / ऐसे अपने में पूरे काम जिनका बस नतीजा चाहिए
- अलग करना घाटे का है ― सिलसिलेवार काम / बार-बार की आवाजाही / एक ही फ़ाइल को छूने वाले समांतर काम / एक-दो चाल में निपट जाने वाले सुधार
यह एक मानक सुविधा है, इसलिए बिना किसी सेटिंग के इस्तेमाल हो जाती है। अपनी परिभाषा जोड़नी हो तो .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/ (साझा) में रख देने भर से यह पहचान ली जाती है।
मुख्य विचार है चरणबद्ध खुलासा। सामान्यतः स्किल के नाम और विवरण की सूची संदर्भ में आती है, जबकि मुख्य पाठ स्वचालित चयन या स्पष्ट /skill-name कमांड से लोड होता है। सहायक सामग्री ज़रूरत पर पढ़ी जाती है। विवरणों की सूची भी संदर्भ में जगह लेती है; बहुत स्किल हों, तो बजट में रखने के लिए विवरण छोटे किए या छोड़े जा सकते हैं। ठोस description लिखें और अलग-अलग जाँचें कि स्किल बुलाई गई या नहीं तथा प्रक्रिया से अपेक्षित परिणाम मिला या नहीं। लिखने का तरीका Claude Agent Skills क्या हैं में देखें।
एक पंक्ति में: CLAUDE.md = नियमित रूप से लोड होने वाली मान्यताएँ; Skills = स्वचालित चयन या स्पष्ट बुलावे से खुलने वाली प्रक्रियाएँ; कमांड-प्रकार के hooks = तय इवेंट और शर्तों से शुरू होने वाला काम।
MCP ― बाहर के सिस्टम तक हाथ बढ़ाना
MCP (Model Context Protocol), डेटाबेस के वर्तमान मान या इश्यू ट्रैकर के टिकट जैसे बाहरी डेटा और ऑपरेशन तक पहुँचने का मानक है। नीचे दो आम कनेक्शन तरीके हैं। कारण खोजने के लिए कनेक्शन का तरीका और त्रुटि का विवरण साथ देखें।
- लोकल (stdio) — सर्वर आपके कंप्यूटर पर चाइल्ड प्रोसेस बनकर शुरू होता है। एक्ज़ीक्यूटेबल का पाथ, आवश्यक एनवायरनमेंट वेरिएबल और सर्वर का त्रुटि आउटपुट सुराग देते हैं
- रिमोट (HTTP) — URL से सर्वर को जोड़ते हैं। URL, नेटवर्क, सर्वर की त्रुटियाँ और क्रेडेंशियल सुराग देते हैं
/mcp के स्टेटस और विवरण से शुरू करें। failed लोकल और रिमोट, दोनों सर्वर पर आ सकता है। claude mcp get <name> के Issue: में HTTP कोड या त्रुटि का संदेश हो तो उसे भी पढ़ें। needs authentication प्रमाणीकरण जाँचने और pending approval प्रोजेक्ट सर्वर की स्वीकृति दोबारा देखने का संकेत है। कनेक्शन बनाते समय तय Authorization हेडर 401/403 से अस्वीकार हो तो प्रमाणीकरण की समस्या होने पर भी failed आता है। उपाय Claude Code के MCP कनेक्शन त्रुटि के कारण और समाधान में हैं।
साझा कॉन्फ़िगरेशन फ़ाइल .mcp.json प्रोजेक्ट रूट में रखें। stdio सर्वर को दिए जाने वाले वेरिएबल उसके env में दें; HTTP प्रमाणीकरण के लिए सेवा के अनुसार OAuth या headers इस्तेमाल करें। असली कुंजियाँ साझा फ़ाइल में सीधे न लिखें; इसके बजाय ${API_KEY} जैसे एनवायरनमेंट वेरिएबल का संदर्भ दें। Claude Code के अपने क्रेडेंशियल सहित कुछ वेरिएबल नाम रिमोट URL और हेडर में खाली स्ट्रिंग बन जाते हैं; विवरण आधिकारिक विस्तार नियम में है।
टूल की परिभाषाएँ डिफ़ॉल्ट रूप से ज़रूरत पड़ने पर लोड होती हैं। टूल खोज चालू होने की सामान्य स्थिति में पहले केवल टूल के नाम और सर्वर के विवरण कॉन्टेक्स्ट में आते हैं। खोज बंद हो, परिवेश समर्थित न हो या सर्वर पर alwaysLoad लगा हो, तो परिभाषाएँ पहले लोड होने के मामले हैं। आउटपुट भी कॉन्टेक्स्ट लेता है, इसलिए /context से वास्तविक उपयोग देखें और अनुपयोगी सर्वर बंद करें।
plugins ― पूरा सेट बाँधकर बाँटना
Plugins से skills, subagent परिभाषाएँ, hooks और MCP कॉन्फ़िगरेशन एक साथ बाँट सकते हैं। किसी प्लगइन का मेनिफ़ेस्ट दें तो उसे .claude-plugin/plugin.json में रखें। मानक संरचना में skills/, agents/, hooks/hooks.json और .mcp.json प्लगइन के अपने रूट में रहते हैं। इन्हें .claude-plugin/ के भीतर न रखें। सिर्फ मानक संरचना इस्तेमाल करने वाला प्लगइन मेनिफ़ेस्ट छोड़ सकता है।
/plugin marketplace add owner/repo ← कैटलॉग जोड़ें
/plugin install name@marketplace ← उससे अलग-अलग प्लगइन इंस्टॉल करें
/plugin list ← marketplace से इंस्टॉल हुए प्लगइन देखें
ये marketplace से इंस्टॉल करने के मूल चरण हैं। सिर्फ कैटलॉग जोड़ने से प्लगइन इंस्टॉल नहीं होते। /plugin list इसी रास्ते से इंस्टॉल हुए प्लगइन दिखाता है, skills डायरेक्टरी या सिंक जैसे दूसरे रास्तों के सभी प्लगइन नहीं। स्कोप हैं user (आपके सभी प्रोजेक्ट), project (साझा कॉन्फ़िगरेशन) और local (इस प्रोजेक्ट में सिर्फ आप)। project स्कोप में भी बाहरी स्रोत के प्लगइन हर सदस्य को इंस्टॉल करने होते हैं। Managed स्कोप प्रशासक नियंत्रित करता है और उपयोगकर्ताओं के सेटिंग बदलाव सीमित करता है। खुद बनाने का तरीका Claude Code Plugins और Marketplace: उपयोग, निर्माण और प्रकाशन में है।
प्लगइन आपके अधिकारों से मनचाहा कोड चला सकते हैं, यह आधिकारिक दस्तावेज़ की चेतावनी है। Community सूची वाले प्लगइन 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 तय शर्तें मिलने पर Claude Code से चलते हैं। निष्पादन-पथ और रोकने का बर्ताव सत्यापित करें; बाद में चलने वाला हुक पूरी हो चुकी कार्रवाई वापस नहीं कर सकता
- subagents किसी और कॉन्टेक्स्ट में काम करते हैं और सिर्फ़ सारांश लौटाते हैं। सिलसिलेवार काम और बार-बार की आवाजाही के लिए ये ठीक नहीं
- Skills में चरणबद्ध खुलासा होता है और उनका मुख्य पाठ ज़रूरत पर खुलता है। स्वचालित चयन के लिए ठोस विवरण लिखें तथा स्पष्ट बुलावे के बाद भी प्रक्रिया के परिणाम परखें
- MCP बाहरी पहुँच का मानक है।
/mcpका स्टेटस, कनेक्शन का तरीका और त्रुटि का विवरण साथ देखकर कारण खोजें - plugins बाँटने का डिब्बा है। दूसरों का कोड आपके अपने अधिकारों से चलता है, इसलिए प्रकाशक जाँच लीजिए
- लगाने का क्रम लक्षण से तय होता है। दिक़्क़त पैदा होने के बाद, एक-एक करके
टूल्स की आपस में तुलना करके चुनने की बात AI कोडिंग कोर्स के अध्याय 6 "एक्सटेंशन से क्षमता बढ़ाएँ" में है।
जितना बढ़ाते जाएँगे, खपत उतनी बढ़ेगी। आख़िर में हम उस संचालन की बात करेंगे जो इसे लंबे समय तक चलाते रहने के लिए चाहिए। अब अध्याय 7 "लागत और सीमाएँ" पर बढ़ें।