स्किल माइनिंग: 3,500 उम्मीदवारों से 466 क्षमताओं तक

इस पोस्ट में दिए गए आंकड़े प्रकाशन के समय (जनवरी 2026) की सिस्टम स्थिति दर्शाते हैं। मौजूदा आंकड़ों के लिए हमारा टीम पेज देखें।

3,500 स्किल की समस्या

जब हमने एक एजेंट ऑर्केस्ट्रेशन सिस्टम बनाना शुरू किया, तो हमें एक दिलचस्प चुनौती का सामना करना पड़ा: AI इकोसिस्टम में हज़ारों संभावित स्किल बिखरी हुई हैं। GitHub रिपॉज़िटरी, वेंडर डॉक्यूमेंटेशन, कम्युनिटी प्रोजेक्ट, आंतरिक पैटर्न — स्किल हर जगह मौजूद हैं। लेकिन कौन-सी मायने रखती हैं? कौन-सी काम करती हैं? और आप एक सुसंगत स्किल लाइब्रेरी कैसे बनाए रखते हैं जिसे एजेंट वास्तव में इस्तेमाल कर सकें?

हमारा जवाब: एक व्यवस्थित माइनिंग और इंजेशन लूप।

आज के आंकड़े

Anthropic द्वारा 16 अक्टूबर, 2025 को Agent Skills लॉन्च करने के लगभग तीन महीने बाद, जब यह पोस्ट 27 जनवरी, 2026 को प्रकाशित हुई, तब हमारी स्थिति यह थी:

मेट्रिक	संख्या
पहचाने गए उम्मीदवार	3,500+
अपनाई गई स्किल	466
वेंडर स्किल	373
आंतरिक स्किल	93
सक्रिय वेंडर	25+
प्रति स्किल औसत टोकन	2,834
संदर्भित टूल	89
यूनीक टैग	635

हमने 3,500 से ज़्यादा स्किल उम्मीदवारों की समीक्षा की है। हमने 466 अपनाई हैं। यह 13% अपनाने की दर है — और यह चयनात्मकता जानबूझकर है।

नॉलेज टियर सिस्टम

सभी स्किल एक जैसी नहीं बनाई जातीं। हम उन्हें पांच नॉलेज लेयर (K0-K4) में व्यवस्थित करते हैं, हर एक लागू होने के अलग दायरे का प्रतिनिधित्व करती है:

K0: Foundations (सार्वभौमिक)

ऐसी स्किल जो हर एजेंट के पास होनी चाहिए। ये “अच्छे विचारक” की क्षमताओं का प्रतिनिधित्व करती हैं जो कहीं भी काम करती हैं।

foundations/
├── test-first-discipline       # TDD: Red-Green-Refactor
├── evidence-based-completion   # Verify before claiming done
├── systematic-debugging        # Root cause methodology
├── structured-planning         # Break work into tasks
└── context-budget-awareness    # Manage token consumption

K0 स्किल किसी भी प्रोजेक्ट, किसी भी डोमेन, किसी भी स्टैक में पोर्टेबल हैं। ये सार्वभौमिक संज्ञानात्मक पैटर्न को एनकोड करती हैं।

K1: Identities (अनुशासन)

“अच्छे इंजीनियर” या “अच्छे रिसर्चर” वाली स्किल जो किसी अनुशासन के भीतर प्रोजेक्ट में लागू होती हैं।

identities/
├── research-workflows          # Multi-source research
├── web-extraction-playbook     # Content extraction
├── code-review                 # PR review patterns
└── cli-interface-standards     # CLI design patterns

K2: Domains (विषय विशेषज्ञता)

“अच्छा डेटाबेस विशेषज्ञ” या “अच्छा सिक्योरिटी इंजीनियर” वाली स्किल जो किसी क्षेत्र के भीतर पोर्टेबल हैं।

domains/
├── schema-migration-workflow   # Safe migration patterns
├── rpc-validation-checklist    # RPC health checks
├── auth-validation-checklist   # JWT/OAuth patterns
└── secrets-audit-checklist     # Credential scanning

K3: Stacks (टेक्नोलॉजी)

विशिष्ट टेक्नोलॉजी स्टैक के लिए “अच्छा Supabase उपयोगकर्ता” या “अच्छा Cloudflare डेवलपर” वाली स्किल।

stacks/
├── maguyva-quickstart          # Our semantic search patterns
├── cloudflare-deployment       # Workers/Pages deployment
└── mcp-tool-best-practices     # MCP tool selection

K4: Project (संगठन)

हमारे संगठन और वर्कफ़्लो के लिए विशिष्ट स्किल।

project/
├── agent-creation-workflow     # How we build agents
├── skill-authoring-workflow    # How we write skills
├── mining-session-workflow     # This very process
└── vendor-skill-evaluation     # Evaluation rubrics

माइनिंग लूप

चरण 1: डिस्कवरी

स्किल हर जगह से आती हैं:

वेंडर रिपॉज़िटरी: AWS, Anthropic, Cloudflare, Supabase, और कम्युनिटी कंट्रीब्यूटर स्किल कलेक्शन प्रकाशित करते हैं। हम 25+ वेंडर रूट ट्रैक करते हैं।

कम्युनिटी प्रोजेक्ट: GitHub Claude Code टेम्पलेट, एजेंट पैटर्न, और वर्कफ़्लो परिभाषाओं से भरा है।

आंतरिक पैटर्न: जैसे-जैसे हमारी टीम समस्याएं सुलझाती है, पैटर्न उभरते हैं। इन्हें स्किल में औपचारिक रूप दिया जाता है।

डॉक्यूमेंटेशन माइनिंग: तकनीकी डॉक्यूमेंटेशन में अक्सर अंतर्निहित स्किल होती हैं — प्रक्रियाएं, चेकलिस्ट, डिसीज़न ट्री।

डिस्कवरी निरंतर चलती रहती है। हम औपचारिक मूल्यांकन से पहले उम्मीदवारों को ट्रैक करने के लिए एक स्किल बैकलॉग का उपयोग करते हैं।

चरण 2: मूल्यांकन

हर उम्मीदवार एक ही रूब्रिक से गुज़रता है:

adoption_criteria:
  - fills_real_gap: true # We lack this capability
  - well_structured: true # Progressive disclosure
  - actively_maintained: true # Commits in last 6 months
  - portable: true # Not hyper-specific
  - tested: true # Evidence of usage

सभी पांच प्रोडक्ट मानदंडों को पास करना ज़रूरी है। यही वजह है कि 87% उम्मीदवार रिजेक्ट कर दिए जाते हैं।

फिर हर उम्मीदवार एक अलग ट्रस्ट रिव्यू से गुज़रता है। हम किसी आधिकारिक वेंडर रिपॉज़िटरी, किसी जाने-माने कम्युनिटी मेंटेनर, और किसी रैंडम GitHub रिपॉज़िटरी को सच्चाई के समकक्ष स्रोत नहीं मानते।

trust_review:
  vendor_credibility:
    - ownership_verified # Official vendor, known maintainer, or internal source
    - maintenance_signal # Recent commits, issue response, release history
    - adoption_signal # Evidence of real use, stars alone are not enough
    - provenance_clear # We can trace where the skill came from
  prompt_injection_scan:
    - hidden_instruction_check # Buried "ignore previous instructions" patterns
    - exfiltration_check # Prompts that try to leak files, secrets, or context
    - authority_check # Claims of priority over system or developer rules
  script_audit:
    - inspect_scripts # Read shell/python/js helpers before adoption
    - network_and_exec_review # curl|bash, remote downloads, subprocess execution
    - file_and_secret_review # Env vars, credential access, broad file writes
    - destructive_action_check # rm, reset, overwrite, or unsafe automation

भरोसेमंद वेंडर को हल्की उत्पत्ति समीक्षा मिलती है, लेकिन कोई मुफ़्त पास नहीं। अविश्वसनीय या अज्ञात स्रोतों को गहरा मैनुअल ऑडिट मिलता है, और हम बंडल की गई स्क्रिप्ट तब तक एक्ज़िक्यूट नहीं करते जब तक उन्हें पढ़ा, स्कोप किया, और सुरक्षित के रूप में वर्गीकृत नहीं किया जाता।

गैप विश्लेषण: अपनाने से पहले, हम अपनी रजिस्ट्री सर्च करते हैं:

uv run orkestra skills search "<capability>"

अगर हमारे पास पहले से है, तो हमें इसकी ज़रूरत नहीं। अगर हमारे पास कुछ मिलता-जुलता है, तो हम शायद अपनाने के बजाय मर्ज करें।

डेप्थ और स्टैंडर्ड्स स्कोरिंग: हम यह भी स्कोर करते हैं कि कोई उम्मीदवार agent-skill मॉडल का कितनी पूरी तरह उपयोग करता है। एक अकेला SKILL.md अब भी उपयोगी हो सकता है, लेकिन गहरी स्किल तब ज़्यादा मूल्यवान होती हैं जब वे निर्देशों को रेफ़रेंस, स्क्रिप्ट, और एसेट से उसी तरह अलग करती हैं जैसा agentskills.io प्रोत्साहित करता है।

skill_depth:
  - level_1: SKILL.md only # Single instruction file
  - level_2: SKILL.md + strong description # Clear triggers and scope
  - level_3: adds references/ # Load docs only when needed
  - level_4: adds atomic scripts/ # Small, reviewable helpers
  - level_5: adds assets/examples/templates # Full progressive disclosure
depth_signals:
  - standards_adherence # Structure aligns with agentskills.io conventions
  - reference_quality # Curated references, not giant context dumps
  - script_atomicity # Focused helpers, not opaque monoliths
  - tool_boundary_clarity # Clear limits on what the skill can execute
  - community_signal # Stars/forks/users help, but only as a weak boost

GitHub स्टार क्रेडिबिलिटी स्कोर को थोड़ा ऊपर उठा सकते हैं, लेकिन वे किसी उथली या असुरक्षित स्किल को कभी नहीं बचाते। एक अस्पष्ट SKILL.md और अपारदर्शी स्क्रिप्ट वाला हाई-स्टार रिपॉज़िटरी, एक सटीक विवरण, क्यूरेटेड references/, और ऐसे एटॉमिक हेल्पर वाले छोटे रिपॉज़िटरी से नीचे स्कोर करता है जो वास्तव में पूरी स्किल क्षमता का लाभ उठाते हैं।

संरचनात्मक विश्लेषण: हम स्किल क्वालिटी जांचते हैं:

wc -l vendor/<repo>/<skill>/SKILL.md  # Size check
ls vendor/<repo>/<skill>/scripts/     # Supporting files
ls vendor/<repo>/<skill>/references/  # Bundled docs

अगर किसी उम्मीदवार में स्क्रिप्ट शामिल हैं, तो वह समीक्षा और सख़्त हो जाती है। एक अच्छी स्किल सिर्फ़ उपयोगी नहीं होती; उसे पठनीय, सीमित, और किसी एजेंट को सौंपने के लिए सुरक्षित भी होना पड़ता है। अकेला यह सेफ़्टी फ़िल्टर अन्यथा दिलचस्प लगने वाले उम्मीदवारों के एक सार्थक हिस्से को अयोग्य ठहरा देता है।

चरण 3: इंजेशन

जब कोई स्किल मूल्यांकन पास कर लेती है, तो वह रजिस्ट्री में प्रवेश करती है। लेकिन स्किल कभी बिना बदले नहीं अपनाई जातीं। इन्हें हमारे सिस्टम में फ़िट करने के लिए संशोधित किया जाता है।

अपनाने पर संशोधन:

1. मेटाडेटा नॉर्मलाइज़ेशन: हर स्किल को हमारा फ़्रंटमैटर स्कीमा मिलता है
2. K-स्तर असाइनमेंट: स्किल को उपयुक्त नॉलेज लेयर में रखा जाता है
3. टैग एनरिचमेंट: डिस्कवरी के लिए टैग जोड़े जाते हैं
4. टूल डिक्लेरेशन: अनुमत टूल स्पष्ट रूप से घोषित किए जाते हैं
5. सेक्शन अलाइनमेंट: कॉन्टेंट को हमारे टेम्पलेट से मेल खाने के लिए पुनर्गठित किया जाता है

इंजेशन के बाद एक सामान्य स्किल YAML:

metadata:
  identifier: vendor-skill-evaluation
  name: vendor-skill-evaluation
  description: Systematic evaluation of vendor skills for adoption.
  type: workflow
  layer: K4
  semantic_folder: project
  source: core
  last_updated: "2026-01-17"

frontmatter:
  tags:
    - agents
    - meta
    - skill-adoption
    - vendor
  allowed_tools:
    - Bash
    - Read
    - Write
    - Edit
    - Grep
    - Glob
    - Task

चरण 4: स्कोप असाइनमेंट

स्किल को स्कोप सौंपे जाते हैं — ऐसी श्रेणियां जो तय करती हैं कि कौन-सा एजेंट कौन-सी स्किल लोड करता है:

scopes:
  database:
    primary_skills:
      - domains/schema-migration-workflow
      - domains/rpc-validation-checklist
      - vendor/supabase/supabase-database
      - vendor/supabase/supabase-auth

  research:
    primary_skills:
      - identities/research-workflows
      - identities/web-extraction-playbook
      - identities/dataset-discovery-quickstart

एजेंट अपने स्कोप घोषित करते हैं, और स्किल अपने-आप असाइन हो जाती हैं:

# Agent definition
scopes: [database, research]
# Gets: all database skills + all research skills + universal skills

चरण 5: मैटीरियलाइज़ेशन

प्रोडक्शन में स्किल YAML के रूप में नहीं रहतीं। इन्हें SKILL.md फ़ाइलों में रेंडर किया जाता है जिन्हें Claude Code लोड कर सकता है:

uv run orkestra sync

यह कमांड:

1. सभी स्किल YAML परिभाषाएं पढ़ता है
2. उन्हें Jinja टेम्पलेट के ज़रिए रेंडर करता है
3. SKILL.md फ़ाइलें .claude/skills/ में लिखता है
4. K-स्तर के हिसाब से व्यवस्थित करता है (foundations/, identities/, domains/, stacks/, project/)

अंतिम आउटपुट संरचना:

.claude/skills/
├── foundations/     # K0: Universal
├── identities/      # K1: Discipline
├── domains/         # K2: Subject
├── stacks/          # K3: Technology
├── project/         # K4: Organization
└── vendor/          # External skills

डॉरमेंट स्कोप पैटर्न

हमारे सबसे शक्तिशाली पैटर्न में से एक “अपनाई-गई-लेकिन-लोड-नहीं-हुई” स्किल है। हम इन्हें डॉरमेंट स्कोप कहते हैं।

k-dense-scientific रिपॉज़िटरी की साइंटिफ़िक कंप्यूटिंग स्किल पर विचार करें। हमने बायोइन्फ़ॉर्मेटिक्स, केमिस्ट्री, क्वांटम कंप्यूटिंग, और क्लिनिकल इन्फ़ॉर्मेटिक्स को कवर करने वाली 120+ स्किल अपनाई हैं। लेकिन हमारे ज़्यादातर एजेंट को मॉलिक्यूलर डॉकिंग या जीन एक्सप्रेशन विश्लेषण की ज़रूरत नहीं होती।

हर एजेंट में सभी 120 स्किल लोड करने (कॉन्टेक्स्ट विंडो को फुलाने) के बजाय, हम:

1. स्किल को एक विशिष्ट स्कोप के साथ अपनाते हैं (जैसे, bioinformatics)
2. उन्हें डॉरमेंट रखते हैं — रजिस्टर्ड लेकिन लोड नहीं
3. उन्हें तभी एनेबल करते हैं जब कोई एजेंट वह स्कोप घोषित करता है

# In scopes.yaml - dormant scope
bioinformatics:
  description: "Bioinformatics and genomics"
  primary_skills: [] # Empty - skills exist but aren't loaded

# When an agent needs bioinformatics:
# Agent YAML
scopes: [research, bioinformatics] # Now loads bioinformatics skills

यह पैटर्न हमें रजिस्ट्री में 466 स्किल रखने देता है, जबकि सामान्य एजेंट सिर्फ़ 40-60 प्रासंगिक स्किल लोड करते हैं।

स्किल के प्रकार

स्किल तीन संज्ञानात्मक पैटर्न में आती हैं:

Workflow

क्रमबद्ध प्रक्रियात्मक चरण: “1. X करो, 2. फिर Y, 3. आख़िर में Z”

type: workflow
# Examples: schema-migration-workflow, mining-session-workflow

Discipline

व्यवहार संबंधी गार्डरेल: “हमेशा X”, “कभी Y नहीं”, “Z को प्राथमिकता दो”

type: discipline
# Examples: test-first-discipline, evidence-based-completion

Checklist

वैरिफ़िकेशन मानदंड: “X कन्फ़र्म करो”, “Y वेरिफ़ाई करो”, “Z चेक करो”

type: checklist
# Examples: auth-validation-checklist, secrets-audit-checklist

क्वालिटी गेट

हर स्किल को शिप होने से पहले वैलिडेशन पास करना ज़रूरी है:

validation:
  file_exists: true # Skill file at declared path
  frontmatter_valid: true # Frontmatter parses correctly
  sections_complete: true # Expected sections present
  tools_registered: true # Declared tools exist in registry

विवरण 50-400 अक्षरों के होने चाहिए, ट्रिगर वाक्यांशों (“Use when…”, “When you need…”) के साथ, ताकि Claude Code को पता हो कि उन्हें कब सुझाना है।

हम लगातार वैलिडेट करते हैं:

uv run orkestra validate --show-warnings

वेंडर इकोसिस्टम

हमारी 373 वेंडर स्किल यहां से आती हैं:

प्रदाता	स्किल	डोमेन
AWS Agent	19	क्लाउड सर्विसेज़
Anthropic	12	डॉक्यूमेंट जनरेशन
Cloudflare	8	एज कंप्यूटिंग
Supabase	5	डेटाबेस
k-dense	100+	साइंटिफ़िक कंप्यूटिंग
silvainfm	4	डेटा साइंस
Java Developer Kit	45+	Spring/Java
Vercel	1	ब्राउज़र ऑटोमेशन

हर वेंडर रूट metadata.yaml में घोषित है:

vendor_roots:
  - path: vendor/aws-agent-skills
    provider: aws
  - path: vendor/k-dense-scientific/scientific-skills
    provider: k-dense
  - path: vendor/supabase-skills
    provider: supabase

जब orkestra sync चलता है, तो वेंडर स्किल को उनके प्रोवाइडर नेमस्पेस के साथ .claude/skills/vendor/ में सिमलिंक कर दिया जाता है।

हमने क्या सीखा

चयनात्मकता फल देती है। हर उपयोगी दिखने वाली चीज़ अपनाने का लालच होता है। लेकिन हर स्किल टोकन ख़र्च करती है। प्रति स्किल औसतन 2,834 टोकन के साथ, ब्लोट तेज़ी से नुक़सान पहुंचाता है। हमारी 13% अपनाने की दर एजेंट को हल्का रखती है।

संरचना डिस्कवरी को सक्षम बनाती है। K-स्तर सिस्टम सिर्फ़ व्यवस्था नहीं है — यह पोर्टेबिलिटी के बारे में है। K0 स्किल कहीं भी दोबारा इस्तेमाल की जा सकती हैं। K4 स्किल जानबूझकर प्रोजेक्ट-विशिष्ट हैं। यह स्पष्टता इंसानों और एजेंट, दोनों को वह खोजने में मदद करती है जिसकी उन्हें ज़रूरत है।

डॉरमेंट स्कोप स्केल करते हैं। आप सैकड़ों स्किल अपना सकते हैं बिना उन सभी को लोड किए। स्कोप आपको एक व्यापक रजिस्ट्री बनाने देते हैं जबकि हर एजेंट के कॉन्टेक्स्ट विंडो को प्रबंधनीय रखते हैं।

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

माइनिंग निरंतर है। 3,500 का आंकड़ा बढ़ता ही रहता है। नए वेंडर रिपॉज़िटरी सामने आते हैं। कम्युनिटी पैटर्न उभरते हैं। आंतरिक वर्कफ़्लो मज़बूत होते हैं। लूप कभी नहीं रुकता।

आगे क्या है

हम कई सुधारों पर काम कर रहे हैं:

1. ऑटोमेटेड गैप डिटेक्शन: जब कोई सामान्य एजेंट विफलता किसी बिना-अपनाई स्किल से हल हो सकती हो, तो अलर्ट करना
2. स्किल डेप्रीकेशन वर्कफ़्लो: उन स्किल को रिटायर करने की औपचारिक प्रक्रिया जो पुरानी पड़ चुकी हैं या इस्तेमाल में नहीं हैं
3. क्रॉस-स्किल डिपेंडेंसी: स्किल की पूर्वापेक्षाओं की स्पष्ट घोषणा
4. उपयोग एनालिटिक्स: ट्रैक करना कि एजेंट वास्तव में कौन-सी स्किल इनवोक करते हैं बनाम सिर्फ़ लोड करते हैं

स्किल माइनिंग लूप इन्फ़्रास्ट्रक्चर है। यह चमकदार नहीं है। लेकिन यही वह चीज़ है जो 41 एजेंट को कॉन्टेक्स्ट सीमाओं के भीतर रहते हुए 466 क्षमताओं के साथ सुसंगत रूप से काम करने देती है।

यही कहानी है कि 3,500 कैसे 466 बन जाते हैं। 3,000 को नज़रअंदाज़ करके नहीं — उन्हें व्यवस्थित रूप से परखकर और सिर्फ़ वही अपनाकर जो काम करता है।

---

स्किल सिस्टम को काम करते देखना चाहते हैं? हमारी मौजूदा रजिस्ट्री एक्सप्लोर करने के लिए uv run orkestra skills list देखें।