# Skill mining: van 3.500 kandidaten naar 466 capaciteiten

Canonical source: https://maguyva.ai/nl/blog/skill-mining-3500-and-counting

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-01-27 · Author: Maguyva Team

> We screenden 3.500 skillkandidaten en namen er 466 over. Een systematische mining- en ingestielus voor het bouwen van een coherente AI-agent-skillbibliotheek op schaal.

> *Cijfers in deze post weerspiegelen het systeem op het moment van publicatie (januari 2026). Zie onze [teampagina](/nl/team) 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 wordt aan dezelfde beoordelingscriteria getoetst:

```yaml
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
```

Aan alle vijf productcriteria moet worden voldaan. 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.

```yaml
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:

```bash
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.

```yaml
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:

```bash
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:

```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
```

### Fase 4: scopetoewijzing

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

```yaml
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:

```yaml
# 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:

```bash
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), gaan we als volgt te werk:

1. **Neem** de skills **op** met een specifieke scope (bijv. `bioinformatics`)
2. Houd ze **dormant** — geregistreerd maar niet geladen
3. **Activeer** ze alleen wanneer een agent die scope declareert

```yaml
# 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"

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

### Discipline

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

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

### Checklist

Verificatiecriteria: "Bevestig X", "Verifieer Y", "Controleer Z"

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

## Kwaliteitsgates

Elke skill moet validatie doorstaan voordat hij wordt uitgeleverd:

```yaml
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:

```bash
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:

```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 krijgen vaste vorm. 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 niet worden gebruikt
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.

Zo brengen we 3.500 kandidaten terug tot 466 skills. 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.*