# Skill Mining: Von 3.500 Kandidaten zu 466 Fähigkeiten

Canonical source: https://maguyva.ai/de/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

> Wir haben 3.500 Skill-Kandidaten geprüft und 466 übernommen. Eine systematische Mining- und Ingestion-Loop für den Aufbau einer kohärenten KI-Agent-Skill-Bibliothek im großen Maßstab.

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

## 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 Agents 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 (Fachdisziplin)

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

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

Alle fünf Produktkriterien müssen erfüllt sein. 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.

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

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:

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

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

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

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

### Phase 4: Scope-Zuweisung

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

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

Agents deklarieren ihre Scopes, und Skills werden automatisch zugewiesen:

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

```bash
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 Agents brauchen weder molekulares Docking noch Genexpressionsanalyse.

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

1. Wir **übernehmen** die Skills mit einem spezifischen Scope (z. B. `bioinformatics`)
2. Wir halten sie **dormant** — registriert, aber nicht geladen
3. Wir **aktivieren** sie nur, wenn ein Agent diesen Scope deklariert

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

Dieses Muster erlaubt uns, 466 Skills in der Registry zu haben, während typische Agents 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“

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

### Verhaltensregeln

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

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

### Checkliste

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

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

## Qualitätsgates

Jeder Skill muss vor dem Ausliefern eine Validierung bestehen:

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

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:

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

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

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 Agents 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 Agents, 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 Agents ü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 Agents tatsächlich aufrufen versus nur laden

Die Skill-Mining-Loop ist Infrastruktur. Sie ist nicht glamourös. Aber sie ist das, was 41 Agents 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.*