Skill mining: Fra 3500 kandidater til 466 evner

Tallene i dette innlegget gjenspeiler systemet ved publisering (januar 2026). Se teamsiden 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

Ikke alle skills er skapt like. 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 går gjennom den samme rubrikken:

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å bestå. 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.

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:

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.

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 atomiske hjelpere som faktisk utnytter hele skill-kapabiliteten.

Strukturell analyse: Vi sjekker skill-kvalitet:

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. Den 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:

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:

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:

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

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

# 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»

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

Discipline

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

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

Checklist

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

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

Kvalitetsporter

Hver skill må bestå validering før den shippes:

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:

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:

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, skader oppblåsthet raskt. 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.

Modifikasjon ved adopsjon er essensielt. 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. 3500-tallet fortsetter å vokse. 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.