Claude Code Plugins: अपनी टीम के लिए एक निजी मार्केटप्लेस बनाएँ

24 फरवरी 2026 को, Anthropic ने Claude Code के लिए निजी प्लगइन मार्केटप्लेस की घोषणा की, जो एडमिन को Anthropic के सार्वजनिक रजिस्ट्रियों को छुए बिना प्लगइन बनाने, होस्ट करने और गेट करने का तरीका देता है। इस पोस्ट से आपको जो मिलता है: एक कौशल को बंडल करने और वितरणयोग्य प्लगइन में हुक करने के सटीक कदम, इसे एक निजी GitHub रेपो में होस्ट करना, संस्करणों को पिन करना, और सबसे आम टूटन का निदान करना जब दूसरी मशीन स्वच्छ रूप से स्थापित होने से इनकार करती है।

जब एक टीम को प्लगइन की जरूरत हो

सार्वजनिक मार्केटप्लेस अकेले प्रयोग के लिए ठीक है। एक बार जब एक से अधिक लोग एक ही स्लैश कमांड या एक ही हुक स्क्रिप्ट पर निर्भर हों, तो तदर्थ वितरण तेजी से ढह जाता है। कोई एक फाइल को मैनुअल रूप से कॉपी करता है, एक थोड़े अलग पथ का उपयोग करता है, और Claude Code चुपचाप हुक को अनदेखा करता है क्योंकि नाम रजिस्ट्री जो अपेक्षा करती है उससे मेल नहीं खाता।

यह एक निजी मार्केटप्लेस के लिए वास्तविक ट्रिगर है: मशीनों में स्थिरता, सिर्फ हेडकाउंट नहीं। अगर आपके पास दो डेवलपर हैं और दोनों को एक ही डिप्लॉयमेंट हुक की जरूरत है, तो एक निजी मार्केटप्लेस सेटअप के एक घंटे के लायक है। अगर आपके पास बीस हैं, तो यह वैकल्पिक नहीं है।

दूसरा ट्रिगर गोपनीयता है। Anthropic के प्लगइन निर्माण दस्तावेज स्पष्ट हैं: एक प्लगइन को अपनी टीम के आंतरिक रखने के लिए, आप मार्केटप्लेस को एक निजी रेपो में होस्ट करते हैं। claude-community को सबमिट करने से आपका प्लगइन किसी के भी देखने और स्थापित करने के लिए प्रकाशित हो जाता है। एक निजी रेपो यह पूरी तरह से बचाता है। यदि आपके प्लगइन में आंतरिक API पैटर्न, स्वामित्व वाली स्लैश कमांड, या कोई ऐसी चीज है जिसे आप इंडेक्स नहीं करवाना चाहते, तो निजी मार्ग सही है।

ध्यान देने के लायक: अगर आपकी टीम पहले से ही उत्पादन में MCP सर्वर चला रही है, तो किसी संरचना को प्रतिबद्ध करने से पहले जाँच लें कि निजी प्लगइन वितरण उस स्टैक के साथ कैसे फिट बैठता है, क्योंकि दोनों दृष्टिकोणों के ओवरलैपिंग लेकिन अलग उपयोग केस हैं।

एक मौजूदा कौशल और हुक को बंडल करें

एक प्लगइन एक फोल्डर है। यह इसका ईमानदार सारांश है। आधिकारिक प्लगइन दस्तावेजों के अनुसार, न्यूनतम व्यवहार्य संरचना इस तरह दिखती है:

my-plugin/

plugin.json

README.md

skills/

my-skill.md

hooks/

hooks.json

guard.sh

plugin.json मैनिफेस्ट है। यह प्लगइन को नाम देता है, एक संस्करण घोषित करता है, और कौशल और हुक उप-निर्देशिकाओं की ओर इशारा करता है। एक सुव्यवस्थित उदाहरण:

{

"name": "deployment-tools",

"version": "1.2.0",

"description": "Deployment workflow helpers for the platform team",

"skills": ["skills/"],

"hooks": "hooks/hooks.json"

}

कौशल markdown फाइलें हैं जो परिभाषित करती हैं कि Claude क्या करना जानता है, और स्लैश कमांड उनके अंदर रहते हैं। हुक JSON घोषणाएं हैं जो शेल स्क्रिप्ट को ट्रिगर पॉइंट से तार देते हैं (एक उपकरण कॉल से पहले, एक सत्र के बाद, और इसी तरह)। आप एक ही प्लगइन फोल्डर में दोनों का कोई भी संयोजन बंडल कर सकते हैं। कौशल दस्तावेज नोट करते हैं कि कस्टम कमांड अब कौशल मॉडल का हिस्सा हैं, इसलिए उन्हें एक अलग समानांतर सिस्टम के रूप में बनाए रखने का प्रयास न करें।

एक चीज जो लोगों को पकड़ती है: हुक स्क्रिप्ट को चलाने योग्य होना चाहिए। प्रतिबद्ध करने से पहले chmod +x hooks/guard.sh चलाएँ। Claude Code अनुमति बिट को जाँचता है और यदि यह सेट नहीं है तो चुपचाप एक हुक को छोड़ देगा।

एक निजी मार्केटप्लेस बनाएँ और वितरित करें

एक मार्केटप्लेस एक GitHub रेपो है जिसमें एक विशिष्ट फोल्डर संरचना है। प्रत्येक प्लगइन अपनी स्वयं की उप-निर्देशिका में रहता है। रेपो रूट में आपको एक registry.json की जरूरत है जो उपलब्ध चीजों को सूचीबद्ध करता है। प्लगइन मार्केटप्लेस दस्तावेज इस संरचना का विस्तार से वर्णन करते हैं, और mrlm-xyz/demo-claude-marketplace पर सामुदायिक डेमो एजेंट, कमांड और कौशल के साथ दो कार्यशील उदाहरण प्लगइन दिखाता है यदि आप शुरुआत से पहले एक ठोस संदर्भ चाहते हैं।

एक बार रिपॉजिटरी बन जाने के बाद, रिपॉजिटरी रूट में .claude/settings.json में Claude Code को इसके बारे में बताएँ:

{

"extraKnownMarketplaces": {

"company-tools": {

"source": {

"source": "github",

"repo": "your-org/claude-plugins"

}

}

},

"enabledPlugins": {

"deployment-tools@company-tools": true,

"code-formatter@company-tools": true

}

}

उस फ़ाइल को कमिट करें। अब हर टीम मेंबर जो प्रोजेक्ट फ़ोल्डर पर भरोसा करता है, वह मार्केटप्लेस को स्वचालित रूप से पाता है — कोई अतिरिक्त प्रॉम्प्ट नहीं और कोई मैनुअल CLI स्टेप नहीं। enabledPlugins ब्लॉक का मतलब है कि वे दोनों प्लगइन डिफ़ॉल्ट रूप से सक्रिय हैं। जो कोई भी उन्हें नहीं चाहता, स्थानीय रूप से अक्षम कर सकता है; डिफ़ॉल्ट केवल बाकी सभी के लिए परेशानी हटाते हैं।

अगर आप Team या Enterprise प्लान पर हैं और Organisation सेटिंग्स के माध्यम से वितरित कर रहे हैं, तो मार्केटप्लेस रिपॉजिटरी निजी या आंतरिक होनी चाहिए। Claude GitHub ऐप इसे पढ़ता है, इसलिए आपको स्पष्ट रूप से इसे एक्सेस देना होगा। एक सार्वजनिक रिपॉजिटरी उस पाथ में चुप्पी से विफल हो जाती है, जो अधिक भ्रामक त्रुटि मोड में से एक है।

जो टीमें बड़े पैमाने पर क्लाइंट-फेसिंग Claude Code काम का प्रबंधन करती हैं, Seahawk की Claude Code एजेंसी सर्विसेज मार्केटप्लेस सेटअप और चल रहे प्लगइन गवर्नेंस को संभालती हैं अगर आप उस इंफ्रास्ट्रक्चर को अपने लिए नहीं रखना चाहते।

संस्करण को नियंत्रित करें और अपडेट की समीक्षा करें

यह वह जगह है जहाँ अधिकांश निजी मार्केटप्लेसें गलत हो जाती हैं। लोग plugin.json में एक संस्करण पिन करते हैं, एक ही टैग के तहत एक महत्वपूर्ण परिवर्तन पुश करते हैं, और आश्चर्य करते हैं कि रोलबैक क्यों काम नहीं किया। Git टैग यहाँ संस्करण सत्य की सही इकाई है, केवल मैनिफेस्ट में संस्करण स्ट्रिंग नहीं।

वह वर्कफ़्लो जो वास्तव में बना रहता है:

1. plugin.json में version फ़ील्ड को बंप करें (semver का पालन करें: 1.2.0 से 1.3.0 बैकवर्ड-कम्पेटिबल जोड़ के लिए, 2.0.0 महत्वपूर्ण परिवर्तनों के लिए)।
2. कमिट और पुश करें।
3. एक git टैग बनाएँ: git tag v1.3.0 && git push origin v1.3.0।
4. registry.json को अपडेट करें ताकि प्लगइन एंट्री नए टैग की ओर इशारा करे।

किसी मशीन पर किसी विशेष संस्करण को इंस्टॉल करने के लिए:

/plugin install deployment-tools@company-tools --version 1.3.0

पिछले टैग पर रोलबैक करने के लिए:

/plugin install deployment-tools@company-tools --version 1.2.0

--version फ़्लैग सोर्स रिपॉजिटरी में git टैग के विरुद्ध हल करता है। अगर आपने टैग नहीं किया, तो Claude Code डिफ़ॉल्ट ब्रांच के HEAD पर वापस गिरता है, जिसका अर्थ है "रोलबैक" अर्थहीन है। हर रिलीज को टैग करें। इसमें दस सेकंड लगते हैं और वास्तविक दर्द बचाता है।

अपडेट समीक्षा के लिए, मार्केटप्लेस रिपॉजिटरी को किसी अन्य प्रोडक्शन कोडबेस की तरह मानें: कम से कम एक अनुमोदन के साथ एक पुल रिक्वेस्ट की आवश्यकता करें, और मुख्य में मर्ज करने से पहले README.md में एक चेंजलॉग प्रविष्टि। Anthropic के अपने डॉक्स नोट करते हैं कि प्लगइन अत्यंत विश्वसनीय घटक हैं जो मनमानी कोड निष्पादित कर सकते हैं, इसलिए प्लगइन रिपॉजिटरी पर एक-व्यक्ति-मर्ज नीति टीम आकार की परवाह किए बिना एक बुरा विचार है।

दूसरी मशीन पर इंस्टॉलेशन का परीक्षण करें

इससे पहले कि आप विस्तृत टीम को नया प्लगइन खींचने के लिए कहें, इसे पूरी तरह से ताज़ी प्रोफ़ाइल पर इंस्टॉल करें। एक अलग टर्मिनल विंडो नहीं। एक ताज़ी प्रोफ़ाइल कोई एम्बेडेड सीक्रेट नहीं, कोई मौजूदा प्लगइन स्टेट नहीं, और रिपॉजिटरी के settings.json में क्या है उसके अलावा कोई प्री-कॉन्फ़िगर्ड मार्केटप्लेस एंट्री नहीं।

क्लीन सेकेंड-मशीन टेस्ट के लिए नंबरड चेकलिस्ट:

1. प्रोजेक्ट रिपॉजिटरी क्लोन करें।
2. Claude Code खोलें और जब प्रॉम्प्ट किया जाए तो फ़ोल्डर पर भरोसा करें।
3. /plugin marketplace list के साथ मार्केटप्लेस की पुष्टि करें।
4. प्लगइन को स्पष्ट रूप से इंस्टॉल करें: /plugin install deployment-tools@company-tools।
5. उस स्लैश कमांड को चलाएँ जो प्लगइन expose करता है और verify करें कि वह expected output return करता है।
6. Hook को fire होते देखें relevant tool call को trigger करके और output को inspect करके।
7. Verify करें कि आपके dev machine के कोई credentials या local paths response में न दिखें।

यह आखिरी check महत्वपूर्ण है। Hook scripts जो absolute paths का reference करते हैं (/Users/yourname/scripts/...) हर दूसरी machine पर टूट जाते हैं। Plugin directory के relative paths या environment variables use करें जो teams consistently set कर सकें।

Names, paths और dependencies को troubleshoot करें।

ज़्यादातर installation failures तीन चीजों में से एक हैं।

Name mismatches। Plugin.json में plugin का नाम marketplace repo में directory के नाम से और registry.json में use किए गए नाम से बिल्कुल match करना चाहिए। Case-sensitive है। अगर plugin.json कहता है deployment-tools और registry entry कहता है Deployment-Tools, तो install command एक not-found error देता है जो capitalization से unrelated दिखता है।

Hooks में path issues। जैसा ऊपर कहा गया, absolute paths "works on my machine" bugs का सबसे बड़ा कारण हैं। Release tag करने से पहले हर hook script को hardcoded paths के लिए audit करें। एक quick grep -r "/Users" hooks/ सबसे common को catch करता है।

Dependency gaps। अगर आपका hook script कोई external binary call करता है (jq, gh, docker, कोई custom internal CLI), तो उस dependency को README.md में minimum version के साथ document करें। Claude Code आपके लिए external binary dependencies resolve नहीं करता। एक hook जो silently exit हो जाता है क्योंकि jq install नहीं है, diagnose करना मुश्किल है, खासकर team member के लिए जो नहीं जानता कि hook exist करता है।

अगर installation stall हो तो कुछ और चीजें check करने लायक हैं:

• GitHub App को private marketplace repo में read access चाहिए। अगर fetch hang हो तो Organisation settings को check करें।
• अगर extraKnownMarketplaces settings.json में है लेकिन folder को trust करने के बाद marketplace नहीं दिखता, तो confirm करें कि file committed है और trust prompt को accept किया गया था, dismiss नहीं।
• enabledPlugins में plugin names को name@marketplace format में बिल्कुल use करना चाहिए। deployment-tools अकेला marketplace qualifier के बिना resolve नहीं होगा।

Nagell की dev.to series auto-versioning और release CI को ज़्यादा depth में cover करती है अगर आप GitHub Actions को tagging workflow में wire करना चाहते हैं। CI step को manually build करने से पहले पढ़ने लायक है।

Broader context के लिए कि Claude Code कैसे real development workflow में plugins के आगे fit होता है, Claude Code superpowers का यह overview एक useful companion है।

FAQ

क्या मैं marketplace को GitHub के अलावा कहीं और host कर सकता हूँ?

settings.json में source field current plugin marketplace docs के अनुसार github और local को source types के रूप में support करता है। एक local path एक single machine या mounted network share के लिए काम करता है, लेकिन यह git-backed source की तरह auto-update नहीं होगा। Team distribution के साथ version tracking के लिए, एक private GitHub repo अभी practical चुनाव है।

क्या team members को private marketplace repo में अपना GitHub access चाहिए?

सीधे नहीं। अगर आप Team या Enterprise plan पर Organisation settings के through distribute कर रहे हैं, तो Claude GitHub App उन्हीं की ओर से repo को read करता है। अगर आप org sync path के बिना settings.json में extraKnownMarketplaces use कर रहे हैं, तो प्रत्येक user को अपने GitHub credentials के through या एक deploy key के through repo में read access चाहिए।

`enabledPlugins` और actually installing एक plugin में क्या फर्क है?

enabledPlugins settings.json में plugins को automatically activate करता है जब project folder trust किया जाता है। यह एक default है, forced install नहीं। एक user अभी भी locally एक plugin को disable कर सकता है। /plugin install के through manually install करने से plugin को regardless add किया जाता है कि settings.json क्या कहता है। दोनों mechanisms एक साथ काम करते हैं: convenience के लिए defaults, project context के बाहर कुछ भी के लिए manual install।

क्या मेरे पास एक organisation में multiple private marketplaces हो सकते हैं?

हाँ। extraKnownMarketplaces object multiple keys को accept करता है। प्रत्येक key एक local marketplace alias है, और प्रत्येक एक अलग source repo की ओर point करता है। आप company-tools, data-team-plugins और security-tools सभी को एक ही settings.json में register कर सकते हैं। बस aliases को unique रखें और claude-plugins-official या claude-community के साथ collide न करें।

यह Anthropic के आधिकारिक मार्केटप्लेस के साथ कैसे इंटरैक्ट करता है?

ये एक-दूसरे के साथ मौजूद रहते हैं। Claude Code पहली इंटरैक्टिव लॉन्च पर स्वचालित रूप से claude-plugins-official रजिस्टर करता है। आपका निजी मार्केटप्लेस इसके साथ जुड़ता है। आपके निजी मार्केटप्लेस से प्लगइन plugin-name@your-alias के रूप में संदर्भित होते हैं; आधिकारिक प्लगइन plugin-name@claude-plugins-official हैं। कोई संघर्ष नहीं, जब तक आपके प्लगइन नाम आधिकारिक नामों को डुप्लिकेट नहीं करते और रेजोल्यूशन में अस्पष्टता पैदा नहीं करते।

इस सब से सबसे तीव्र चेतावनी: git tags एकमात्र विश्वसनीय रोलबैक तंत्र हैं। plugin.json में एक संस्करण स्ट्रिंग बिना मेल खाने वाले tag के केवल सजावट है, न कि कोई रिकवरी विकल्प।