Skill Mining: Von 3.500 Kandidaten zu 466 Capabilities

Die Zahlen in diesem Beitrag spiegeln den Stand des Systems zum Veröffentlichungszeitpunkt (Januar 2026) wider. Aktuelle Zahlen findest du auf unserer Team-Seite.

Das 3.500-Skill-Problem

Als wir angefangen haben, ein Agent-Orchestrierungssystem zu bauen, standen wir vor einer interessanten Herausforderung: Es gibt Tausende potenzielle Skills, verstreut über das gesamte KI-Ökosystem. GitHub-Repositories, Vendor-Dokumentation, Community-Projekte, interne Muster — Skills existieren überall. Aber welche zählen? Welche funktionieren? Und wie pflegst du eine kohärente Skill-Bibliothek, die Agenten tatsächlich nutzen können?

Unsere Antwort: eine systematische Mining- und Ingestion-Loop.

Die Zahlen heute

Etwas mehr als drei Monate nachdem Anthropic am 16. Oktober 2025 Agent Skills gestartet hat, sah unser Stand am Veröffentlichungsdatum dieses Beitrags, dem 27. Januar 2026, so aus:

Metrik	Anzahl
Identifizierte Kandidaten	3.500+
Übernommene Skills	466
Vendor-Skills	373
Interne Skills	93
Aktive Vendors	25+
Durchschnittliche Tokens pro Skill	2.834
Referenzierte Tools	89
Eindeutige Tags	635

Wir haben über 3.500 Skill-Kandidaten geprüft. Wir haben 466 übernommen. Das ist eine Übernahmequote von 13 % — und diese Selektivität ist Absicht.

Das Knowledge-Tier-System

Nicht alle Skills sind gleich. Wir organisieren sie in fünf Wissensschichten (K0–K4), jede repräsentiert einen anderen Geltungsbereich der Anwendbarkeit:

K0: Foundations (Universell)

Skills, die jeder Agent haben sollte. Diese repräsentieren „guter Denker“-Fähigkeiten, die überall funktionieren.

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 sind auf jedes Projekt, jede Domäne, jeden Stack portabel. Sie kodieren universelle kognitive Muster.

K1: Identities (Disziplin)

„Guter Engineer“- oder „guter Researcher“-Skills, die über Projekte hinweg innerhalb einer Disziplin gelten.

identities/
├── research-workflows          # Multi-source research
├── web-extraction-playbook     # Content extraction
├── code-review                 # PR review patterns
└── cli-interface-standards     # CLI design patterns

K2: Domains (Fachexpertise)

„Guter Datenbankexperte“- oder „guter Security-Engineer“-Skills, portabel innerhalb eines Fachbereichs.

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 (Technologie)

„Guter Supabase-Nutzer“- oder „guter Cloudflare-Entwickler“-Skills für bestimmte Technologie-Stacks.

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

K4: Project (Organisation)

Skills, die spezifisch für unsere Organisation und unsere Workflows sind.

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

Die Mining-Loop

Phase 1: Entdeckung

Skills kommen von überall her:

Vendor-Repositories: AWS, Anthropic, Cloudflare, Supabase und Community-Contributor veröffentlichen Skill-Sammlungen. Wir verfolgen 25+ Vendor-Roots.

Community-Projekte: GitHub ist voll von Claude-Code-Templates, Agent-Mustern und Workflow-Definitionen.

Interne Muster: Während unser Team Probleme löst, entstehen Muster. Diese werden zu Skills formalisiert.

Dokumentations-Mining: Technische Dokumentation enthält oft implizite Skills — Prozeduren, Checklisten, Entscheidungsbäume.

Entdeckung ist kontinuierlich. Wir nutzen einen Skill-Backlog, um Kandidaten vor der formalen Bewertung zu verfolgen.

Phase 2: Bewertung

Jeder Kandidat durchläuft dieselbe 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 fünf Produktkriterien müssen bestehen. Deshalb werden 87 % der Kandidaten abgelehnt.

Dann durchläuft jeder Kandidat ein separates Trust-Review. Wir behandeln ein offizielles Vendor-Repository, einen bekannten Community-Maintainer und ein zufälliges GitHub-Repo nicht als gleichwertige Quellen der Wahrheit.

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

Vertrauenswürdige Vendors bekommen ein leichteres Provenienz-Review, aber keinen Freifahrtschein. Nicht vertrauenswürdige oder unbekannte Quellen bekommen ein tieferes manuelles Audit, und wir führen keine gebündelten Skripte aus, bevor sie gelesen, eingegrenzt und als sicher klassifiziert wurden.

Gap-Analyse: Vor der Übernahme durchsuchen wir unsere Registry:

uv run orkestra skills search "<capability>"

Wenn wir es schon haben, brauchen wir es nicht. Wenn wir etwas Ähnliches haben, mergen wir vielleicht, statt zu übernehmen.

Tiefen- und Standards-Scoring: Wir bewerten auch, wie vollständig ein Kandidat das Agent-Skill-Modell nutzt. Ein einsames SKILL.md kann trotzdem nützlich sein, aber tiefere Skills sind wertvoller, wenn sie Anweisungen von Referenzen, Skripten und Assets trennen, so wie agentskills.io es fördert.

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-Sterne können einen Glaubwürdigkeits-Score etwas anheben, aber sie retten nie einen flachen oder unsicheren Skill. Ein Repo mit vielen Sternen und einem vagen SKILL.md sowie undurchsichtigen Skripten schneidet schlechter ab als ein kleineres Repo mit präziser Beschreibung, kuratierten references/ und atomaren Helpern, die die volle Skill-Capability tatsächlich nutzen.

Strukturelle Analyse: Wir prüfen die Skill-Qualität:

wc -l vendor/<repo>/<skill>/SKILL.md  # Size check
ls vendor/<repo>/<skill>/scripts/     # Supporting files
ls vendor/<repo>/<skill>/references/  # Bundled docs

Wenn ein Kandidat Skripte enthält, wird dieses Review strenger. Ein guter Skill ist nicht nur nützlich; er muss lesbar, abgegrenzt und sicher genug sein, um ihn einem Agent zu übergeben. Allein dieser Sicherheitsfilter disqualifiziert einen bedeutenden Teil ansonsten interessanter Kandidaten.

Phase 3: Einlesung

Wenn ein Skill die Bewertung besteht, kommt er in die Registry. Aber Skills werden nie unverändert übernommen. Sie werden angepasst, um in unser System zu passen.

Modifikationen bei der Übernahme:

1. Metadaten-Normalisierung: Jeder Skill bekommt unser Frontmatter-Schema
2. K-Tier-Zuweisung: Skills werden der passenden Wissensschicht zugeordnet
3. Tag-Anreicherung: Tags werden für die Auffindbarkeit hinzugefügt
4. Tool-Deklaration: Erlaubte Tools werden explizit deklariert
5. Abschnitts-Angleichung: Inhalt wird umstrukturiert, um zu unserem Template zu passen

Eine typische Skill-YAML nach der Ingestion:

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

Phase 4: Scope-Zuweisung

Skills werden Scopes zugewiesen — Kategorien, die bestimmen, welche Agenten welche Skills laden:

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

Agenten deklarieren ihre Scopes, und Skills werden automatisch zugewiesen:

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

Phase 5: Materialisierung

Skills leben nicht als YAML in Produktion. Sie werden in SKILL.md-Dateien gerendert, die Claude Code laden kann:

uv run orkestra sync

Dieser Befehl:

1. Liest alle Skill-YAML-Definitionen
2. Rendert sie durch Jinja-Templates
3. Schreibt SKILL.md-Dateien nach .claude/skills/
4. Organisiert nach K-Tier (foundations/, identities/, domains/, stacks/, project/)

Die finale Ausgabestruktur:

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

Das Dormant-Scope-Muster

Eines unserer mächtigsten Muster sind „übernommen, aber nicht geladen“-Skills. Wir nennen diese Dormant Scopes.

Betrachte Scientific-Computing-Skills aus dem k-dense-scientific-Repository. Wir haben 120+ Skills übernommen, die Bioinformatik, Chemie, Quantencomputing und klinische Informatik abdecken. Aber die meisten unserer Agenten brauchen kein molekulares Docking oder Genexpressionsanalyse.

Statt alle 120 Skills in jeden Agenten zu laden (was die Kontextfenster aufbläht), tun wir Folgendes:

1. Übernehmen wir die Skills mit einem spezifischen Scope (z. B. bioinformatics)
2. Halten wir sie dormant — registriert, aber nicht geladen
3. Aktivieren wir sie nur, wenn ein Agent diesen Scope deklariert

# 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

Dieses Muster erlaubt uns, 466 Skills in der Registry zu haben, während typische Agenten nur 40–60 relevante laden.

Skill-Typen

Skills kommen in drei kognitiven Mustern:

Workflow

Geordnete prozedurale Schritte: „1. Mach X, 2. Dann Y, 3. Schließlich Z“

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

Discipline

Verhaltens-Leitplanken: „Immer X“, „Nie Y“, „Bevorzuge Z“

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

Checklist

Verifikationskriterien: „Bestätige X“, „Verifiziere Y“, „Prüfe Z“

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

Qualitätsgates

Jeder Skill muss vor dem Ausliefern eine Validierung bestehen:

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

Beschreibungen müssen 50–400 Zeichen mit Auslösephrasen sein („Verwenden, wenn…“, „Wenn du… brauchst”), damit Claude Code weiß, wann sie vorgeschlagen werden sollen.

Wir validieren kontinuierlich:

uv run orkestra validate --show-warnings

Das Vendor-Ökosystem

Unsere 373 Vendor-Skills kommen von:

Anbieter	Skills	Domäne
AWS Agent	19	Cloud-Services
Anthropic	12	Dokumentengenerierung
Cloudflare	8	Edge-Infrastruktur
Supabase	5	Datenbank
k-dense	100+	Wissenschaftliches Computing
silvainfm	4	Datenwissenschaft
Java Developer Kit	45+	Spring/Java
Vercel	1	Browser-Automatisierung

Jede Vendor-Root wird in metadata.yaml deklariert:

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

Wenn orkestra sync läuft, werden Vendor-Skills mit ihrem Provider-Namespace nach .claude/skills/vendor/ symlinkt.

Was wir gelernt haben

Selektivität zahlt sich aus. Es ist verlockend, alles zu übernehmen, was nützlich aussieht. Aber jeder Skill kostet Tokens. Bei 2.834 durchschnittlichen Tokens pro Skill schadet Aufblähung schnell. Unsere Übernahmequote von 13 % hält Agenten schlank.

Struktur ermöglicht Auffindbarkeit. Das K-Tier-System ist nicht nur Organisation — es geht um Portabilität. K0-Skills können überall wiederverwendet werden. K4-Skills sind absichtlich projektspezifisch. Diese Klarheit hilft sowohl Menschen als auch Agenten, zu finden, was sie brauchen.

Dormant Scopes skalieren. Du kannst Hunderte von Skills übernehmen, ohne sie alle zu laden. Scopes lassen dich eine umfassende Registry aufbauen, während die Kontextfenster einzelner Agenten überschaubar bleiben.

Modifikation bei der Übernahme ist essenziell. Rohe Vendor-Skills passen selten zu deinem System. Der Ingestion-Prozess — Metadaten hinzufügen, Tiers zuweisen, Tags anreichern — macht externe Skills intern nutzbar.

Mining ist kontinuierlich. Die Zahl 3.500 wächst weiter. Neue Vendor-Repos tauchen auf. Community-Muster entstehen. Interne Workflows verfestigen sich. Die Loop hört nie auf.

Was als Nächstes kommt

Wir arbeiten an mehreren Verbesserungen:

1. Automatisierte Gap-Erkennung: Alarm, wenn häufige Agent-Fehler durch einen nicht übernommenen Skill adressiert werden könnten
2. Skill-Ausmusterungsprozesse: Formaler Prozess für das Ausmustern von Skills, die abgelöst oder ungenutzt sind
3. Cross-Skill-Abhängigkeiten: Explizite Deklaration von Skill-Voraussetzungen
4. Nutzungs-Analytik: Verfolgen, welche Skills Agenten tatsächlich aufrufen versus nur laden

Die Skill-Mining-Loop ist Infrastruktur. Sie ist nicht glamourös. Aber sie ist das, was 41 Agenten erlaubt, kohärent mit 466 Capabilities zu funktionieren, während sie innerhalb der Kontextgrenzen bleiben.

Das ist die Geschichte, wie aus 3.500 466 werden. Nicht, indem man 3.000 ignoriert — indem man sie systematisch bewertet und nur übernimmt, was funktioniert.

---

Willst du das Skill-System in Aktion sehen? Schau dir uv run orkestra skills list an, um unsere aktuelle Registry zu erkunden.