Skill-mining: från 3 500 kandidater till 466 förmågor

3500-skillproblemet

När vi började bygga ett agentorkestreringssystem stod vi inför en intressant utmaning: det finns tusentals potentiella skills utspridda över hela AI-ekosystemet. GitHub-repositorier, leverantörsdokumentation, communityprojekt, interna mönster — skills finns överallt. Men vilka spelar roll? Vilka fungerar? Och hur underhåller man ett sammanhängande skill-bibliotek som agenter faktiskt kan använda?

Vårt svar: en systematisk mining- och intagsloop.

Siffrorna idag

Bara drygt tre månader efter att Anthropic lanserade Agent Skills den 16 oktober 2025, så här såg det ut när det här inlägget publicerades den 27 januari 2026:

Mätvärde	Antal
Identifierade kandidater	3 500+
Antagna skills	466
Leverantörsskills	373
Interna skills	93
Aktiva leverantörer	25+
Genomsnittliga tokens per skill	2 834
Refererade verktyg	89
Unika taggar	635

Vi har granskat över 3 500 skill-kandidater. Vi har antagit 466. Det är en antagandegrad på 13 % — och den selektiviteten är avsiktlig.

Kunskapsnivåsystemet

Alla skills är inte likvärdiga. Vi organiserar dem i fem kunskapslager (K0–K4), var och en representerar en annan tillämplighetsgrad:

K0: Grunder (universellt)

Skills alla agenter bör ha. De representerar “god tänkare”-förmågor som fungerar överallt.

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 är portabla till vilket projekt, vilken domän, vilken stack som helst. De kodifierar universella kognitiva mönster.

K1: Identiteter (disciplin)

“God ingenjör”- eller “god forskare”-skills som gäller över projekt inom 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: Domäner (ämnesexpertis)

“God databasexpert”- eller “god säkerhetsingenjör”-skills portabla inom ett fält.

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: Stackar (teknik)

“God Supabase-användare”- eller “god Cloudflare-utvecklare”-skills för specifika teknikstackar.

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

K4: Projekt (organisation)

Skills specifika för vår organisation och våra arbetsflöden.

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

Fas 1: Upptäckt

Skills kommer från överallt:

Leverantörsrepositorier: AWS, Anthropic, Cloudflare, Supabase och communitybidragsgivare publicerar skill-samlingar. Vi bevakar 25+ leverantörsrötter.

Communityprojekt: GitHub är fullt av Claude Code-mallar, agentmönster och arbetsflödesdefinitioner.

Interna mönster: Allteftersom vårt team löser problem uppstår mönster. De formaliseras till skills.

Dokumentationsmining: Teknisk dokumentation innehåller ofta implicita skills — procedurer, checklistor, beslutsträd.

Upptäckten är kontinuerlig. Vi använder en skill-backlogg för att spåra kandidater innan formell utvärdering.

Fas 2: Utvärdering

Varje kandidat går igenom samma 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

Alla fem produktkriterier måste godkännas. Det är därför 87 % av kandidaterna avvisas.

Sedan går varje kandidat igenom en separat förtroendegranskning. Vi behandlar inte ett officiellt leverantörsrepositorium, en välkänd community-underhållare och ett slumpmässigt GitHub-repo som likvärdiga sanningskällor.

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

Betrodda leverantörer får en lättare proveniensgranskning, men inget frikort. Obetrodda eller okända källor får en djupare manuell granskning, och vi kör inte bifogade skript förrän de har lästs, avgränsats och klassificerats som säkra.

Luckanalys: Innan vi antar söker vi i vårt register:

uv run orkestra skills search "<capability>"

Har vi redan det behöver vi det inte. Har vi något liknande kanske vi slår ihop istället för att anta.

Djup- och standardpoängsättning: Vi poängsätter också hur fullt en kandidat använder agent-skill-modellen. En ensam SKILL.md kan fortfarande vara användbar, men djupare skills är mer värdefulla när de separerar instruktioner från referenser, skript och tillgångar på det sätt agentskills.io uppmuntrar.

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-stjärnor kan höja en trovärdighetspoäng lite, men de räddar aldrig en ytlig eller osäker skill. Ett repo med många stjärnor och en vag SKILL.md och opaka skript poängsätts lägre än ett mindre repo med en precis beskrivning, kuraterade references/, och atomära hjälpare som faktiskt utnyttjar hela skill-förmågan.

Strukturell analys: Vi kontrollerar 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

Om en kandidat innehåller skript blir den granskningen mer sträng. En bra skill är inte bara användbar; den måste vara läsbar, avgränsad och säker att lämna över till en agent. Det säkerhetsfiltret ensamt diskvalificerar en betydande andel av annars intressanta kandidater.

Fas 3: Intag

När en skill klarar utvärderingen kommer den in i registret. Men skills antas aldrig oförändrade. De modifieras för att passa vårt system.

Modifieringar vid antagande:

1. Metadatanormalisering: Varje skill får vårt frontmatter-schema
2. K-nivåtilldelning: Skills placeras i lämpligt kunskapslager
3. Taggberikning: Taggar läggs till för upptäckbarhet
4. Verktygsdeklaration: Tillåtna verktyg deklareras explicit
5. Sektionsjustering: Innehåll omstruktureras för att matcha vår mall

En typisk skill-YAML efter intag:

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

Fas 4: Scope-tilldelning

Skills tilldelas scopes — kategorier som avgör vilka agenter som laddar vilka 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 deklarerar sina scopes, och skills tilldelas automatiskt:

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

Fas 5: Materialisering

Skills lever inte som YAML i produktion. De renderas till SKILL.md-filer som Claude Code kan ladda:

uv run orkestra sync

Det här kommandot:

1. Läser alla skill-YAML-definitioner
2. Renderar dem genom Jinja-mallar
3. Skriver SKILL.md-filer till .claude/skills/
4. Organiserar efter K-nivå (foundations/, identities/, domains/, stacks/, project/)

Den slutgiltiga utdatastrukturen:

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

Det vilande scope-mönstret

Ett av våra kraftfullaste mönster är “antagen-men-inte-laddad”-skills. Vi kallar de här vilande scopes.

Betrakta skills för vetenskaplig databehandling från repositoriet k-dense-scientific. Vi har antagit 120+ skills som täcker bioinformatik, kemi, kvantdatorer och klinisk informatik. Men de flesta av våra agenter behöver inte molekylär docking eller genuttrycksanalys.

Istället för att ladda alla 120 skills i varje agent (vilket blåser upp kontextfönstren) gör vi så här:

1. Antar skills med ett specifikt scope (t.ex. bioinformatics)
2. Håller dem vilande — registrerade men inte laddade
3. Aktiverar dem bara när en agent deklarerar det scopet

# 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

Det här mönstret låter oss ha 466 skills i registret medan typiska agenter bara laddar 40–60 relevanta.

Skill-typer

Skills finns i tre kognitiva mönster:

Arbetsflöde

Ordnade procedursteg: “1. Gör X, 2. Sedan Y, 3. Slutligen Z”

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

Disciplin

Beteendemässiga skyddsräcken: “Alltid X”, “Aldrig Y”, “Föredra Z”

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

Checklista

Verifieringskriterier: “Bekräfta X”, “Verifiera Y”, “Kontrollera Z”

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

Kvalitetsgrindar

Varje skill måste klara validering innan den skeppas:

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

Beskrivningar måste vara 50–400 tecken med utlösarfraser (“Använd när…”, “När du behöver…”) så att Claude Code vet när de ska föreslås.

Vi validerar kontinuerligt:

uv run orkestra validate --show-warnings

Leverantörsekosystemet

Våra 373 leverantörsskills kommer från:

Leverantör	Skills	Domän
AWS Agent	19	Molntjänster
Anthropic	12	Dokumentgenerering
Cloudflare	8	Edge computing
Supabase	5	Databas
k-dense	100+	Vetenskaplig databehandling
silvainfm	4	Datavetenskap
Java Developer Kit	45+	Spring/Java
Vercel	1	Webbläsarautomation

Varje leverantörsrot deklareras 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örs symlänkas leverantörsskills in i .claude/skills/vendor/ med sitt leverantörsnamnrymd.

Vad vi har lärt oss

Selektivitet lönar sig. Det är frestande att anta allt som ser användbart ut. Men varje skill kostar tokens. Med i genomsnitt 2 834 tokens per skill gör uppsvällning ont snabbt. Vår antagandegrad på 13 % håller agenterna slimmade.

Struktur möjliggör upptäckt. K-nivåsystemet är inte bara organisation — det handlar om portabilitet. K0-skills kan återanvändas var som helst. K4-skills är avsiktligt projektspecifika. Den här tydligheten hjälper både människor och agenter att hitta det de behöver.

Vilande scopes skalar. Man kan anta hundratals skills utan att ladda dem alla. Scopes låter en bygga ett heltäckande register samtidigt som enskilda agenters kontextfönster hålls hanterbara.

Modifiering vid antagande är avgörande. Råa leverantörsskills passar sällan ens system rakt av. Intagsprocessen — att lägga till metadata, tilldela nivåer, berika taggar — gör att externa skills fungerar internt.

Mining är kontinuerligt. Siffran 3 500 fortsätter växa. Nya leverantörsrepon dyker upp. Communitymönster uppstår. Interna arbetsflöden befästs. Loopen stannar aldrig.

Vad som är näst

Vi arbetar på flera förbättringar:

1. Automatiserad luckdetektion: Larm när vanliga agentfel skulle kunna åtgärdas av en icke-antagen skill
2. Arbetsflöden för utfasning av skills: Formell process för att pensionera skills som ersatts eller inte används
3. Beroenden mellan skills: Explicit deklaration av skill-förutsättningar
4. Användningsanalys: Spåra vilka skills agenter faktiskt åberopar kontra bara laddar

Mining-loopen för skills är infrastruktur. Den är inte glamorös. Men det är den som gör att 41 agenter fungerar sammanhängande med 466 förmågor samtidigt som de håller sig inom kontextgränserna.

Det är historien om hur 3 500 blir 466. Inte genom att ignorera 3 000 — utan genom att utvärdera dem systematiskt och bara anta det som fungerar.

---

Vill du se skill-systemet i praktiken? Kolla in uv run orkestra skills list för att utforska vårt nuvarande register.