CODEZ / परिचय और डेटा पद्धति
CODEZ के बारे में: कौशल समावेशन, स्टार रैंकिंग और डेटा पद्धति।
CODEZ.WIN एक ट्रेस करने योग्य एजेंट स्किल डिस्कवरी डायरेक्टरी है जो आपको कार्य के आधार पर उम्मीदवारों को खोजने में मदद करती है और फिर विवरण, निर्भरता और लाइसेंस सत्यापित करने के लिए मूल रिपॉजिटरी पर वापस जाने की सुविधा देती है। यह पृष्ठ बताता है कि डायरेक्टरी में मौजूद संख्याएँ और टैग कैसे उत्पन्न होते हैं और वे क्या सिद्ध नहीं करते हैं।
विधि सत्यापन:
डायरेक्टरी स्नैपशॉट:
इस अनुभाग में इस साइट पर उपयोग किए जाने वाले वास्तविक डेटा संग्रह और प्रदर्शन नियमों का विवरण दिया गया है। तृतीय-पक्ष विवरण उनके मूल लेखकों के हैं; विधि स्पष्टीकरण और चयन सुझाव CODEZ द्वारा संकलित और संपादित किए गए हैं। इसमें शामिल होने का यह अर्थ नहीं है कि परियोजना का वास्तविक उपयोग परीक्षण, सुरक्षा ऑडिट या संगतता प्रमाणन किया गया है।
वर्तमान में कौन-कौन से स्रोत शामिल हैं?
वर्तमान स्नैपशॉट में 11 रिपॉजिटरी और 611 स्किल्स शामिल हैं; स्रोत सूची 11 रिपॉजिटरी के साथ कॉन्फ़िगर की गई है। इस चरण में 0 रिपॉजिटरी संग्रह त्रुटियाँ दर्ज की गईं, और 0 रिपॉजिटरी पुराने डेटा का उपयोग कर रही हैं।
नीचे दी गई तालिका में डेटा को स्रोत के क्रम में सूचीबद्ध किया गया है, न कि लोकप्रियता के क्रम में। "समाप्त के रूप में चिह्नित नहीं" का अर्थ केवल यह है कि रिपॉजिटरी स्तर पर कोई विफलता संकेत नहीं है; यह फ़ाइल-दर-फ़ाइल पूर्ण पठन की गारंटी नहीं देता है। जब केवल कुछ स्रोतों को रीफ़्रेश किया जाता है, तो अन्य रिपॉजिटरी में पुराना डेटा रह सकता है; इसलिए, संपूर्ण बैच के स्नैपशॉट समय को प्रत्येक स्रोत के संग्रह समय के रूप में नहीं लिया जा सकता है।
मूल स्रोत रिपॉज़िटरी और इस स्नैपशॉट का सार्वजनिक डेटा:
| स्रोत रिपॉज़िटरी | रिपॉज़िटरी Star | सूची में शामिल Skill | डेटा संग्रह की स्थिति |
|---|---|---|---|
| anthropics/skills | 183,533 | 20 | पुराना होने का चिह्न नहीं |
| openai/skills | 28,289 | 44 | पुराना होने का चिह्न नहीं |
| vercel-labs/agent-skills | 32,960 | 9 | पुराना होने का चिह्न नहीं |
| obra/superpowers | 304,663 | 15 | पुराना होने का चिह्न नहीं |
| microsoft/skills | 3,145 | 209 | पुराना होने का चिह्न नहीं |
| vercel-labs/open-agents | 5,862 | 13 | पुराना होने का चिह्न नहीं |
| anthropics/knowledge-work-plugins | 32,664 | 252 | पुराना होने का चिह्न नहीं |
| huggingface/skills | 11,209 | 26 | पुराना होने का चिह्न नहीं |
| cloudflare/skills | 3,166 | 19 | पुराना होने का चिह्न नहीं |
| supabase/agent-skills | 2,923 | 2 | पुराना होने का चिह्न नहीं |
| duixcom/duix-skills | 12 | 2 | पुराना होने का चिह्न नहीं |
कुछ कौशल निर्देशिका में क्यों नहीं दिखाई दे रहे हैं?
डेटा संग्रह केवल स्रोत सूची में मौजूद सार्वजनिक, गैर-अक्षम रिपॉजिटरी को स्कैन करता है, जिसमें डिफ़ॉल्ट शाखा के फ़ाइल ट्री का उपयोग किया जाता है; प्रति रिपॉजिटरी की वर्तमान सीमा 300 उम्मीदवार SKILL.md फ़ाइलें हैं। यदि सीमा पार हो जाती है या फ़ाइल ट्री छोटा हो जाता है, तो संपूर्ण रिपॉजिटरी संग्रह एक त्रुटि की सूचना देगा, और छोटा किया गया डेटा पूर्ण परिणाम के रूप में प्रकाशित नहीं किया जाएगा।
इन फ़ोल्डर अंशों वाले पथ फिलहाल बाहर हैं: /test/, /tests/, /fixtures/, /node_modules/, /examples/। फ़ाइल नाम SKILL.md पर समाप्त होना चाहिए और YAML frontmatter में name व description गैर-खाली स्ट्रिंग होने चाहिए। तृतीय-पक्ष स्क्रिप्ट नहीं चलाई जातीं।
यह इस साइट पर पार्स करने योग्य प्रविष्टियों के लिए निर्धारित सीमा है, न कि एजेंट स्किल्स विनिर्देश में उल्लिखित सभी आवश्यकताओं का सत्यापन। जिन फ़ाइलों को पढ़ा नहीं जा सकता, जिनमें आवश्यक मेटाडेटा की कमी है, या जिन्हें पार्स नहीं किया जा सकता, उन्हें छोड़ा जा सकता है; स्रोत सूची में शामिल न होने वाली वस्तुओं का स्वचालित रूप से पता नहीं लगाया जाएगा।
अलग-अलग Skill पर Star की संख्या समान क्यों है?
स्टार GitHub रिपॉजिटरी से संबंधित हैं। एक ही रिपॉजिटरी के भीतर कौशल उसी रिपॉजिटरी के स्टार दिखाते हैं; ये संख्याएँ किसी कौशल को पसंदीदा के रूप में चिह्नित किए जाने की संख्या को नहीं दर्शाती हैं, और न ही इन्हें विभिन्न कौशलों के लिए एक साथ जोड़ा जाना चाहिए। GitHub प्रशंसा और मान्यता व्यक्त करने के लिए स्टार का उपयोग करता है, इसलिए यह साइट इन्हें खोज के लिए एक संकेत के रूप में उपयोग करती है।
होमपेज रिपॉज़िटरी को Star की घटती संख्या में रखता है; बराबर होने पर रिपॉज़िटरी ID से क्रम तय होता है। पूरी Skill सूची में पहले संबंधित रिपॉज़िटरी के Star, फिर Skill नाम और ID का स्थिर क्रम है। कार्ड क्रमांक सूची में स्थान है, प्रभाव का स्कोर नहीं। होमपेज पर नाम जैसे अन्य क्रम चुने जा सकते हैं।
| फ़ील्ड | वास्तविक अर्थ | इसका उपयोग निर्णय लेने के लिए नहीं किया जा सकता है। |
|---|---|---|
| रिपॉज़िटरी Star | डेटा संग्रह के दौरान GitHub द्वारा लौटाई गई रिपॉजिटरी की लोकप्रियता | किसी एक कौशल की सफलता दर या सुरक्षा |
| शामिल कौशलों की संख्या | इस स्नैपशॉट में पार्स की जा सकने वाली और रखी जा सकने वाली प्रविष्टियों की संख्या | रिपॉज़िटरी की सभी क्षमताएँ, गुणवत्ता या अनुकूलता |
| रिपॉज़िटरी अपडेट की तारीख | GitHub रिपॉजिटरी का अंतिम पुश समय | आप जिस स्किल का उपयोग कर रहे हैं, उसमें हाल ही में कौन-कौन से सुधार किए गए हैं? |
क्या यह वर्गीकरण लेखक द्वारा घोषित किया गया है या इस साइट द्वारा निर्धारित किया गया है?
यह वर्गीकरण इस साइट के सिंगल-टैग नियम के आधार पर किया गया है। सबसे पहले, मैन्युअल ओवरराइडिंग का उपयोग किया जाता है, फिर नाम और पथ में क्लाउड सेवा और एजेंट वर्कफ़्लो नियमों की जाँच की जाती है; शेष प्रविष्टियों का निर्धारण नाम, विवरण और कौशल पथ में कीवर्ड मिलान की संख्या के आधार पर किया जाता है। जो प्रविष्टियाँ मेल नहीं खातीं, उन्हें "अन्य" के रूप में वर्गीकृत किया जाता है। यदि मिलान की संख्या समान है, तो नियम क्रम का पालन किया जाता है।
एक कौशल में विकास, डेटा, अनुसंधान और अन्य कार्य शामिल हो सकते हैं। निर्देशिका में केवल एक मुख्य श्रेणी दी गई है, जिससे गलत वर्गीकरण हो सकता है। कोई श्रेणी किसी विशेष क्लाइंट के साथ उसकी अनुकूलता साबित नहीं करती; फ़िल्टर करने के बाद, आपको SKILL.md, README और निर्भरता विवरण पढ़ना चाहिए। समस्या निवारण के लिए, आपको विशिष्ट रिपॉजिटरी, SKILL.md फ़ाइल का पथ और उस श्रेणी के लिए सहायक दस्तावेज़ की आवश्यकता होगी।
यह तालिका साइट की विशिष्ट फ़ाइलों की मैन्युअल वर्गीकरण समीक्षा दिखाती है। पुरानी श्रेणी समीक्षा के समय की सार्वजनिक सूची से है। निर्णय लिंक किए गए निश्चित commit के मूल पाठ पर आधारित है। केवल सूची की श्रेणी बदली गई; तृतीय-पक्ष Skill चलाई नहीं गईं और सभी क्लाइंट पर प्रभाव साबित नहीं होता।
| Skill | समीक्षा से पहले वर्गीकरण | वर्तमान श्रेणी | निर्णय का आधार | डेटा सत्यापन |
|---|---|---|---|---|
| obra/superpowers / brainstorming | डिज़ाइन | एजेंट वर्कफ़्लो | कार्यान्वयन से पहले उद्देश्य, आवश्यकताएँ और डिज़ाइन की पुष्टि के लिए सहयोग व्यवस्थित करता है। मुख्य परिणाम संयुक्त निर्णय और विनिर्देश हैं। | 2026-10-07 |
| obra/superpowers / verification-before-completion | अन्य | एजेंट वर्कफ़्लो | सत्यापन कमांड चुनना और पूरा आउटपुट पढ़ने के बाद ही पूर्णता का दावा करना आवश्यक है। केंद्र में Agent के काम की स्वीकृति और डिलीवरी प्रक्रिया है। | 2026-10-07 |
| obra/superpowers / writing-skills | दस्तावेज़ | एजेंट वर्कफ़्लो | इस प्रक्रिया का मूल आधार तनावपूर्ण परिस्थितियों में एजेंट के व्यवहार की जांच करने के लिए कौशल का निर्माण, संपादन और उपयोग करना है, और यह एजेंट की क्षमताओं को लिखने और मान्य करने की प्रक्रिया है। | 2026-10-07 |
| anthropics/skills / pdf | डिज़ाइन | दस्तावेज़ | निर्देश PDF निकालने, मर्ज करने, बाँटने, बनाने और स्कैन पर OCR के बारे में हैं। मुख्य इनपुट-आउटपुट दस्तावेज़ हैं; Python उदाहरण कार्य करने का साधन हैं। | 2026-10-08 |
| openai/skills / pdf | विकास | दस्तावेज़ | पीडीएफ पढ़ने, बनाने और डिलीवरी से पहले उसकी रेंडरिंग जांच से संबंधित मुख्य परिणाम दस्तावेज़ और उसके लेआउट का सत्यापन है, न कि सॉफ्टवेयर विकास कार्य। | 2026-10-08 |
| vercel-labs/open-agents / frontend-design | एजेंट वर्कफ़्लो | डिज़ाइन | टाइपोग्राफ़ी, रंग, लेआउट और एनीमेशन के माध्यम से फ्रंटएंड इंटरफ़ेस के कार्यान्वयन का मार्गदर्शन करता है; मुख्य परिणाम इंटरफ़ेस डिज़ाइन और कोड हैं। | 2026-10-11 |
| cloudflare/skills / cf-cli | विकास | क्लाउड सेवाएं | Cloudflare API संचालन, Workers डिप्लॉयमेंट और DNS, D1, KV तथा R2 संसाधनों के प्रबंधन पर केंद्रित है; मुख्य कार्य क्लाउड सेवाओं का संचालन है, और मूल फ़ाइल CLI को beta चरण में बताती है। | 2026-10-13 |
| cloudflare/skills / gateway-workers | विकास | क्लाउड सेवाएं | यह Cloudflare Gateway की HTTP नीतियों में Forward कार्रवाई, Workers और GatewayMiddleware प्रवेश बिंदु पर केंद्रित है; इसका मुख्य दायरा क्लाउड सेवाएँ हैं। केवल मूल पाठ की समीक्षा की गई; इस Skill को चलाया नहीं गया। | 2026-10-19 |
CODEZ: कार्य चरण के अनुसार वर्कफ़्लो कौशल का चयन करें ↗
CODEZ: दो PDF स्किल्स के वास्तविक स्रोतों की तुलना और स्वीकृति जांच ↗
obra/superpowers / skills/brainstorming/SKILL.md ↗
obra/superpowers / skills/verification-before-completion/SKILL.md ↗
obra/superpowers / skills/writing-skills/SKILL.md ↗
anthropics/skills / skills/pdf/SKILL.md ↗
openai/skills / skills/.curated/pdf/SKILL.md ↗
vercel-labs/open-agents / .agents/skills/frontend-design/SKILL.md ↗
क्या सभी सार्वजनिक रिपॉजिटरी को सीधे आपके अपने प्रोजेक्ट में उपयोग किया जा सकता है?
GitHub पर किसी रिपॉज़िटरी का सार्वजनिक रूप से दिखाई देना और उसकी लाइसेंस जानकारी अलग बातें हैं। CODEZ लाइसेंस से जुड़ी अनिश्चितता को स्पष्ट रखता है और प्रोजेक्ट के नाम, README में प्रचार संबंधी वाक्यों या डाउनलोड की उपलब्धता से उपयोग की अनुमति का अनुमान नहीं लगाता।
| लेबल | साइट का आधार | उपयोग करने से पहले जांच लें |
|---|---|---|
| SPDX पहचानकर्ता जैसे MIT / Apache-2.0 | Skill के पास या ऊपरी फ़ोल्डर में अधिक नज़दीकी स्वतंत्र लाइसेंस न मिले तो GitHub द्वारा पहचाना रिपॉज़िटरी लाइसेंस इस्तेमाल होता है | मूल लाइसेंस पाठ, लागू दायरा और अतिरिक्त सामग्री का लाइसेंस |
| लाइसेंस दस्तावेजों का सत्यापन लंबित है | स्किल डायरेक्टरी या उसकी पैरेंट डायरेक्टरी में एक अलग लाइसेंस फाइल मिली, या रूट डायरेक्टरी लाइसेंस को पहचाना नहीं गया। | संबंधित फ़ाइल बॉडी; यह स्वचालित रूप से रिपॉजिटरी रूट लाइसेंस का उपयोग नहीं करता है। |
| निर्दिष्ट नहीं है | लाइसेंसिंग का कोई पहचान योग्य आधार नहीं मिला। | मूल प्रोजेक्ट से उपयोग की अनुमति जाँचें; पढ़ सकना लाइसेंस मिलना नहीं है |
चीनी और अंग्रेजी में दिए गए निर्देश कहाँ से आते हैं?
इंटरफ़ेस और साइट के अपने विवरण तेरह भाषाओं में बनाए रखे जाते हैं। तीसरे पक्ष के सारांश अभी SKILL.md के साथ वाले फ़ोल्डर में चीनी और अंग्रेज़ी README पहचानते हैं। स्पष्ट भाषा नाम वाली फ़ाइल को प्राथमिकता मिलती है; सामान्य README.md की भाषा उसके पाठ से पहचानी जाती है। चीनी और अंग्रेज़ी इंटरफ़ेस में संबंधित भाषा का छोटा मूल सारांश प्राथमिक होता है। अन्य इंटरफ़ेस SKILL.md का मूल विवरण रखते हैं। उपलब्ध चीनी और अंग्रेज़ी README के मूल लिंक बने रहते हैं।
भाषा न मिले या सारांश न निकले तो SKILL.md का मूल description फ़ील्ड इस्तेमाल होता है। पूरी रिपॉज़िटरी का README किसी एक Skill का परिचय नहीं माना जाता और स्वचालित अनुवाद को लेखक का मूल पाठ नहीं बताया जाता। इसलिए अंग्रेज़ी इंटरफ़ेस में चीनी मूल पाठ या उसका उलटा दिख सकता है।
यदि डेटा संग्रह विफल हो जाता है, तो क्या पुराने डेटा को आज के डेटा के रूप में माना जाएगा?
सर्वर प्रतिदिन बीजिंग समयानुसार सुबह 10:37 बजे डेटा संग्रह शुरू करता है और पूरा होने पर MySQL से स्थिर पृष्ठ उत्पन्न करता है। स्नैपशॉट समय उस समय को दर्शाता है जब डेटा का यह बैच उत्पन्न हुआ था; इसे सभी स्रोतों से एक ही समय पर नहीं पढ़ा जाता है, न ही यह प्रत्येक प्रोजेक्ट का संशोधन समय है।
जब रिपॉजिटरी-स्तर का अनुरोध विफल हो जाता है, तो उस रिपॉजिटरी के अंतिम सफल अनुरोध का डेटा पुनः उपयोग किया जाता है, और लीडरबोर्ड और यह पृष्ठ "पुराने डेटा का उपयोग" के रूप में चिह्नित हो जाएगा। यदि सभी स्रोत विफल हो जाते हैं, तो मूल स्नैपशॉट को सुरक्षित रखा जाता है और एक त्रुटि की सूचना दी जाती है। रिपॉजिटरी-स्तर की त्रुटियाँ मूल डायरेक्टरी JSON में सुरक्षित रखी जाती हैं। एकल फ़ाइल पढ़ने की विफलताओं को केवल छोड़ा जा सकता है और संग्रह लॉग में लिखा जा सकता है, और संपूर्ण रिपॉजिटरी को स्वचालित रूप से समाप्त के रूप में चिह्नित नहीं किया जाएगा। इसलिए, "इस दौर में सफल" में अभी भी कवरेज की सीमाएँ हैं।
मूल फ़ाइल लिंक डेटा संग्रह के दौरान उपयोग की गई डिफ़ॉल्ट शाखा को इंगित करता है; मूल प्रोजेक्ट तब से बदल गया हो सकता है। समस्या को दोबारा उत्पन्न करते समय, आपको GitHub पर विशिष्ट कमिट और फ़ाइल पथ रिकॉर्ड करने चाहिए, न कि केवल इस साइट पर संख्याएँ सहेजनी चाहिए।
इस जानकारी का उपयोग वास्तविक निर्णय लेने के लिए कैसे किया जा सकता है?
सबसे पहले, कार्य और इनपुट/आउटपुट के आधार पर उम्मीदवारों को छाँटें, फिर वातावरण, कार्यक्षेत्र और अनुमतियों की जाँच करें; अंत में, समान इनपुट के साथ एक छोटा परीक्षण करें और परिणामों को रिकॉर्ड करें। रिपॉजिटरी स्टार रेटिंग, डायरेक्टरी श्रेणियां और लेखक विवरण उम्मीदवारों को खोजने में मदद कर सकते हैं, लेकिन वे आपके लिए परीक्षण नहीं करेंगे।
इस वेबसाइट पर मौजूद चयन मार्गदर्शिका में पुन: उपयोग योग्य सत्यापन विधियाँ और उदाहरण दिए गए हैं। ये उदाहरण किसी विशिष्ट परियोजना के वास्तविक परीक्षण परिणाम नहीं हैं; आगे के परियोजना विश्लेषणों में सार्वजनिक रूप से उपलब्ध डेटा और वास्तविक परीक्षण के बीच अंतर स्पष्ट किया जाएगा।