# Skill mining: Fra 3.500 kandidater til 466 kapabiliteter

Canonical source: https://maguyva.ai/da/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

> Vi screenede 3.500 skill-kandidater og adopterede 466. En systematisk mining- og indarbejdelsesløkke til at opbygge et sammenhængende skill-bibliotek til AI-agenter i stor skala.

> *Tallene i dette indlæg afspejler systemet på udgivelsestidspunktet (januar 2026). Se vores [team-side](/da/team) for aktuelle tal.*

## 3.500-skill-problemet

Da vi begyndte at bygge et agent-orkestreringssystem, stod vi over for en interessant udfordring: der findes tusindvis af potentielle skills spredt ud over AI-økosystemet. GitHub-repositorier, leverandørdokumentation, community-projekter, interne mønstre - skills findes overalt. Men hvilke betyder noget? Hvilke virker? Og hvordan vedligeholder man et sammenhængende skill-bibliotek, som agenter rent faktisk kan bruge?

Vores svar: en systematisk mining- og indarbejdelsesløkke.

## Tallene i dag

Lidt over tre måneder efter Anthropic lancerede Agent Skills den 16. oktober 2025, så vores status sådan ud, da dette indlæg blev udgivet den 27. januar 2026:

| Metrik | Antal |
|--------|-------|
| Identificerede kandidater | 3.500+ |
| Adopterede skills | 466 |
| Leverandør-skills | 373 |
| Interne skills | 93 |
| Aktive leverandører | 25+ |
| Gennemsnitlige tokens pr. skill | 2.834 |
| Refererede værktøjer | 89 |
| Unikke tags | 635 |

Vi har gennemgået over 3.500 skill-kandidater. Vi har adopteret 466. Det er en adoptionsrate på 13% - og den selektivitet er tilsigtet.

## Videnslagssystemet

Ikke alle skills har samme værdi. Vi organiserer dem i fem videnslag (K0-K4), der hver repræsenterer et forskelligt anvendelsesscope:

### K0: Foundations (universel)

Skills, enhver agent bør have. Disse repræsenterer "god tænker"-kapabiliteter, der virker overalt.

```
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 er portable til ethvert projekt, ethvert domæne, enhver stack. De indkoder universelle kognitive mønstre.

### K1: Identities (disciplin)

"God ingeniør"- eller "god forsker"-skills, der gælder på tværs af projekter inden for en disciplin.

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

### K2: Domains (fagekspertise)

"God databaseekspert"- eller "god sikkerhedsingeniør"-skills, der er portable inden for et felt.

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

"God Supabase-bruger"- eller "god Cloudflare-udvikler"-skills til specifikke teknologistakke.

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

### K4: Project (organisation)

Skills, der er specifikke for vores organisation og arbejdsgange.

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

## Mining-løkken

### Fase 1: Discovery

Skills kommer fra alle steder:

**Leverandørrepositorier**: AWS, Anthropic, Cloudflare, Supabase og community-bidragydere udgiver skill-samlinger. Vi følger 25+ leverandørrødder.

**Community-projekter**: GitHub er fuldt af Claude Code-skabeloner, agentmønstre og arbejdsgangsdefinitioner.

**Interne mønstre**: Efterhånden som vores team løser problemer, opstår mønstre. Disse formaliseres til skills.

**Dokumentationsmining**: Teknisk dokumentation indeholder ofte implicitte skills - procedurer, tjeklister, beslutningstræer.

Discovery er kontinuerlig. Vi bruger en skill-backlog til at spore kandidater før formel evaluering.

### Fase 2: Evaluering

Enhver kandidat vurderes efter de samme kriterier:

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

Alle fem produktkriterier skal bestås. Det er derfor, 87% af kandidaterne afvises.

Derefter gennemgår enhver kandidat en separat tillidsgennemgang. Vi behandler ikke et officielt leverandørrepository, en velkendt community-vedligeholder og et tilfældigt GitHub-repository som ligeværdige sandhedskilder.

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

Betroede leverandører får en lettere proveniensgennemgang, men ikke fribillet. Ikke-betroede eller ukendte kilder får et dybere manuelt tjek, og vi kører ikke medfølgende scripts, før de er blevet læst, afgrænset og klassificeret som sikre.

**Gap-analyse**: Før vi adopterer, søger vi i vores register:

```bash
uv run orkestra skills search "<capability>"
```

Hvis vi allerede har det, har vi ikke brug for det. Hvis vi har noget tæt på, kan vi vælge at fusionere i stedet for at adoptere.

**Dybde- og standardscoring**: Vi scorer også, hvor fuldt en kandidat udnytter agent-skill-modellen. Et enligt `SKILL.md` kan stadig være nyttigt, men dybere skills er mere værdifulde, når de adskiller instruktioner fra referencer, scripts og assets på den måde, `agentskills.io` opfordrer til.

```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-stjerner kan løfte en troværdighedsscore en smule, men de redder aldrig en overfladisk eller usikker skill. Et repository med mange stjerner og én vag `SKILL.md` og uigennemsigtige scripts scorer lavere end et mindre repository med en præcis beskrivelse, kurateret `references/` og atomare hjælpefunktioner, der rent faktisk udnytter den fulde skill-kapabilitet.

**Strukturel analyse**: Vi tjekker skill-kvalitet:

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

Hvis en kandidat inkluderer scripts, bliver den gennemgang mere striks. En god skill er ikke bare nyttig; den skal være læselig, afgrænset og sikker at overlade til en agent. Det sikkerhedsfilter alene diskvalificerer en betydelig andel af ellers interessante kandidater.

### Fase 3: Indarbejdelse

Når en skill består evalueringen, kommer den ind i registret. Men skills adopteres aldrig uændrede. De modificeres, så de passer til vores system.

**Modifikationer ved adoption**:

1. **Metadata-normalisering**: Enhver skill får vores frontmatter-skema
2. **K-lags-tildeling**: Skills placeres i det passende videnslag
3. **Tag-berigelse**: Tags tilføjes til discovery
4. **Værktøjsdeklaration**: Tilladte værktøjer erklæres eksplicit
5. **Sektionsjustering**: Indhold omstruktureres, så det matcher vores template

En typisk skill-YAML efter indarbejdelse:

```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: Scope-tildeling

Skills tildeles scopes - kategorier, der afgør, hvilke agenter der indlæser hvilke skills:

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

Agenter erklærer deres scopes, og skills tildeles automatisk:

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

### Fase 5: Materialisering

Skills lever ikke som YAML i produktion. De renderes til SKILL.md-filer, som Claude Code kan indlæse:

```bash
uv run orkestra sync
```

Denne kommando:
1. Læser alle skill-YAML-definitioner
2. Renderer dem gennem Jinja-templates
3. Skriver SKILL.md-filer til `.claude/skills/`
4. Organiserer efter K-lag (foundations/, identities/, domains/, stacks/, project/)

Den endelige outputstruktur:

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

## Det dvalende scope-mønster

Et af vores mest kraftfulde mønstre er "adopteret-men-ikke-indlæst"-skills. Vi kalder disse dvalende scopes.

Overvej scientific computing-skills fra k-dense-scientific-repositoriet. Vi har adopteret 120+ skills, der dækker bioinformatik, kemi, kvantecomputing og klinisk informatik. Men de fleste af vores agenter har ikke brug for molekylær docking eller genekspressionsanalyse.

I stedet for at indlæse alle 120 skills i hver agent (hvilket oppuster kontekstvinduer), gør vi følgende:

1. Vi **adopterer** skills med et specifikt scope (f.eks. `bioinformatics`)
2. Vi holder dem **dvalende** - registreret, men ikke indlæst
3. Vi **aktiverer** dem kun, når en agent erklærer det scope

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

Dette mønster lader os have 466 skills i registret, mens typiske agenter kun indlæser 40-60 relevante.

## Skill-typer

Skills kommer i tre kognitive mønstre:

### Workflow

Ordnede procedurelle trin: "1. Gør X, 2. Så Y, 3. Til sidst Z"

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

### Discipline

Regler for adfærd: "Altid X", "Aldrig Y", "Foretræk Z"

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

### Checklist

Verificeringskriterier: "Bekræft X", "Verificér Y", "Tjek Z"

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

## Kvalitetsgates

Enhver skill skal bestå validering, før den shippes:

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

Beskrivelser skal være 50-400 tegn med udløsningsfraser ("Use when...", "When you need..."), så Claude Code ved, hvornår den skal foreslå dem.

Vi validerer løbende:

```bash
uv run orkestra validate --show-warnings
```

## Leverandørøkosystemet

Vores 373 leverandør-skills kommer fra:

| Leverandør | Skills | Domæne |
|----------|--------|--------|
| AWS Agent | 19 | Cloud-tjenester |
| Anthropic | 12 | Dokumentgenerering |
| 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 |

Hver leverandørrod erklæres i 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
```

Når `orkestra sync` kører, symlinkes leverandør-skills ind i `.claude/skills/vendor/` med deres leverandørnavnerum.

## Hvad vi har lært

**Selektivitet betaler sig.** Det er fristende at adoptere alt, der ser nyttigt ud. Men hver skill koster tokens. Med 2.834 gennemsnitlige tokens pr. skill går bloat hurtigt ud over ydeevnen. Vores adoptionsrate på 13% holder agenter slanke.

**Struktur muliggør discovery.** K-lagsystemet er ikke bare organisering - det handler om portabilitet. K0-skills kan genbruges hvor som helst. K4-skills er bevidst projektspecifikke. Denne klarhed hjælper både mennesker og agenter med at finde det, de har brug for.

**Dvalende scopes skalerer.** Man kan adoptere hundredvis af skills uden at indlæse dem alle. Scopes lader dig bygge et omfattende register, samtidig med at individuelle agenters kontekstvinduer forbliver håndterbare.

**Modifikation ved adoption er essentiel.** Rå leverandør-skills passer sjældent til ens system. Indarbejdelsesprocessen - tilføjelse af metadata, tildeling af lag, berigelse af tags - får eksterne skills til at fungere internt.

**Mining er kontinuerlig.** Tallet 3.500 bliver ved med at vokse. Nye leverandørrepositorier dukker op. Community-mønstre opstår. Interne arbejdsgange tager form. Løkken stopper aldrig.

## Hvad er det næste?

Vi arbejder på flere forbedringer:

1. **Automatiseret gap-detektion**: Advarsel når almindelige agentfejl kunne løses af en ikke-adopteret skill
2. **Skill-udfasningsarbejdsgange**: Formel proces til at pensionere skills, der er overflødiggjort eller ubrugte
3. **Cross-skill-afhængigheder**: Eksplicit erklæring af skill-forudsætninger
4. **Brugsanalyser**: Spor hvilke skills agenter rent faktisk påkalder vs. bare indlæser

Skill-mining-løkken er infrastruktur. Det er ikke glamourøst. Men det er det, der får 41 agenter til at fungere sammenhængende med 466 kapabiliteter, samtidig med at de holder sig inden for kontekstgrænserne.

Det er historien om, hvordan 3.500 bliver til 466. Ikke ved at ignorere 3.000 - men ved at evaluere dem systematisk og kun adoptere det, der virker.

---

*Vil du se skill-systemet i aktion? Tjek `uv run orkestra skills list` ud for at udforske vores nuværende register.*