तीसरी चैट फिर से उसी स्पष्टीकरण से शुरू होती है: ब्रीफ़िंग में कौन-से विवरण होने चाहिए, टीम कौन-से शब्दों का उपयोग करती है और कुछ छूट जाने पर क्या होना चाहिए? दोहराव इस बात का अच्छा संकेत है कि आप काम करने के किसी तरीके को लिखित रूप दे सकते हैं। एक skill उसे एक पुन: उपयोग योग्य निर्देश में बदल देती है, जिसे आप सोच-समझकर लागू करते हैं और जिसका रखरखाव करते रहते हैं।
Claude Code के लिए आधिकारिक skills दस्तावेज़ीकरण मेटाडेटा और निर्देशों वाली एक SKILL.md का वर्णन करता है। इसका उपयोग तब किया जा सकता है जब कोई कार्य उपयुक्त हो या जब इसे स्पष्ट रूप से बुलाया जाए। इससे काम के लिए निर्देश बदलता है, प्रशिक्षित मॉडल के वेट्स नहीं। नीचे दी गई फ़ाइलें हमारा अपना उदाहरणात्मक मसौदा हैं, किसी वास्तव में किए गए रन की रिपोर्ट नहीं।
पहले निर्णय, फिर फ़ाइल
हमारा उदाहरण एक मासिक मरम्मत संध्या है। संगठनात्मक नोट्स से एक आंतरिक ब्रीफ़िंग तैयार की जानी है। इसमें सहायकों को पुष्टि की गई व्यवस्थाएँ, कार्य और खुले निर्णय चाहिए। यह पूरे कार्यक्रम की योजना बनाने से छोटा काम है।
पहले से एक इनपुट अनुबंध लिख लीजिए। हर विवरण के लिए एक मान और एक स्थिति आवश्यक है। “प्रारंभ 18:00, पुष्टि हुई” और “प्रारंभ 18:00, सुझाव” अलग-अलग बातें हैं। एआई को यह अंतर बनाए रखना चाहिए। यदि स्थल का विवरण नहीं है, तो वह एक खुला प्रश्न है; विश्वसनीय लगने वाला कोई वैकल्पिक पता इस काम को बिगाड़ देगा।
SKILL.md को छोटा और स्पष्ट रखिए
प्रोजेक्ट-स्तर पर एक संभावित स्थान है .claude/skills/reparaturbrief/। इसमें आपका अपना निम्नलिखित कार्य-निर्देश हो सकता है। मेटाडेटा बताता है कि इसकी आवश्यकता कब है; उसके नीचे का पाठ बताता है कि इसे क्या देना चाहिए।
---
name: reparaturbrief
description: Creates internal briefings for repair evenings from organisational notes.
---
Record confirmed details and suggestions separately.
Do not invent venues, dates, names or commitments.
If there are contradictions: state both details and phrase a follow-up question.
Output:
1. Confirmed arrangements
2. Tasks with confirmed responsibility
3. Open decisions with a reference to the input
4. Next coordination step“संगठन से जुड़ी हर चीज़ में मदद करती है” जैसा विवरण कम बताएगा। इससे यह देखना कठिन हो जाता है कि skill कहाँ उपयुक्त है और कब काम करने का कोई दूसरा तरीका उचित है। एक स्पष्ट सीमा बाद के रखरखाव को भी आसान बनाती है।
वास्तविक कमी वाला एक नमूना हैंड-ओवर
कृत्रिम नोट्स का उपयोग कीजिए: कमरे की पुष्टि हो चुकी है, प्रारंभ का समय अभी केवल एक सुझाव है, और सामग्री तभी ऑर्डर की जाएगी जब बजट स्वीकृत हो जाएगा। इन शर्तों को सीधे बताइए। अपेक्षित आउटपुट में “बजट स्पष्ट करें” जैसा कार्य हो सकता है। दूसरी ओर, “सामग्री ऑर्डर कर दी गई” एक नया, असमर्थित दावा होगा।
एक सहायक अतिरिक्त निर्देश यह है: “हर खुले निर्णय के लिए बताइए कि इनपुट का कौन-सा हिस्सा उसे जन्म देता है।” इससे कमी और उसके स्रोत के बीच एक संबंध बनता है। skill को पूरा मूल पाठ दोहराने की आवश्यकता नहीं है; उसे विवादित विवरण को आसानी से खोजने योग्य बनाना चाहिए।
शैली संबंधी पसंद को सामग्री संबंधी नियमों से अलग रखिए। छोटे कार्य-विवरणों का एक उदाहरण सहायक फ़ाइल के रूप में काम आ सकता है। इसके विपरीत, बार-बार बदलने वाले कार्यक्रम के विवरण अलग-अलग काम के अनुरोध में होने चाहिए। इस तरह सामान्य निर्देश अगली तारीख के साथ पुराना नहीं पड़ता।
तीन मामले अलग-अलग कमज़ोरियाँ उजागर करते हैं
पहले मामले में आप संपूर्ण, सुसंगत विवरण देते हैं। दूसरे में तारीख नहीं है और बजट से जुड़े दो नोट एक-दूसरे का खंडन करते हैं। तीसरे में आप skill के क्षेत्र से बाहर की कोई चीज़ माँगते हैं, जैसे यात्रा की योजना। इससे आप संरचना, अनिश्चितता से निपटने और उपयोग की सीमाओं को अलग-अलग देख सकते हैं।
हर मामले के लिए लिखिए कि किस चीज़ को हर हाल में बनाए रखना है। किसी उत्तर को पहले इसी आधार पर परखिए और उसके बाद ही उसकी शैली पर। सुंदर शब्दावली किसी गढ़ी हुई तारीख की भरपाई नहीं करती। इसी तरह, यदि इनपुट में ठीक वही निर्णय नहीं है, तो अनुवर्ती प्रश्न पूछना कोई त्रुटि नहीं है।
एक छोटे कार्य-निर्देश का रखरखाव
जब कोई समस्या बार-बार आए, तो एक विशिष्ट नियम बदलिए और मौजूदा मामलों को दोहराइए। एक ऐसा नया मामला जोड़िए जो बदलाव लिखते समय ज्ञात नहीं था। इससे यह देखना आसान होता है कि कहीं नियम केवल किसी एक उदाहरण की नकल तो नहीं कर रहा।
बदलाव का कारण और उसकी स्थिति दर्ज कीजिए। शुरुआत में इसके लिए किसी बड़े इन्फ्रास्ट्रक्चर की आवश्यकता नहीं होती। “बजट की शर्तें कार्य-सूची में बनी रहनी चाहिए” जैसा छोटा नोट बिना कारण के किए गए पूरे पुनर्लेखन की तुलना में समझना आसान है। एक skill तब सार्थक होती है जब उसके नियम अगले वास्तविक हैंड-ओवर को समझना आसान बनाते हैं।
स्रोत और दस्तावेज़ीकरण की स्थिति: 25 अक्टूबर 2026।
