AI और एजेंट टूल्स

एजेंट के साथ कुछ बनाने का मतलब है ढेर सारी छोटी कॉन्फ़िगरेशन फ़ाइलें लिखना, जो चुपचाप विफल होती हैं। ऐसी स्किल जिसका विवरण कभी किसी काम से मेल नहीं खाता; ऐसा अनुमति नियम जो उस कमांड को कवर ही नहीं करता जो आपके मन में था; ऐसा हुक जिसका मैचर ऐसे टूल का नाम लेता है जो है ही नहीं; ऐसा टूल स्कीमा जो वैलिडेट हो जाता है पर फिर भी गलत तरीके से बुलाया जाता है। ये टूल उस काम को डिबगिंग के पूरे सत्र की कीमत चुकाने से पहले ही जाँच लेते हैं। स्किल फ़ाइलें, सबएजेंट परिभाषाएँ और स्लैश कमांड लिखें और लिंट करें। MCP सर्वर प्रविष्टियाँ, हुक और प्लगइन मैनिफ़ेस्ट बनाएँ, और अनुमति नियमों को असली कमांडों पर परखकर देखें कि कौन-सा नियम जीतता है। प्रॉम्प्ट की तरफ़: पंक्तियों की तालिका पर टेम्पलेट भरें, दो संस्करणों का शब्द-दर-शब्द अंतर टोकन के फ़र्क के साथ देखें, सिस्टम प्रॉम्प्ट में विरोधाभास पकड़ें, और ऐसे few-shot उदाहरण बनाएँ जो अपने टैग से बाहर न निकल सकें। आसपास के डेटा के लिए: JSONL पढ़ें और वैलिडेट करें, फ़ाइन-ट्यूनिंग डेटासेट जाँचें, स्ट्रीमिंग जवाब को फिर से जोड़ें, और किसी दस्तावेज़ को ऐसे टुकड़ों में बाँटें जो असली सीमाओं पर टूटें। और लागत के लिए: कॉन्टेक्स्ट विंडो का बजट बनाएँ, अनुरोध को ऐसे क्रम में रखें कि कैश होने लायक शुरुआती हिस्सा जितना हो सके लंबा रहे, और एजेंट लूप की लागत हर मोड़ पर उस इतिहास के साथ आँकें जिसे वह दोबारा भेजता है। सब कुछ आपके डिवाइस पर चलता है — प्रॉम्प्ट, डेटासेट और कॉन्फ़िगरेशन फ़ाइलें कभी अपलोड नहीं होतीं।

• स्किल बिल्डर — SKILL.md लिखिए, frontmatter साथ-साथ जाँचा जाता है।
• स्किल लिंटर — SKILL.md चिपकाइए और देखिए उसे किसी काम से जुड़ने से क्या रोक रहा है।
• सबएजेंट बिल्डर — सबएजेंट की परिभाषा फ़ाइल बनाइए, उसके उपकरण और मॉडल समेत।
• स्लैश कमांड बिल्डर — तर्कों और उपकरण सूची के साथ अपना कमांड बनाइए।
• परियोजना निर्देश बिल्डर — ऐसी CLAUDE.md लिखिए जो हर सत्र में अपनी जगह कमाए।
• प्लगइन मैनिफ़ेस्ट बिल्डर — plugin.json बनाइए और उसकी अपेक्षित फ़ोल्डर बनावट देखिए।
• हुक बिल्डर — settings.json के हुक बनाइए और कभी न चलने वाले मैचर पकड़िए।
• अनुमति नियम परीक्षक — अनुमति, पूछो और मनाही के नियम असली कमांडों पर आज़माइए।
• MCP सर्वर कॉन्फ़िग — stdio, HTTP या SSE के लिए MCP सर्वर प्रविष्टि बनाइए।
• MCP टूल स्कीमा बिल्डर — उपकरण तय कीजिए और JSON Schema पाइए, strict mode जाँच के साथ।
• टूल स्कीमा सत्यापन — परिभाषा चिपकाइए और जानिए वह क्यों अस्वीकार हो रही है।
• प्रॉम्प्ट टेम्पलेट भराई — एक प्रॉम्प्ट को पंक्तियों की तालिका पर फैलाइए और कमी देखिए।
• सिस्टम प्रॉम्प्ट लिंटर — विरोधाभास, बेअसर निर्देश और बिना भरे प्लेसहोल्डर ढूँढ़िए।
• प्रॉम्प्ट अंतर — दो संस्करण शब्द-दर-शब्द मिलाइए, टोकन अंतर के साथ।
• few-shot उदाहरण बिल्डर — इनपुट-आउटपुट जोड़ों को टैग, JSON या चैट रूप के उदाहरण बनाइए।
• XML प्रॉम्प्ट खंड बिल्डर — खंडों को ऐसे टैग में लपेटिए जिनसे सामग्री बाहर न निकले।
• JSONL व्यूअर और जाँच — JSONL फ़ाइल पंक्ति-दर-पंक्ति पढ़िए, छाँटिए और जाँचिए।
• बातचीत प्रतिलेख परिवर्तक — संदेशों के ऐरे को पढ़ने लायक़ प्रतिलेख में बदलिए, और वापस।
• डेटासेट जाँच — chat रूप का JSONL डेटासेट उन त्रुटियों के लिए जाँचिए जो प्रशिक्षण गिरा दें।
• SSE स्ट्रीम व्यूअर — कच्ची स्ट्रीम से पाठ, उपकरण कॉल और खपत वापस पाइए।
• संदर्भ विंडो योजना — विंडो को प्रॉम्प्ट, उपकरण, इतिहास और जवाब में बाँटिए।
• प्रॉम्प्ट कैश योजना — ब्लॉक ऐसे क्रम में रखिए कि कैश होने वाला उपसर्ग सबसे लंबा हो।
• पाठ चंकर — दस्तावेज़ को असली सीमाओं पर टूटने वाले ओवरलैप टुकड़ों में बाँटिए।
• एजेंट लूप ख़र्च अनुमान — बारी-दर-बारी ख़र्च निकालिए, दोबारा भेजे इतिहास और कैश के साथ।
• थोक अनुरोध बिल्डर — पंक्तियों की तालिका को अलग पहचान वाले थोक कार्य में बदलिए।

अक्सर पूछे जाने वाले प्रश्न

ये AI टूल किस काम के हैं?

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

क्या इनमें से कोई टूल मेरे प्रॉम्प्ट कहीं भेजता है?

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

क्या मॉडल की क़ीमतें और कॉन्टेक्स्ट सीमाएँ ताज़ा हैं?

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

क्या ये सिर्फ़ एक प्रदाता के साथ काम करते हैं?

फ़ाइल फ़ॉर्मैट — स्किल, सबएजेंट, स्लैश कमांड, हुक, MCP — उन्हीं परंपराओं पर चलते हैं जो ये फ़ॉर्मैट अपनाते हैं। बाकी सब प्रदाता-निरपेक्ष है: JSONL, चैट ट्रांसक्रिप्ट, स्ट्रीमिंग इवेंट, चंकिंग, टोकन बजट और प्रॉम्प्ट की बनावट एक जैसे काम करते हैं, आप उन्हें किसी भी मॉडल को भेजें।

किसी स्किल या टूल के विवरण को इतनी बारीकी से क्यों जाँचें?

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