Claude Code Skill कैसे बनाएं जो वास्तव में काम करे (पूर्ण गाइड)

@undefinedKi
अंग्रेज़ी3 दिन पहले · 18 जुल॰ 2026
116K
75
10
12
176

TL;DR

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

आप एक सप्ताह से Claude का उपयोग कर रहे हैं और हर बार एक ही चीज़ टाइप करते हैं। जब भी आप कोड कमिट करते हैं, तो आप अपने कमिट फ़ॉर्मेट के बारे में वही तीन नियम पेस्ट करते हैं। जब भी आप कोई दस्तावेज़ लिखते हैं, तो आप अपनी शैली फिर से समझाते हैं। Claude यह अच्छी तरह से करता है, लेकिन चैट खत्म होते ही भूल जाता है, और कल आपको यह सब फिर से टाइप करना होगा।

एक स्किल इस समस्या को ठीक करती है। यह एक छोटा सा फ़ोल्डर है जिसे आप एक बार लिखते हैं जो Claude को एक वर्कफ़्लो स्थायी रूप से सिखाता है, ताकि यह हर सत्र में बिना पूछे लागू हो जाए।

यहाँ बताया गया है कि यह एक नज़र में कैसे काम करता है: एक स्किल एक फ़ोल्डर है जिसके अंदर एक फ़ाइल होती है। Claude हर समय इसका एक-पंक्ति का सारांश देखता रहता है, और पूर्ण निर्देशों को तभी लाता है जब आपका अनुरोध मेल खाता है। यही पूरी प्रक्रिया है।

इस गाइड में हम शुरुआत से एक वास्तविक स्किल बनाते हैं: commit-messages, जो आपके सटीक फ़ॉर्मेट में git कमिट लिखता है। यदि आपके पास Claude इंस्टॉल है और कुछ नहीं, तो आप हर चरण का पालन कर सकते हैं।

आपको अंत में क्या मिलेगा

इसके मूल में, एक स्किल एक फ़ोल्डर है जिसमें एक आवश्यक फ़ाइल होती है, SKILL.md। तीन वैकल्पिक फ़ोल्डर बाद में आते हैं जैसे-जैसे स्किल बढ़ती है:

text
1your-skill-name/
2├── SKILL.md # आवश्यक - मुख्य स्किल फ़ाइल
3├── scripts/ # वैकल्पिक - निष्पादन योग्य कोड
4├── references/ # वैकल्पिक - दस्तावेज़ीकरण
5└── assets/ # वैकल्पिक - टेम्पलेट, आदि।

SKILL.md में स्वयं दो भाग होते हैं: एक छोटा हेडर जो Claude को बताता है कि स्किल का उपयोग कब करना है, और उसके नीचे निर्देश जो Claude को बताते हैं कि क्या करना है। विभाजन का कारण मायने रखता है। Claude लगातार हेडर पढ़ता है, इसलिए उसे हमेशा पता रहता है कि स्किल मौजूद है, लेकिन यह निर्देशों को तभी लोड करता है जब आपका अनुरोध मेल खाता है। इस अंतर को ध्यान में रखें, क्योंकि इस गाइड में लगभग बाकी सब कुछ इसी से अनुसरण करता है।

इसे बनाएँ

स्किल्स आपकी होम डायरेक्टरी के अंदर .claude/skills नामक फ़ोल्डर में रहती हैं, जिसे Claude Code और डेस्कटॉप ऐप दोनों पढ़ते हैं। यह छिपा हुआ है और शायद अभी मौजूद नहीं है, इसलिए इसे, आपकी स्किल के फ़ोल्डर के साथ, बनाने का सबसे तेज़ तरीका एक ही कमांड है।

Mac पर, Terminal खोलें और चलाएँ:

bash
1mkdir -p ~/.claude/skills/your-skill-name

Windows पर, PowerShell खोलें और चलाएँ:

text
1New-Item -ItemType Directory -Force -Path "$HOME\.claude\skills\your-skill-name"

फ़ोल्डर का नाम केवल दिखावा नहीं है। Claude इसे स्किल के पहचानकर्ता के रूप में उपयोग करता है, और एक फ़ॉर्मेटिंग नियम लोगों को किसी भी अन्य से अधिक परेशान करता है:

  • kebab-case का उपयोग करें: notion-project-setup ✔
  • कोई स्पेस नहीं: Notion Project Setup ✖
  • कोई अंडरस्कोर नहीं: notion_project_setup ✖
  • कोई कैपिटल नहीं: NotionProjectSetup ✖

उस फ़ोल्डर के अंदर, SKILL.md नाम की एक फ़ाइल बनाएँ और इसे किसी भी टेक्स्ट एडिटर में खोलें। अब से सब कुछ वही है जो उस फ़ाइल में जाता है।

इसे लिखने से पहले डिज़ाइन करें

जो स्किल्स काम करती हैं, वे दो निर्णयों से शुरू होती हैं, जो फ़ाइल की एक पंक्ति लिखने से पहले लिए जाते हैं। दोनों को छोड़ने योग्य लगता है और दोनों में से कोई भी नहीं है।

पहला, ठीक से तय करें कि स्किल कब सक्रिय होनी चाहिए। वास्तविक स्थितियों में से दो या तीन को उन शब्दों में लिखें जो उपयोगकर्ता वास्तव में टाइप करेगा:

  • "इन बदलावों को कमिट करें"
  • "इस डिफ़ के लिए कमिट संदेश लिखें"
  • "स्टेज और कमिट करें"

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

दूसरा, तय करें कि आपको कैसे पता चलेगा कि यह काम करता है। सबसे महत्वपूर्ण मापदंड यह है कि क्या स्किल अपने आप लोड होती है, बिना आपके इसे नाम दिए। यदि आपको इसे हर बार मैन्युअल रूप से लागू करना पड़ता है, तो स्किल तकनीकी रूप से चलती है लेकिन अपने वास्तविक काम में विफल रही है। इसके साथ देखने लायक यह है: क्या यह आपके बीच में सुधार किए बिना कार्य पूरा करती है, और क्या यह आपको अलग-अलग सत्रों में समान आकार का परिणाम देती है।

विवरण ही इसे बनाता या बिगाड़ता है

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

एक मजबूत विवरण एक वाक्य में दो सवालों का जवाब देता है: स्किल क्या करती है, और Claude को इसके लिए कब पहुँचना चाहिए। वह दूसरा भाग वह है जिसे लोग छोड़ देते हैं।

यहाँ अंतर है:

yaml
1# कमज़ोर - बताता है कि यह क्या है, Claude को अनुरोध से मिलान करने के लिए कुछ नहीं देता
2description: git कमिट में मदद करता है।
3
4# मजबूत - उन क्षणों का नाम बताता है जिन पर इसे सक्रिय होना चाहिए
5description: Conventional Commits फ़ॉर्मेट में git कमिट संदेश लिखता है। उपयोग करें जब उपयोगकर्ता बदलावों को कमिट करने, कमिट संदेश लिखने, या फ़ाइलों को स्टेज और कमिट करने के लिए कहे।

कमज़ोर संस्करण Claude को बताता है कि स्किल मौजूद है लेकिन इसे कभी भी आपके द्वारा कही गई किसी भी चीज़ से नहीं जोड़ता। मजबूत संस्करण वास्तविक वाक्यांशों का नाम बताता है, इसलिए जब आप "इन बदलावों को कमिट करें" टाइप करते हैं, तो Claude के पास मिलान करने के लिए कुछ होता है। उन शब्दों का नाम बताएं जो एक उपयोगकर्ता वास्तव में उपयोग करेगा, पूरी चीज़ को 1024 वर्णों से कम रखें, और इसके अंदर < या > न डालें।

जब कोई स्किल ट्रिगर नहीं होगी, तो सुधार लगभग हमेशा यहाँ होता है। उन वाक्यांशों को जोड़ें जिनका आप वास्तव में उपयोग करते हैं। यदि आप "मेरे काम को सहेजें" कहते हैं लेकिन विवरण में केवल "कमिट" का उल्लेख है, तो Claude के पास दोनों को जोड़ने का कोई तरीका नहीं है। और यदि विपरीत होता है और स्किल तब सक्रिय होती है जब उसे नहीं होना चाहिए, तो विवरण को संकीर्ण करें या एक नकारात्मक ट्रिगर जोड़ें:

yaml
1description: Conventional Commits फ़ॉर्मेट में git कमिट संदेश लिखता है। बदलावों को कमिट करते समय उपयोग करें। कोड टिप्पणियाँ या दस्तावेज़ीकरण लिखने के लिए उपयोग न करें।

इस पर भरोसा करने से पहले अपने काम की जाँच करने का एक त्वरित तरीका है। सीधे Claude से पूछें:

"आप commit-messages स्किल का उपयोग कब करेंगे?"

Claude आपके विवरण को अपने शब्दों में वापस पढ़ेगा। यदि यह उस समय से मेल नहीं खाता जब आप वास्तव में स्किल को सक्रिय करना चाहते हैं, तो आपको अपनी समस्या मिल गई है, और यह विवरण में है, नीचे के निर्देशों में नहीं।

ऐसे निर्देश लिखें जिनका Claude वास्तव में पालन करे

हेडर के नीचे बॉडी आती है, सादे Markdown में। यह वह जगह है जहाँ आपका वास्तविक वर्कफ़्लो रहता है, और दो आदतें उन निर्देशों को अलग करती हैं जिनका Claude पालन करता है उनसे जिन्हें वह चुपचाप अनदेखा कर देता है।

पहला विशिष्ट होना है। Claude ठोस निर्देशों पर कार्य करता है और अस्पष्ट निर्देशों को अनदेखा करता है, इसलिए आप जितने अधिक सटीक होंगे, यह उतना ही विश्वसनीय रूप से व्यवहार करता है:

markdown
1# खराब
2अंतिम रूप देने से पहले कमिट को मान्य करें।
3
4# अच्छा
5`python scripts/validate.py "<message>"` चलाएँ।
6यदि यह विफल होता है, तो इन्हें ठीक करें:
7- अमान्य प्रकार: feat, fix, docs, refactor, test, chore का उपयोग करें
8- सारांश 60 वर्णों से अधिक: इसे छोटा करें

दूसरा क्रम है। Claude वही तौलता है जो वह पहले पढ़ता है, इसलिए एक लंबी फ़ाइल के नीचे दबा हुआ नियम एक ऐसा नियम है जो छूट जाता है। कुछ भी जो टूटना नहीं चाहिए, उसे शीर्ष पर रखें, एक शीर्षक के नीचे जो इसे संकेत देता है:

markdown
1## महत्वपूर्ण
2- सारांश पंक्ति हमेशा 60 वर्णों से कम
3- केवल वर्तमान काल: "add", "added" नहीं

भाषा जो गारंटी दे सकती है, उसकी भी एक सीमा है। निर्देशों की व्याख्या की जाती है, जिसका अर्थ है कि Claude उनका अच्छी तरह से पालन करता है लेकिन हर बार समान रूप से नहीं। जब किसी जाँच को वास्तव में हर रन पर पास होना है, तो इसे गद्य में वर्णन न करें, इसे एक स्क्रिप्ट में ले जाएँ और निर्देशों को इसे चलाने के लिए कहें। कोड हर बार एक ही काम करता है; एक वाक्य नहीं करता। (यही scripts/ फ़ोल्डर के लिए है, जिसे आगे कवर किया गया है।)

एक संरचना जो अधिकांश स्किल्स में बनी रहती है, वह इस तरह दिखती है:

markdown
1# स्किल का नाम
2
3## महत्वपूर्ण
4महत्वपूर्ण नियम जिन्हें छोड़ा नहीं जाना चाहिए।
5
6## निर्देश
7चरण दर चरण, विशिष्ट और कार्रवाई योग्य।
8
9## उदाहरण
10ठोस इनपुट और आउटपुट। Claude नियमों का पालन करने की तुलना में उदाहरणों की अधिक विश्वसनीय रूप से नकल करता है।

फ़ाइल को पतला रखें। जिस क्षण यह अपने मुख्य निर्देशों से आगे बढ़ने लगे, वह क्षण अतिरिक्त विवरण को बाहर निकालने का है, जो कि वैकल्पिक फ़ोल्डरों के लिए बिल्कुल सही है।

स्क्रिप्ट्स, संदर्भ, संपत्तियाँ

अब तक सब कुछ एक ऐसी स्किल उत्पन्न करता है जो Claude को निर्देश देती है। तीन वैकल्पिक फ़ोल्डर इसे एक ऐसी स्किल में बदल देते हैं जो Claude को उपकरण देती है, और यह वह जगह है जहाँ एक स्किल ऐसे काम करती है जो एक सादा प्रॉम्प्ट नहीं कर सकता।

scripts/ में कोड होता है जिसे Claude चलाता है, किसी भी चीज़ के लिए जो सटीक होनी चाहिए। Claude पर यह भरोसा करने के बजाय कि वह आँख से देख लेगा कि कमिट सही ढंग से फ़ॉर्मेट किया गया है या नहीं, आप इसे एक स्क्रिप्ट देते हैं जो जाँच करती है:

python
1# scripts/validate.py
2import sys
3msg = sys.argv[1]
4types = ("feat", "fix", "docs", "refactor", "test", "chore")
5
6if msg.split(":")[0] not in types:
7 print(f"Invalid type. Use: {', '.join(types)}")
8elif len(msg.split("\n")[0]) > 60:
9 print("Summary too long (over 60 chars)")
10else:
11 print("OK")

फिर आप Claude को SKILL.md में इसका उपयोग करने के लिए कहते हैं:

markdown
1अंतिम रूप देने से पहले, `python scripts/validate.py "<message>"` चलाएँ
2और वह जो कुछ भी फ़्लैग करता है उसे ठीक करें।

अब फ़ॉर्मेट नियम कोड द्वारा लागू किया जाता है जो हर बार एक ही तरह से चलता है, न कि Claude पर जाँच करना याद रखने पर निर्भर रहता है।

references/ में दस्तावेज़ होता है जो केवल ज़रूरत पड़ने पर लोड होता है। मान लें कि आपके कमिट कन्वेंशन स्कोप, फ़ुटर और एज केस के दो पेजों तक चलते हैं। यह सब SKILL.md में डालें और यह हर एक कमिट पर लोड होता है, यहाँ तक कि एक-लाइनर पर भी। इसके बजाय इसे एक संदर्भ फ़ाइल में ले जाएँ:

text
1your-skill-name/
2├── SKILL.md
3└── references/
4 └── conventions.md

और मुख्य फ़ाइल से इसे इंगित करें:

markdown
1पूर्ण कन्वेंशन सूची के लिए, references/conventions.md देखें

Claude उस फ़ाइल को तभी खोलता है जब कार्य इसकी माँग करता है। स्किल्स के सस्ते चलने का यही पूरा कारण है: भारी विवरण डिस्क पर तब तक बैठा रहता है जब तक कि यह वास्तव में प्रासंगिक न हो, बजाय इसके कि हर बार संदर्भ में साथ चले।

assets/ में वे फ़ाइलें होती हैं जिनका उपयोग स्किल अपने आउटपुट में करती है, न कि मार्गदर्शन के लिए पढ़ती है, जैसे कोई टेम्पलेट, कोई कॉन्फ़िग फ़ाइल, या कोई लोगो। एक कमिट स्किल को किसी की आवश्यकता नहीं है, लेकिन एक स्किल जो रिपोर्ट उत्पन्न करती है, वह यहाँ एक template.md रख सकती है और हर बार इसे भर सकती है, ताकि हर रिपोर्ट एक ही संरचना के साथ आए।

एक साथ लेने पर, ये तीन फ़ोल्डर उस स्किल के बीच का अंतर हैं जो Claude को बताती है कि आप कैसे काम करते हैं और जो Claude को आपके तरीके से काम करने के लिए सटीक उपकरण देती है।

याद रखने वाली एक बात

एक स्किल Claude को कोई नई क्षमता नहीं सिखा रही है। वह पहले से ही जानता है कि कमिट कैसे लिखना है। स्किल जो करती है वह है काम को आपके तरीके से, हर बार, बिना आपके इसे फिर से समझाए, करवाना।

और जब कोई स्किल काम नहीं करती है, तो इसका कारण लगभग कभी भी वे निर्देश नहीं होते जिन पर आपने मेहनत की थी। यह विवरण है। Claude उस एक पंक्ति से स्किल को लोड करने का निर्णय लेता है, इससे पहले कि वह नीचे के काम को कभी पढ़े। विवरण को सही पाएँ और नीचे की हर चीज़ का अंततः उपयोग होगा।

यदि यह उपयोगी था, तो मेरे प्रोफ़ाइल पर जाएँ और फ़ॉलो करें। मैं तकनीक, AI, और ऐसी प्रणालियों के बारे में लिखता हूँ जो वास्तव में चलती हैं।

Ciao,

@undefinedKi

YouMind में रीमिक्स करें

Turn one viral article into a full content workflow

Collect the source, decode the pattern, create assets, draft the story, and distribute from one AI workspace.

Explore YouMind
क्रिएटर्स के लिए

अपने Markdown को एक साफ़-सुथरे 𝕏 आर्टिकल में बदलें

जब आप अपना लंबा कंटेंट पब्लिश करते हैं, तो इमेज, टेबल और कोड ब्लॉक को 𝕏 के लिए फ़ॉर्मेट करना मुश्किल होता है। YouMind पूरे Markdown ड्राफ़्ट को एक साफ़-सुथरे, पोस्ट के लिए तैयार 𝕏 आर्टिकल में बदल देता है।

Markdown से 𝕏 आज़माएँ

समझने के लिए और पैटर्न

हाल के वायरल लेख

और वायरल लेख देखें