Skill Mining: Dari 3.500 Kandidat Menjadi 466 Kapabilitas

Angka dalam tulisan ini mencerminkan sistem pada saat publikasi (Januari 2026). Lihat halaman tim kami untuk angka terkini.

Masalah 3.500 Skill

Ketika kami mulai membangun sistem orkestrasi agen, kami menghadapi tantangan yang menarik: ada ribuan calon skill yang bertebaran di seluruh ekosistem AI. Repositori GitHub, dokumentasi vendor, proyek komunitas, pola internal — skill ada di mana-mana. Tetapi yang mana yang penting? Yang mana yang benar-benar berhasil? Dan bagaimana Anda memelihara sebuah pustaka skill yang koheren yang benar-benar bisa digunakan agen?

Jawaban kami: sebuah loop mining dan ingestion yang sistematis.

Angka-angka Hari Ini

Hanya sedikit lebih dari tiga bulan setelah Anthropic meluncurkan Agent Skills pada 16 Oktober 2025, inilah posisi kami saat tulisan ini dipublikasikan pada 27 Januari 2026:

Metrik	Jumlah
Kandidat teridentifikasi	3.500+
Skill teradopsi	466
Skill vendor	373
Skill internal	93
Vendor aktif	25+
Rata-rata token per skill	2.834
Tool yang dirujuk	89
Tag unik	635

Kami telah meninjau lebih dari 3.500 kandidat skill. Kami telah mengadopsi 466. Itu tingkat adopsi 13% — dan selektivitas itu memang disengaja.

Sistem Tier Pengetahuan

Tidak semua skill diciptakan setara. Kami mengorganisasikannya ke dalam lima lapisan pengetahuan (K0-K4), masing-masing merepresentasikan cakupan penerapan yang berbeda:

K0: Foundations (Universal)

Skill yang harus dimiliki setiap agen. Ini merepresentasikan kapabilitas “pemikir yang baik” yang berlaku di mana saja.

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

Skill K0 bisa dibawa ke proyek mana pun, domain mana pun, stack mana pun. Mereka mengenkode pola kognitif yang universal.

K1: Identities (Disiplin)

Skill “engineer yang baik” atau “peneliti yang baik” yang berlaku lintas proyek dalam sebuah disiplin.

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

K2: Domains (Keahlian Subjek)

Skill “pakar database yang baik” atau “security engineer yang baik” yang bisa dibawa dalam sebuah bidang.

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 (Teknologi)

Skill “pengguna Supabase yang baik” atau “developer Cloudflare yang baik” untuk stack teknologi spesifik.

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

K4: Project (Organisasi)

Skill yang spesifik untuk organisasi dan alur kerja kami.

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

Loop Mining-nya

Fase 1: Discovery

Skill datang dari mana-mana:

Repositori Vendor: AWS, Anthropic, Cloudflare, Supabase, dan kontributor komunitas mempublikasikan koleksi skill. Kami melacak 25+ akar vendor.

Proyek Komunitas: GitHub penuh dengan template Claude Code, pola agen, dan definisi alur kerja.

Pola Internal: Seiring tim kami memecahkan masalah, pola-pola muncul. Ini diformalkan menjadi skill.

Mining Dokumentasi: Dokumentasi teknis sering mengandung skill implisit — prosedur, checklist, pohon keputusan.

Discovery berjalan terus-menerus. Kami menggunakan sebuah backlog skill untuk melacak kandidat sebelum evaluasi formal.

Fase 2: Evaluasi

Setiap kandidat melewati rubrik yang sama:

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

Semua lima kriteria produk harus lulus. Inilah sebabnya 87% kandidat ditolak.

Lalu setiap kandidat melewati tinjauan trust yang terpisah. Kami tidak memperlakukan sebuah repositori vendor resmi, seorang maintainer komunitas yang terkenal, dan sebuah repo GitHub acak sebagai sumber kebenaran yang setara.

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

Vendor tepercaya mendapat tinjauan provenance yang lebih ringan, tetapi bukan jaminan lolos begitu saja. Sumber yang tidak tepercaya atau tidak dikenal mendapat audit manual yang lebih dalam, dan kami tidak menjalankan script bawaan sampai script itu sudah dibaca, di-scope, dan diklasifikasikan sebagai aman.

Analisis Gap: Sebelum mengadopsi, kami mencari di registry kami:

uv run orkestra skills search "<capability>"

Jika kami sudah punya, kami tidak butuh itu. Jika kami punya sesuatu yang mirip, kami mungkin menggabungkan alih-alih mengadopsi.

Penilaian Kedalaman dan Standar: Kami juga menilai seberapa penuh sebuah kandidat menggunakan model agent-skill. Sebuah SKILL.md tunggal masih bisa berguna, tetapi skill yang lebih dalam lebih bernilai ketika mereka memisahkan instruksi dari referensi, script, dan asset dengan cara yang dianjurkan 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

Bintang GitHub bisa sedikit mengangkat skor kredibilitas, tetapi mereka tidak pernah menyelamatkan skill yang dangkal atau tidak aman. Sebuah repo berbintang tinggi dengan satu SKILL.md yang samar dan script yang opak mendapat skor lebih rendah daripada repo yang lebih kecil dengan deskripsi yang presisi, references/ yang terkurasi, dan helper atomik yang benar-benar memanfaatkan kapabilitas skill secara penuh.

Analisis Struktural: Kami memeriksa kualitas skill:

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

Jika sebuah kandidat menyertakan script, tinjauan itu menjadi lebih ketat. Sebuah skill yang baik bukan sekadar berguna; ia harus legible, terbatas, dan aman untuk diserahkan ke agen. Filter keamanan itu saja mendiskualifikasi sebagian kandidat yang sebenarnya menarik.

Fase 3: Ingestion

Ketika sebuah skill lulus evaluasi, ia masuk ke registry. Tetapi skill tidak pernah diadopsi tanpa perubahan. Mereka dimodifikasi agar cocok dengan sistem kami.

Modifikasi saat Adopsi:

1. Normalisasi Metadata: Setiap skill mendapat skema frontmatter kami
2. Penetapan K-Tier: Skill ditempatkan di lapisan pengetahuan yang sesuai
3. Pengayaan Tag: Tag ditambahkan untuk discovery
4. Deklarasi Tool: Tool yang diizinkan dideklarasikan secara eksplisit
5. Penyelarasan Section: Konten distruktur ulang agar sesuai dengan template kami

Sebuah YAML skill tipikal setelah ingestion:

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

Fase 4: Penetapan Scope

Skill ditetapkan ke scope — kategori yang menentukan agen mana yang memuat skill mana:

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

Agen mendeklarasikan scope mereka, dan skill ditetapkan secara otomatis:

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

Fase 5: Materialisasi

Skill tidak hidup sebagai YAML di produksi. Mereka di-render menjadi file SKILL.md yang bisa dimuat Claude Code:

uv run orkestra sync

Perintah ini:

1. Membaca semua definisi YAML skill
2. Merender lewat template Jinja
3. Menulis file SKILL.md ke .claude/skills/
4. Mengorganisasi berdasarkan K-tier (foundations/, identities/, domains/, stacks/, project/)

Struktur output akhirnya:

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

Pola Dormant Scope

Salah satu pola kami yang paling ampuh adalah skill “teradopsi-tapi-tidak-dimuat.” Kami menyebutnya dormant scope.

Pertimbangkan skill scientific computing dari repositori k-dense-scientific. Kami telah mengadopsi 120+ skill yang mencakup bioinformatika, kimia, quantum computing, dan clinical informatics. Tetapi sebagian besar agen kami tidak butuh molecular docking atau analisis ekspresi gen.

Alih-alih memuat semua 120 skill ke setiap agen (yang akan membengkakkan jendela konteks), kami:

1. Mengadopsi skill dengan scope tertentu (misalnya, bioinformatics)
2. Membiarkannya tetap dormant — terdaftar tapi tidak dimuat
3. Mengaktifkan hanya ketika sebuah agen mendeklarasikan scope itu

# 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

Pola ini memungkinkan kami memiliki 466 skill di registry sementara agen tipikal hanya memuat 40-60 yang relevan.

Tipe Skill

Skill hadir dalam tiga pola kognitif:

Workflow

Langkah prosedural yang berurutan: “1. Lakukan X, 2. Lalu Y, 3. Terakhir Z”

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

Discipline

Guardrail perilaku: “Selalu X”, “Jangan pernah Y”, “Utamakan Z”

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

Checklist

Kriteria verifikasi: “Konfirmasi X”, “Verifikasi Y”, “Periksa Z”

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

Quality Gate

Setiap skill harus lulus validasi sebelum dirilis:

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

Deskripsi harus 50-400 karakter dengan frase trigger (“Gunakan saat…”, “Ketika Anda butuh…”) sehingga Claude Code tahu kapan harus menyarankannya.

Kami memvalidasi secara berkelanjutan:

uv run orkestra validate --show-warnings

Ekosistem Vendor

373 skill vendor kami berasal dari:

Provider	Skill	Domain
AWS Agent	19	Layanan cloud
Anthropic	12	Generasi dokumen
Cloudflare	8	Edge computing
Supabase	5	Database
k-dense	100+	Scientific computing
silvainfm	4	Data science
Java Developer Kit	45+	Spring/Java
Vercel	1	Otomasi browser

Setiap akar vendor dideklarasikan dalam 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

Ketika orkestra sync berjalan, skill vendor di-symlink ke .claude/skills/vendor/ dengan namespace provider mereka.

Apa yang Telah Kami Pelajari

Selektivitas terbayar. Tergoda untuk mengadopsi semua yang terlihat berguna. Tetapi setiap skill punya biaya token. Dengan rata-rata 2.834 token per skill, kembung terasa cepat. Tingkat adopsi 13% kami menjaga agen tetap ramping.

Struktur memungkinkan discovery. Sistem K-tier bukan sekadar organisasi — ini soal portabilitas. Skill K0 bisa digunakan ulang di mana saja. Skill K4 sengaja dibuat spesifik proyek. Kejelasan ini membantu baik manusia maupun agen menemukan apa yang mereka butuhkan.

Dormant scope bisa berskala. Anda bisa mengadopsi ratusan skill tanpa memuat semuanya. Scope memungkinkan Anda membangun registry yang komprehensif sembari menjaga jendela konteks masing-masing agen tetap terkendali.

Modifikasi saat adopsi itu esensial. Skill vendor mentah jarang cocok dengan sistem Anda. Proses ingestion — menambahkan metadata, menetapkan tier, memperkaya tag — membuat skill eksternal bisa bekerja secara internal.

Mining berjalan terus-menerus. Angka 3.500 itu terus bertambah. Repo vendor baru muncul. Pola komunitas bermunculan. Alur kerja internal mengeras. Loop-nya tidak pernah berhenti.

Apa Selanjutnya

Kami sedang mengerjakan beberapa peningkatan:

1. Deteksi gap otomatis: Peringatkan ketika kegagalan agen yang umum bisa diatasi oleh sebuah skill yang belum diadopsi
2. Alur kerja deprecation skill: Proses formal untuk mempensiunkan skill yang sudah digantikan atau tidak terpakai
3. Dependensi antar-skill: Deklarasi eksplisit dari prasyarat skill
4. Analitik penggunaan: Lacak skill mana yang benar-benar dipanggil agen versus sekadar dimuat

Loop mining skill ini adalah infrastruktur. Ini tidak glamor. Tetapi inilah yang membuat 41 agen bekerja secara koheren dengan 466 kapabilitas sembari tetap berada dalam batas konteks.

Itulah kisah bagaimana 3.500 menjadi 466. Bukan dengan mengabaikan 3.000 — tetapi dengan mengevaluasinya secara sistematis dan hanya mengadopsi yang benar-benar berhasil.

---

Ingin melihat sistem skill ini beraksi? Lihat uv run orkestra skills list untuk menjelajahi registry kami saat ini.