मैंने खुद को एक हफ्ते में चौथी बार वही 200 शब्दों का प्रॉम्प्ट टाइप करते हुए पकड़ा। "स्टेज किए गए बदलावों के लिए एक conventional commit मैसेज लिखो, पहली लाइन 72 अक्षरों से कम रखो, अगर ब्रांच नाम में issue नंबर है तो उसे body में mention करो..." हर। एक। बार। यही वो पल है जब आपको रुककर एक स्लैश कमांड बना लेना चाहिए। तो चलिए Claude Code स्लैश कमांड और स्किल्स सेट अप करते हैं, ताकि यह सब दोबारा टाइप न करना पड़े।
दोनों फीचर मूल रूप से एक ही काम करते हैं — निर्देशों को पैकेज करके दोबारा इस्तेमाल के लायक बनाना — लेकिन दोनों अलग-अलग काम के लिए बने हैं। स्लैश कमांड उन चीज़ों के लिए हैं जो आप ट्रिगर करते हैं। स्किल्स उन चीज़ों के लिए हैं जो Claude तब ट्रिगर करता है जब किसी काम में उनकी ज़रूरत हो। यह फर्क समझ लिया तो बाकी सब आसान है।
स्लैश कमांड: आपके शॉर्टकट
स्लैश कमांड एक सेव किया हुआ प्रॉम्प्ट है जिसे आप /नाम से चलाते हैं। इसे बनाने के लिए अपने प्रोजेक्ट में .claude/commands/ फोल्डर में एक markdown फाइल डालें। फाइल का नाम ही कमांड बन जाता है।
चलिए उस commit message प्रॉम्प्ट का हमेशा के लिए काम तमाम करते हैं। .claude/commands/commit.md बनाएं:
अभी स्टेज किए गए बदलावों के लिए एक conventional commit मैसेज लिखो।
नियम:
- पहली लाइन 72 अक्षरों से कम, imperative mood में ("Add", न कि "Added")।
- Type prefix: feat, fix, refactor, docs, test, या chore।
- अगर ब्रांच नाम में कोई issue नंबर है, तो उसे body में reference करो।
- मुझे मैसेज दिखाओ। खुद git commit मत चलाओ।
पहले `git diff --staged` चलाओ ताकि देख सको क्या बदला है।
अब किसी भी सेशन में /commit टाइप करो और Claude पूरा काम कर देता है। दो सौ की जगह बस एक शब्द। फाइल ही कमांड है — जब भी इसे invoke करो, उसमें लिखा सब कुछ मेरे प्रॉम्प्ट के रूप में भेज दिया जाता है।
आर्गुमेंट पास करना
जब कमांड में input लिया जाए तो यह और भी उपयोगी हो जाता है। $ARGUMENTS को placeholder की तरह इस्तेमाल करें। यहाँ .claude/commands/explain.md है:
इस कोडबेस में $ARGUMENTS कैसे काम करता है, यह समझाओ।
जहाँ यह define है वहाँ जाओ, कैसे use होता है यह trace करो, और मुझे
एक छोटा plain-English सारांश दो। ढूंढने के लिए एक subagent का इस्तेमाल करो
ताकि हमारी बातचीत फाइल dumps से न भर जाए।
फिर /explain auth flow लिखने पर "auth flow" उस जगह भर जाता है। एक कमांड, अनगिनत उपयोग। मेरे पास अब इस तरह के एक दर्जन कमांड हैं — /test, /review, /changelog — और इन्होंने चुपचाप मेरे दिन से ज़्यादातर boilerplate हटा दिया है।
स्किल्स: वो निर्देश जिन्हें Claude खुद ढूंढता है
स्लैश कमांड तब बढ़िया काम करते हैं जब आपको पता हो आप क्या चाहते हैं। लेकिन कभी-कभी आप चाहते हैं कि Claude बीच काम में, बिना आपको कुछ invoke किए, खुद ब खुद specialized knowledge लगाए। यही skill का काम है।
स्किल एक ऐसा फोल्डर होता है जिसमें SKILL.md फाइल होती है। उस फाइल के ऊपर लिखा होता है कि स्किल कब लागू होती है। Claude उस description को ध्यान में रखता है, और जब कोई काम उससे match करे, तो वह खुद पूरे निर्देश लोड कर लेता है। आपको कोई कमांड नहीं टाइप करना। यह बस हो जाता है।
मान लीजिए आपकी टीम database migrations लिखने का एक सख्त तरीका follow करती है। .claude/skills/migrations/SKILL.md बनाएं:
---
name: migrations
description: इस प्रोजेक्ट में database migrations लिखने का तरीका।
Migration फाइल बनाते, edit करते, या review करते समय उपयोग करें।
---
Migrations db/migrations में रहती हैं, नाम में UTC timestamp prefix होता है।
हर migration में ज़रूरी है:
- Reversible होना — up और down दोनों include करें।
- जिस migration में किसी column पर लिखना बंद करते हों, उसी में उसे drop न करें।
इसे दो deploys में बाँटें।
- Schema बदलाव को transaction में wrap करें।
लिखने से पहले, style match करने के लिए पिछली तीन migrations पढ़ें।
अब जब मैं Claude से कहता हूँ "नए archived_at column के लिए migration जोड़ो," तो वह notice करता है कि काम skill की description से match करता है, ये rules load करता है, और इन्हें follow करता है — बिना मेरे "skill" शब्द कहे। यही इसका जादू है। ज्ञान ठीक तब आता है जब ज़रूरत हो, और बाकी समय रास्ते से हट जाता है।
कौन सा बनाऊं?
यहाँ वो सरल नियम है जो मैं इस्तेमाल करता हूँ।
स्लैश कमांड बनाएं जब आप तय करते हों कि इसे कब चलाना है। Commit messages, changelog generate करना, कोई specific review शुरू करना — ये सब जानबूझकर किए जाने वाले काम हैं। आप इन्हें invoke करते हैं।
स्किल बनाएं जब Claude को खुद तय करना हो। Coding conventions, domain rules, formatting standards — कोई भी चीज़ जो जब भी matching काम आए तो अपने आप लागू होनी चाहिए। आप हर बार database छूते वक्त /migrations याद नहीं रखना चाहते। आप चाहते हैं कि rules बस वहाँ हों।
एक अच्छा तरीका: अगर वाक्य "जब भी Claude X करे, उसे..." से शुरू होता है — वो skill है। अगर "कभी-कभी मैं चाहता हूँ कि..." से शुरू होता है — वो command है।
Description ही असली नींव है
Skills के लिए खासतौर पर, description लाइन सबसे ज़रूरी है। इसी से Claude तय करता है कि skill लागू होती है या नहीं। अस्पष्ट description हो तो skill कभी fire नहीं करेगी। Trigger के बारे में ठोस बात करें: "Migration फाइल बनाते, edit करते, या review करते समय उपयोग करें" — Claude को ठीक-ठीक पता चलता है कि कब जागना है। "Database वाली चीज़ें" नहीं चलेगा।
यह एक अच्छे tool description लिखने जैसी ही बात है। आप एक ऐसे agent के लिए लिख रहे हैं जिसे उसी पल तय करना है कि यह चीज़ relevant है या नहीं। उसे एक साफ हाँ/न का जवाब दें।
जो सबसे ज़्यादा परेशान करे, उससे शुरू करें
एक साथ बैठकर बीस commands मत बनाइए। आप गलत अंदाज़ा लगाएंगे कि आपको असल में क्या चाहिए। बजाय इसके, तब तक रुकें जब तक घर्षण न महसूस हो — चौथी बार वही टाइप करना, वो नियम जो आप बार-बार समझाते हैं — और वही एक बनाएं। ठीक उसी वक्त। दो मिनट लगते हैं और फायदा तुरंत दिखता है।
मेरा पूरा कलेक्शन इसी तरह बड़ा हुआ, एक परेशानी के बाद एक। Commit command commit prompts को बार-बार टाइप करने से आया। Migrations skill एक ही migration गलती दो बार करने से आई। हर एक ने एक असली, खास जलन को दूर किया जिसे मैं नाम से बता सकता था।
तो यह है आपका होमवर्क। अगली बार जब आप खुद को वो प्रॉम्प्ट टाइप करते पाएं जो पहले भी टाइप कर चुके हैं, रुकें। .claude/commands/ खोलें, एक फाइल बनाएं, प्रॉम्प्ट उसमें paste करें। आपने अभी-अभी उन दो मिनटों का हर भविष्य का copy वापस खरीद लिया। दस बार करें और आपका Claude Code setup generic नहीं लगेगा — वो आपका लगने लगेगा।