2,465 सार्वजनिक रूप से सूचीबद्ध AI-agent "skills" के एक ताज़ा ऑडिट में पाया गया कि आधे से अधिक प्रकाशित specification का उल्लंघन करते हैं, और 7.8 प्रतिशत को तो एक agent द्वारा चुना भी नहीं जा सकता क्योंकि उनमें आवश्यक metadata की कमी है। ये दोष उन किसी भी सिस्टम की विश्वसनीयता के लिए खतरा पैदा करते हैं जो स्वचालित रूप से इन skills को खोजते और लोड करते हैं।
Why the audit matters
Agent-skill रजिस्ट्रियां डेवलपर्स को पुन: प्रयोज्य क्षमताएं (reusable capabilities) प्रकाशित करने की अनुमति देती हैं—कोड पैकेज जिन्हें एक स्वायत्त agent मांग पर बुला सकता है। एक agent रजिस्ट्री को स्कैन करता है, प्रत्येक skill के YAML frontmatter (एक छोटा संरचित टेक्स्ट ब्लॉक जिसमें कम से कम एक नाम और विवरण होना चाहिए) को पढ़ता है, और निर्णय लेता है कि क्या skill उसके लक्ष्यों से मेल खाती है। यदि frontmatter गायब है या गलत तरीके से बना है, तो skill agent के मेनू से गायब हो जाती है। एक ऐसी दुनिया में जहाँ स्वायत्त agent मीटिंग शेड्यूल करते हैं, सर्वर की समस्याओं को सुलझाते हैं, और बहुत कुछ करते हैं, एक खराब skill पूरे वर्कफ़्लो को बाधित कर सकती है।
What the numbers reveal
- 57.8% skills में कम से कम एक spec violation है।
- 29.2% में ऐसा नाम दिया गया है जो registry slug (URL identifier) से मेल नहीं खाता है।
- 18.1% में टूटे हुए package paths या डेड लिंक हैं।
- 7.8% (192 skills) में कोई YAML frontmatter ही नहीं है, जिससे वे बिना नाम और विवरण के रह जाते हैं।
- 3.8% में absolute file paths एम्बेड किए गए हैं जो केवल लेखक की मशीन पर मौजूद हैं।
- 2.4%
allowed-toolsफ़ील्ड का दुरुपयोग करते हैं, जिससे उन्हें agents द्वारा पढ़ना असंभव हो जाता है। - 2.1% environment variables के माध्यम से API keys को उजागर करते हैं, जो सुरक्षा के लिहाज से एक रेड फ्लैग है।
- 1.3% उन्हें घोषित किए बिना बाहरी command-line tools का उपयोग करते हैं, जो portability नियम का उल्लंघन है।
Portability सबसे अधिक बार सामने आती है। /home/USER/.local/bin/tool जैसा एक absolute path उस डेवलपर के लिए काम करता है जिसने skill लिखी है, लेकिन अन्य सभी उपयोगकर्ताओं के लिए विफल हो जाता है, जिससे runtime errors होते हैं जिन्हें static checks कभी नहीं पकड़ पाते।
A deeper dive: the openclaw case
ऑडिट में openclaw repository में बंडल की गई 46 skills की भी जांच की गई। गलत अलार्म को रोकने के लिए टेस्टिंग स्क्रिप्ट को रिफाइन करने के बाद, समीक्षक ने 59 वास्तविक दोष (genuine defects) खोज निकाले—यह एक अनुस्मारक है कि अत्यधिक आक्रामक linters उल्टा असर कर सकते हैं। जब कोई टूल बहुत अधिक हानिरहित मुद्दों को फ्लैग करता है, तो डेवलपर्स उसका उपयोग करना बंद कर देते हैं, और वास्तविक समस्याएं निकल जाती हैं।
openclaw के दो दोष उन फ़ाइलों की ओर इशारा करते हैं जो अब repository में मौजूद नहीं हैं। Maintainer ने एक फिक्स मर्ज किया जो गायब संदर्भों (references) को बहाल करता है, जो यह दर्शाता है कि कैसे एक सिंगल pull request एक टूटी हुई dependency chain को साफ कर सकती है।
Developer reactions
Auditor ने मूल skill repositories पर issues खोले। एक रिपोर्ट को खारिज कर दिया गया; maintainer ने तर्क दिया कि "broken" का निर्णय वास्तविक runtime व्यवहार से किया जाना चाहिए, न कि static file inspection से। Auditor इस बात से सहमत हुआ कि "brokenness" की एक सख्त परिभाषा को इस बात के अनुरूप होना चाहिए कि skill वास्तव में कैसे निष्पादित (execute) होती है। एक अन्य issue को स्वीकार कर लिया गया, और संबंधित फिक्स अब लाइव है।
Who stands to gain—or lose
- Agents और end-users तब अधिक सहज और अनुमानित व्यवहार का अनुभव करते हैं जब रजिस्ट्री में केवल अनुपालन करने वाली (compliant) और पोर्टेबल skills होती हैं।
- Skill authors को स्पष्ट validation rules मिलते हैं जो प्रकाशन से पहले गलतियों को पकड़ लेते हैं, जिससे issue triage के उतार-चढ़ाव कम हो जाते हैं।
- Registry operators को सख्त validation pipelines बनाने या एकीकृत करने होंगे; उनके बिना, इकोसिस्टम के भरोसे के कम होने का जोखिम है।
लापरवाह सत्यापन (Lax validation) "quick-and-dirty" सबमिशन को बढ़ावा देता है जो प्रोडक्शन में agents को खराब कर सकते हैं, जिससे संभावित रूप से महंगा downtime या सुरक्षा जोखिम पैदा हो सकते हैं।
Counter-point: are all violations fatal?
कुछ लोगों का तर्क है कि कुछ "त्रुटियां" हानिरहित हैं। एक गलत नाम उस agent को प्रभावित नहीं कर सकता है जो प्रदर्शित नाम के बजाय slug द्वारा skills का चयन करता है। स्थानीय विकास (local development) के लिए environment से API keys पढ़ना एक जानबूझकर किया गया डिज़ाइन विकल्प हो सकता है। हालाँकि, ऑडिट के प्रतिशत spec से किसी भी विचलन को उल्लंघन मानते हैं, जो कुछ मुद्दों के व्यावहारिक प्रभाव को बढ़ा-चढ़ाकर दिखा सकता है।
What to watch next
- बेहतर linters जो वास्तविक portability bugs को मामूली खामियों (benign quirks) से अलग करते हैं।
- Registry-side validation hooks जो आवश्यक frontmatter की कमी वाले या absolute paths वाले सबमिशन को खारिज कर देते हैं।
- Community-driven audits जो प्रोडक्शन agents तक पहुँचने से पहले छिपे हुए दोषों को सामने लाते हैं।
- संभावित spec revisions जो
allowed-toolsजैसे अस्पष्ट फ़ील्ड्स को स्पष्ट करते हैं और environment variables के स्वीकार्य उपयोग को परिभाषित करते हैं।
अगली पीढ़ी के टूल्स संभवतः इन जांचों को continuous-integration pipelines में शामिल करेंगे, जिससे compliance को एक मैन्युअल विचार के बजाय एक स्वचालित gate में बदल दिया जाएगा।
निष्कर्ष (Takeaway)
सार्वजनिक रूप से सूचीबद्ध अधिकांश AI-एजेंट स्किल्स बुनियादी अनुपालन (compliance) जांच में विफल हो जाते हैं, और एक महत्वपूर्ण हिस्सा तो बिल्कुल भी नहीं चुना जा सकता। ये निष्कर्ष सख्त वैलिडेशन (validation), बेहतर लिंटिंग टूल्स और एक ऐसी सामुदायिक संस्कृति की स्पष्ट आवश्यकता को रेखांकित करते हैं, जो प्रकाशन के लिए स्पेसिफिकेशन (spec) के पालन को एक अनिवार्य शर्त मानती हो। जब तक ये सुरक्षा उपाय लागू नहीं हो जाते, तब तक एजेंट कमजोर और नॉन-पोर्टेबल स्किल्स के कारण समस्याओं का सामना करते रहेंगे।