# Skill mining: Fra 3500 kandidater til 466 evner

Canonical source: https://maguyva.ai/nb/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 vurderte 3500 skill-kandidater og tok i bruk 466. En systematisk mining- og innlemmingsløkke for å bygge et sammenhengende skill-bibliotek for AI-agenter i stor skala.

> *Tallene i dette innlegget gjenspeiler systemet ved publisering (januar 2026). Se [teamsiden](/nb/team) for gjeldende tall.*

## 3500-skill-problemet

Da vi begynte å bygge et orkestreringssystem for agenter, sto vi overfor en interessant utfordring: det finnes tusenvis av potensielle skills spredt utover AI-økosystemet. GitHub-repositorier, leverandørdokumentasjon, community-prosjekter, interne mønstre — skills finnes overalt. Men hvilke betyr noe? Hvilke fungerer? Og hvordan vedlikeholder man et sammenhengende skill-bibliotek som agenter faktisk kan bruke?

Svaret vårt: en systematisk mining- og innlemmingsløkke.

## Tallene i dag

Bare litt over tre måneder etter at Anthropic lanserte Agent Skills 16. oktober 2025, var dette stillingen da dette innlegget ble publisert 27. januar 2026:

| Metrikk | Antall |
|--------|-------|
| Identifiserte kandidater | 3500+ |
| Adopterte skills | 466 |
| Leverandørskills (vendor) | 373 |
| Interne skills | 93 |
| Aktive leverandører | 25+ |
| Gjennomsnittlige tokens per skill | 2834 |
| Refererte verktøy | 89 |
| Unike tagger | 635 |

Vi har gjennomgått over 3500 skill-kandidater. Vi har adoptert 466. Det er en adopsjonsrate på 13 % — og den selektiviteten er bevisst.

## Kunnskapsnivåsystemet

Skills har ulik kvalitet og ulikt bruksområde. Vi organiserer dem i fem kunnskapslag (K0–K4), hvert med et forskjellig anvendelsesomfang:

### K0: Foundations (universelt)

Skills alle agenter bør ha. Disse representerer «god tenker»-kapabiliteter som fungerer 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 prosjekt, ethvert domene, enhver stack. De koder for universelle kognitive mønstre.

### K1: Identities (disiplin)

«God ingeniør»- eller «god forsker»-skills som gjelder på tvers av prosjekter innenfor en 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 (fagekspertise)

«God databaseekspert»- eller «god sikkerhetsingeniør»-skills, portable innenfor 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-bruker»- eller «god Cloudflare-utvikler»-skills for spesifikke teknologistacker.

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

### K4: Project (organisasjon)

Skills spesifikke for vår organisasjon og våre arbeidsflyter.

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

Skills kommer fra overalt:

**Leverandørrepositorier**: AWS, Anthropic, Cloudflare, Supabase, og community-bidragsytere publiserer skill-samlinger. Vi følger 25+ leverandørrøtter.

**Community-prosjekter**: GitHub er fullt av Claude Code-maler, agentmønstre og arbeidsflytdefinisjoner.

**Interne mønstre**: Etter hvert som teamet vårt løser problemer, oppstår mønstre. Disse formaliseres til skills.

**Dokumentasjonsmining**: Teknisk dokumentasjon inneholder ofte implisitte skills — prosedyrer, sjekklister, beslutningstrær.

Oppdagelse er kontinuerlig. Vi bruker en skill-backlog for å spore kandidater før formell evaluering.

### Fase 2: Evaluering

Hver kandidat vurderes etter de samme kriteriene:

```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 må være oppfylt. Det er derfor 87 % av kandidatene avvises.

Deretter går hver kandidat gjennom en separat tillitsgjennomgang. Vi behandler ikke et offisielt leverandørrepositorium, en velkjent community-vedlikeholder, og et tilfeldig GitHub-repo som likeverdige sannhetskilder.

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

Betrodde leverandører får en lettere herkomstgjennomgang, men ikke fribillett. Ikke-betrodde eller ukjente kilder får en dypere manuell revisjon, og vi kjører ikke medfølgende skript før de er lest, avgrenset, og klassifisert som trygge.

**Gap-analyse**: Før vi adopterer, søker vi i registeret vårt:

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

Hvis vi allerede har det, trenger vi det ikke. Hvis vi har noe likt, kan vi heller slå sammen enn å adoptere.

**Dybde- og standardscoring**: Vi scorer også hvor fullt ut en kandidat bruker agent-skill-modellen. Et ensomt `SKILL.md` kan fortsatt være nyttig, men dypere skills er mer verdifulle når de skiller instruksjoner fra referanser, skript og ressurser på den måten `agentskills.io` oppmuntrer 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 troverdighetsscore litt, men de redder aldri en overfladisk eller utrygg skill. Et repo med mange stjerner og én vag `SKILL.md` og uklare skript scorer under et mindre repo med en presis beskrivelse, kuraterte `references/`, og små hjelpeprogrammer med én avgrenset oppgave som faktisk utnytter hele skill-kapabiliteten.

**Strukturell analyse**: Vi sjekker 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 skript, blir den gjennomgangen strengere. En god skill er ikke bare nyttig; den må være lesbar, avgrenset, og trygg å overlate til en agent. Det sikkerhetsfilteret alene diskvalifiserer en betydelig andel av ellers interessante kandidater.

### Fase 3: Innlemming

Når en skill består evalueringen, går den inn i registeret. Men skills adopteres aldri uendret. De modifiseres for å passe systemet vårt.

**Modifikasjoner ved adopsjon**:

1. **Metadatanormalisering**: Hver skill får frontmatter-skjemaet vårt
2. **K-nivå-tildeling**: Skills plasseres i riktig kunnskapslag
3. **Tag-berikelse**: Tagger legges til for oppdagbarhet
4. **Verktøydeklarasjon**: Tillatte verktøy deklareres eksplisitt
5. **Seksjonstilpasning**: Innhold restruktureres til å matche malen vår

En typisk skill-YAML etter innlemming:

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

Skills tildeles omfang (scopes) — kategorier som avgjør hvilke agenter som laster 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 deklarerer sine omfang, 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 produksjon. De rendres til SKILL.md-filer som Claude Code kan laste:

```bash
uv run orkestra sync
```

Denne kommandoen:
1. Leser alle skill-YAML-definisjoner
2. Rendrer dem gjennom Jinja-maler
3. Skriver SKILL.md-filer til `.claude/skills/`
4. Organiserer etter K-nivå (foundations/, identities/, domains/, stacks/, project/)

Den endelige resultatstrukturen:

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

## Det sovende omfangs-mønsteret

Ett av våre kraftigste mønstre er «adoptert-men-ikke-lastet»-skills. Vi kaller disse sovende omfang (dormant scopes).

Ta for eksempel vitenskapelige databehandlings-skills fra k-dense-scientific-repositoriet. Vi har adoptert 120+ skills som dekker bioinformatikk, kjemi, kvantedatabehandling, og klinisk informatikk. Men de fleste av agentene våre trenger ikke molekylær docking eller genuttrykksanalyse.

I stedet for å laste alle 120 skillsene inn i hver agent (som blåser opp kontekstvinduene), gjør vi:

1. **Adopterer** skillsene med et spesifikt omfang (f.eks. `bioinformatics`)
2. Holder dem **sovende** — registrert, men ikke lastet
3. **Aktiverer** dem bare når en agent deklarerer det omfanget

```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ønsteret lar oss ha 466 skills i registeret mens typiske agenter bare laster 40–60 relevante.

## Skill-typer

Skills kommer i tre kognitive mønstre:

### Workflow

Ordnede prosedyrale steg: «1. Gjør X, 2. Deretter Y, 3. Til slutt Z»

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

### Discipline

Atferdsvern: «Alltid X», «Aldri Y», «Foretrekk Z»

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

### Checklist

Verifiseringskriterier: «Bekreft X», «Verifiser Y», «Sjekk Z»

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

## Kvalitetsporter

Hver skill må 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 må være 50–400 tegn med utløserfraser («Use when...», «When you need...») slik at Claude Code vet når den skal foreslå dem.

Vi validerer kontinuerlig:

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

## Leverandørøkosystemet

Våre 373 leverandørskills kommer fra:

| Leverandør | Skills | Domene |
|----------|--------|--------|
| AWS Agent | 19 | Skytjenester |
| Anthropic | 12 | Dokumentgenerering |
| Cloudflare | 8 | Edge computing |
| Supabase | 5 | Database |
| k-dense | 100+ | Vitenskapelig databehandling |
| silvainfm | 4 | Data science |
| Java Developer Kit | 45+ | Spring/Java |
| Vercel | 1 | Nettleserautomatisering |

Hver leverandørrot deklareres 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` kjører, symlinkes leverandørskills inn i `.claude/skills/vendor/` med sitt leverandørnavnerom.

## Hva vi har lært

**Selektivitet lønner seg.** Det er fristende å adoptere alt som ser nyttig ut. Men hver skill koster tokens. Med 2834 tokens i gjennomsnitt per skill, fyller unødvendig innhold raskt kontekstvinduet. Vår adopsjonsrate på 13 % holder agenter slanke.

**Struktur muliggjør oppdagelse.** K-nivåsystemet handler ikke bare om organisering — det handler om portabilitet. K0-skills kan gjenbrukes hvor som helst. K4-skills er bevisst prosjektspesifikke. Denne klarheten hjelper både mennesker og agenter å finne det de trenger.

**Sovende omfang skalerer.** Du kan adoptere hundrevis av skills uten å laste dem alle. Omfang lar deg bygge et omfattende register samtidig som du holder den enkelte agents kontekstvindu håndterlig.

**Tilpasning ved innføring er avgjørende.** Rå leverandørskills passer sjelden systemet ditt. Innlemmingsprosessen — å legge til metadata, tildele nivåer, berike tagger — gjør at eksterne skills fungerer internt.

**Mining er kontinuerlig.** Antallet kandidater fortsetter å vokse fra 3500. Nye leverandørrepositorier dukker opp. Community-mønstre oppstår. Interne arbeidsflyter befestes. Løkken stopper aldri.

## Hva som kommer

Vi jobber med flere forbedringer:

1. **Automatisert gap-deteksjon**: Varsle når vanlige agentfeil kunne vært løst av en ikke-adoptert skill
2. **Arbeidsflyter for utfasing av skills**: Formell prosess for å pensjonere skills som er erstattet eller ubrukt
3. **Avhengigheter på tvers av skills**: Eksplisitt deklarering av skill-forutsetninger
4. **Bruksanalyse**: Spor hvilke skills agenter faktisk påkaller versus bare laster

Mining-løkken for skills er infrastruktur. Den er ikke glamorøs. Men det er den som gjør at 41 agenter fungerer sammenhengende med 466 kapabiliteter, samtidig som de holder seg innenfor kontekstgrensene.

Det er historien om hvordan 3500 blir 466. Ikke ved å ignorere 3000 — men ved å evaluere dem systematisk og bare adoptere det som fungerer.

---

*Vil du se skill-systemet i aksjon? Sjekk ut `uv run orkestra skills list` for å utforske det gjeldende registeret vårt.*