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

Canonical source: https://maguyva.ai/sv/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 granskade 3 500 skill-kandidater och antog 466. En systematisk mining- och intagsloop för att bygga ett sammanhängande skill-bibliotek för AI-agenter i stor skala.

> *Siffrorna i det här inlägget speglar systemet vid publiceringen (januari 2026). Se vår [teamsida](/sv/team) för aktuella siffror.*

## 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åg det ut så här 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), där vart och ett har ett eget tillämpningsområde:

### 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 bedöms enligt samma 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
```

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.

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

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:

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

```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-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 små, avgränsade hjälpskript som faktiskt utnyttjar hela skill-förmågan.

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

Om en kandidat innehåller skript blir den granskningen strängare. 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:

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

### Fas 4: Scope-tilldelning

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

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

```bash
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, kvantberäkning 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

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

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"

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

### Disciplin

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

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

### Checklista

Verifieringskriterier: "Bekräfta X", "Verifiera Y", "Kontrollera Z"

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

## Kvalitetsgrindar

Varje skill måste klara validering innan den skeppas:

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

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:

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

```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/` under sin leverantörs namnrymd.

## 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 blir onödig volym snabbt kostsam. 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 kommer härnä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.*