Skill mining: Fra 3.500 kandidater til 466 kapabiliteter

Tallene i dette indlæg afspejler systemet på udgivelsestidspunktet (januar 2026). Se vores team-side 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 indtagelsesløkke.

Tallene i dag

Lidt over tre måneder efter Anthropic lancerede Agent Skills den 16. oktober 2025, sådan så vores status 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 er skabt lige. 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 gennemgår den samme rubrik:

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.

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:

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.

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:

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

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

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:

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:

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

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. Adopterer vi skills med et specifikt scope (f.eks. bioinformatics)
2. Holder vi dem dvalende - registreret, men ikke indlæst
3. Aktiverer vi dem kun, når en agent erklærer det scope

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

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

Discipline

Adfærdsmæssige autoværn: “Altid X”, “Aldrig Y”, “Foretræk Z”

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

Checklist

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

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

Kvalitetsgates

Enhver skill skal 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 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:

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:

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. Indtagelsesprocessen - 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 stivner. 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.