Skill mining: van 3.500 kandidaten naar 466 capaciteiten

Cijfers in deze post weerspiegelen het systeem op het moment van publicatie (januari 2026). Zie onze teampagina voor actuele cijfers.

Het probleem van de 3.500 skills

Toen we begonnen met het bouwen van een agent-orchestratiesysteem, stonden we voor een interessante uitdaging: er zijn duizenden potentiële skills verspreid over het AI-ecosysteem. GitHub-repositories, vendordocumentatie, communityprojecten, interne patronen — skills bestaan overal. Maar welke zijn belangrijk? Welke werken? En hoe onderhoud je een coherente skillbibliotheek die agents daadwerkelijk kunnen gebruiken?

Ons antwoord: een systematische mining- en ingestielus.

De cijfers vandaag

Iets meer dan drie maanden nadat Anthropic Agent Skills lanceerde op 16 oktober 2025, is dit waar we stonden toen deze post werd gepubliceerd op 27 januari 2026:

Metriek	Aantal
Geïdentificeerde kandidaten	3.500+
Overgenomen skills	466
Vendor-skills	373
Interne skills	93
Actieve vendors	25+
Gemiddeld aantal tokens per skill	2.834
Gerefereerde tools	89
Unieke tags	635

We hebben meer dan 3.500 skillkandidaten beoordeeld. We hebben er 466 overgenomen. Dat is een adoptiepercentage van 13% — en die selectiviteit is met opzet.

Het kennis-tiersysteem

Niet alle skills zijn gelijk. We organiseren ze in vijf kennislagen (K0-K4), elk met een andere reikwijdte van toepasbaarheid:

K0: Foundations (universeel)

Skills die elke agent zou moeten hebben. Deze vertegenwoordigen “goede denker”-capaciteiten die overal werken.

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-skills zijn overdraagbaar naar elk project, elk domein, elke stack. Ze coderen universele cognitieve patronen.

K1: Identities (discipline)

“Goede engineer”- of “goede onderzoeker”-skills die van toepassing zijn over projecten heen binnen een discipline.

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

K2: Domains (vakexpertise)

“Goede database-expert”- of “goede security-engineer”-skills die overdraagbaar zijn binnen een vakgebied.

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

“Goede Supabase-gebruiker”- of “goede Cloudflare-developer”-skills voor specifieke technologiestacks.

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

K4: Project (organisatie)

Skills specifiek voor onze organisatie en workflows.

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

De mininglus

Fase 1: ontdekking

Skills komen overal vandaan:

Vendor-repositories: AWS, Anthropic, Cloudflare, Supabase en communitybijdragers publiceren skillcollecties. We volgen 25+ vendor-roots.

Communityprojecten: GitHub staat vol met Claude Code-templates, agentpatronen en workflowdefinities.

Interne patronen: Terwijl ons team problemen oplost, ontstaan patronen. Die worden geformaliseerd tot skills.

Documentatiemining: technische documentatie bevat vaak impliciete skills — procedures, checklists, beslisbomen.

Ontdekking is continu. We gebruiken een skillbacklog om kandidaten bij te houden vóór formele evaluatie.

Fase 2: evaluatie

Elke kandidaat doorloopt dezelfde rubriek:

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

Alle vijf productcriteria moeten slagen. Daarom wordt 87% van de kandidaten afgewezen.

Vervolgens doorloopt elke kandidaat een aparte trust review. We behandelen een officiële vendor-repository, een bekende community-maintainer en een willekeurige GitHub-repo niet als gelijkwaardige sources of truth.

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

Vertrouwde vendors krijgen een lichtere herkomstreview, maar geen vrijbrief. Niet-vertrouwde of onbekende bronnen krijgen een diepere handmatige audit, en we voeren gebundelde scripts pas uit nadat ze zijn gelezen, afgebakend en als veilig geclassificeerd.

Gap-analyse: vóór we iets overnemen, doorzoeken we ons register:

uv run orkestra skills search "<capability>"

Als we het al hebben, hebben we het niet nodig. Als we iets vergelijkbaars hebben, mergen we het misschien liever dan het over te nemen.

Scoren op diepgang en standaarden: we scoren ook hoe volledig een kandidaat het agent-skill-model gebruikt. Een losstaande SKILL.md kan nog altijd nuttig zijn, maar diepere skills zijn waardevoller wanneer ze instructies scheiden van referenties, scripts en assets, zoals agentskills.io aanmoedigt.

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-sterren kunnen een credibility-score een beetje verhogen, maar ze redden nooit een oppervlakkige of onveilige skill. Een repo met veel sterren en één vage SKILL.md met ondoorzichtige scripts scoort lager dan een kleinere repo met een precieze beschrijving, samengestelde references/, en atomaire helpers die de volledige skillcapaciteit daadwerkelijk benutten.

Structurele analyse: we controleren skillkwaliteit:

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

Als een kandidaat scripts bevat, wordt die review strenger. Een goede skill is niet alleen nuttig; hij moet ook leesbaar, afgebakend en veilig zijn om aan een agent te geven. Dat veiligheidsfilter alleen al diskwalificeert een aanzienlijk deel van verder interessante kandidaten.

Fase 3: ingestie

Wanneer een skill de evaluatie doorstaat, komt hij in het register. Maar skills worden nooit ongewijzigd overgenomen. Ze worden aangepast om in ons systeem te passen.

Aanpassingen bij overname:

1. Metadatanormalisatie: elke skill krijgt ons frontmatter-schema
2. K-tiertoewijzing: skills worden in de juiste kennislaag geplaatst
3. Tagverrijking: tags worden toegevoegd voor vindbaarheid
4. Tooldeclaratie: toegestane tools worden expliciet gedeclareerd
5. Sectie-uitlijning: inhoud wordt geherstructureerd om overeen te komen met onze template

Een typische skill-YAML na ingestie:

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: scopetoewijzing

Skills worden toegewezen aan scopes — categorieën die bepalen welke agents welke skills laden:

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

Agents declareren hun scopes, en skills worden automatisch toegewezen:

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

Fase 5: materialisatie

Skills bestaan niet als YAML in productie. Ze worden gerenderd naar SKILL.md-bestanden die Claude Code kan laden:

uv run orkestra sync

Dit commando:

1. Leest alle skill-YAML-definities
2. Rendert ze via Jinja-templates
3. Schrijft SKILL.md-bestanden naar .claude/skills/
4. Organiseert per K-tier (foundations/, identities/, domains/, stacks/, project/)

De uiteindelijke outputstructuur:

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

Het dormant-scope-patroon

Een van onze krachtigste patronen is “overgenomen-maar-niet-geladen”-skills. We noemen deze dormant scopes.

Denk aan scientific-computing-skills uit de k-dense-scientific-repository. We hebben er 120+ overgenomen die bio-informatica, scheikunde, quantum computing en klinische informatica bestrijken. Maar de meeste van onze agents hebben geen molecular docking of gene expression analysis nodig.

In plaats van alle 120 skills in elke agent te laden (wat contextvensters opblaast), doen we:

1. Adopt de skills met een specifieke scope (bijv. bioinformatics)
2. Houd ze dormant — geregistreerd maar niet geladen
3. Enable ze alleen wanneer een agent die scope declareert

# 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

Dit patroon laat ons 466 skills in het register hebben, terwijl typische agents er slechts 40-60 relevante laden.

Skilltypes

Skills komen in drie cognitieve patronen:

Workflow

Geordende procedurele stappen: “1. Doe X, 2. Dan Y, 3. Tot slot Z”

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

Discipline

Gedragsmatige guardrails: “Doe altijd X”, “Doe nooit Y”, “Geef de voorkeur aan Z”

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

Checklist

Verificatiecriteria: “Bevestig X”, “Verifieer Y”, “Controleer Z”

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

Kwaliteitsgates

Elke skill moet validatie doorstaan voordat hij wordt uitgeleverd:

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

Beschrijvingen moeten 50-400 tekens zijn met triggerzinnen (“Use when…”, “When you need…”) zodat Claude Code weet wanneer hij ze moet voorstellen.

We valideren continu:

uv run orkestra validate --show-warnings

Het vendor-ecosysteem

Onze 373 vendor-skills komen van:

Provider	Skills	Domein
AWS Agent	19	Cloudservices
Anthropic	12	Documentgeneratie
Cloudflare	8	Edge computing
Supabase	5	Database
k-dense	100+	Scientific computing
silvainfm	4	Data science
Java Developer Kit	45+	Spring/Java
Vercel	1	Browserautomatisering

Elke vendor-root wordt gedeclareerd in 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

Wanneer orkestra sync draait, worden vendor-skills gesymlinkt naar .claude/skills/vendor/ met hun provider-namespace.

Wat we hebben geleerd

Selectiviteit loont. Het is verleidelijk om alles over te nemen wat er nuttig uitziet. Maar elke skill kost tokens. Met gemiddeld 2.834 tokens per skill doet bloat snel pijn. Ons adoptiepercentage van 13% houdt agents slank.

Structuur maakt ontdekking mogelijk. Het K-tiersysteem is niet zomaar organisatie — het gaat om overdraagbaarheid. K0-skills kunnen overal worden hergebruikt. K4-skills zijn opzettelijk projectspecifiek. Deze helderheid helpt zowel mensen als agents vinden wat ze nodig hebben.

Dormant scopes schalen. Je kunt honderden skills overnemen zonder ze allemaal te laden. Scopes laten je een uitgebreid register bouwen terwijl de contextvensters van individuele agents behapbaar blijven.

Aanpassing bij overname is essentieel. Ruwe vendor-skills passen zelden in jouw systeem. Het ingestieproces — metadata toevoegen, tiers toewijzen, tags verrijken — laat externe skills intern werken.

Mining is continu. Het getal van 3.500 blijft groeien. Nieuwe vendor-repo’s verschijnen. Communitypatronen ontstaan. Interne workflows verharden. De lus stopt nooit.

Wat komt hierna

We werken aan verschillende verbeteringen:

1. Geautomatiseerde gap-detectie: waarschuwen wanneer veelvoorkomende agentfouten kunnen worden verholpen door een niet-overgenomen skill
2. Skill-deprecationworkflows: formeel proces voor het uitfaseren van skills die zijn vervangen of ongebruikt
3. Cross-skill-afhankelijkheden: expliciete declaratie van skillvereisten
4. Gebruiksanalytics: bijhouden welke skills agents daadwerkelijk aanroepen versus alleen laden

De skill-mininglus is infrastructuur. Het is niet glamoureus. Maar het is wat 41 agents coherent laat samenwerken met 466 capaciteiten terwijl ze binnen contextlimieten blijven.

Dat is het verhaal van hoe 3.500 466 wordt. Niet door 3.000 te negeren — door ze systematisch te evalueren en alleen over te nemen wat werkt.

---

Wil je het skillsysteem in actie zien? Bekijk uv run orkestra skills list om ons huidige register te verkennen.