Skill Miner

Was macht Skill Miner?

Verwandle das Signal, das in vergangenen Coding-Agenten-Sitzungen verborgen liegt, in neue und bestehende „Agent Skills“. Eine Sitzung wird nur dann zu einem Skill, wenn sie dieses Tor passiert – wiederholbar UND (Verbesserungspotenzial ODER wiederholte Anfrage) :

1. Wiederholbar – die Aufgabe oder das Wissen wiederholt sich oder könnte es eindeutig. Bisherige Wiederholungen sind der stärkste Beleg, aber eine plausibel wiederkehrende Aufgabe zählt; eine echte Einmaligkeit niemals. (Erforderlich.)
2. Verbesserungspotenzial – es gibt bedeutendes Feedback, sodass das nächste Mal besser gelingt als das erste:
   • Umwelt-Feedback – was die Ausführung der Arbeit offenbart hat: Fehler, wiederkehrende Eigenheiten dieser Umgebung, umständliche Pfade und ihre Abkürzungen, mühsam erworbene Heuristiken. Dies sind buchstäblich Skills.
   • Benutzer-Feedback – der Benutzer ist der Experte und sein Feedback ist selten; nutze es, um sein Wissen zu extrahieren (eine Korrektur, einen besseren Weg, den er kannte, eine Tatsache, die wir falsch hatten).
3. Wiederholte Anfrage – der Benutzer fragt immer wieder nach demselben; extrahiere es einmal, damit er nicht erneut fragen muss.

Pipeline: Discover → Distill (günstiges LLM, pro Sitzung) → Group, Judge & Generate.

0. Voraussetzungen

Ein kleines LLM muss erreichbar sein. Überprüfe es zuerst:

python3 scripts/llm.py --check   # zeigt das Backend, das verwendet wird, oder wie man es aktiviert

Setze entweder OPENAI_API_KEY / GEMINI_API_KEY / OPENROUTER_API_KEY oder habe ein claude- / codex- / gemini-CLI im PATH. Überschreibe das Modell mit SKILL_MINER_MODEL, erzwinge ein Backend mit SKILL_MINER_LLM.

1–2. Führe die Pipeline aus (Scripts erledigen die schwere, günstige LLM-Arbeit)

Behalte dein Arbeitsverzeichnis als Startverzeichnis bei: alle Artefakte werden unter ./out abgelegt.

OUT=./out
python3 scripts/discover.py  --since 35 --out $OUT/inventory.jsonl       # Transkripte über Agenten hinweg finden
python3 scripts/extract.py   --inventory $OUT/inventory.jsonl --out $OUT/conversations.jsonl --workers 10

• discover.py durchläuft jeden Adapter in common.py:ADAPTERS (Claude Code, Codex, opencode; füge dort weitere hinzu) und behält Sitzungen der letzten --since Tage. Starte mit höchstens 100 Sitzungen, es sei denn, der Benutzer wünscht mehr. Füge --limit 15 zu extract.py hinzu, um schnell zu proben.
• extract.py parst jede Sitzung und gibt eine JSONL-Zeile aus: agent, session_id, path, main_dir, datetime, n_user_turns, topics[], tasks[], skills_used[], env_feedback[], user_feedback[]. main_dir ist der tiefste Ordner, in dem die meiste Arbeit stattfand (aus bearbeiteten / gelesenen / erwähnten Dateien), nicht das Start-CWD. topics sind der Umfang (normalerweise einer – dient gleichzeitig als Überschrift – für die Gruppierung). tasks, env_feedback und user_feedback sind kurze Arrays, die das günstige LLM aus den eigenen Worten des Benutzers kopiert (jedes [] für die typische Sitzung) – sie entsprechen den drei Dimensionen des Tors. Der günstige Aufruf sieht nur Benutzereingaben, daher ist env_feedback das, was der Benutzer über das, was lief, gesagt hat, nicht die rohe Tool-Ausgabe – überprüfe es in Schritt 4.

3. Gruppiere die Sitzungen

Lies conversations.jsonl – eine Zeile pro Sitzung. Bei ≤100 Zeilen passt die gesamte Datei in den Kontext, also lies sie. (Wenn du viele weitere abgebaut hast, überfliege mit jq/grep die Zeilen mit nicht-leerem env_feedback / user_feedback zuerst, dann lies die interessanten Ausschnitte.) Ignoriere Zeilen, deren topics <error> oder trivial/leer ist.

Gruppiere nach Aufgaben-Archetyp – der ART der Arbeit, nicht nur dem Verzeichnis (z.B. „CI-Deploy-Debugging“, „Settings-UI-Iteration“, „Abhängigkeits-Migration“) – um Dimension 1 (wiederholbar) zu beurteilen: welche Aufgaben wiederkehren oder eindeutig könnten. Sammle dann über die Zeilen hinweg die anderen beiden Dimensionen:

• Dimension 2 – env_feedback und user_feedback, die auf einen Weg hinweisen, eine Aufgabe beim nächsten Mal besser zu erledigen (führe zuerst mit Umwelt-Feedback). Eine einzige mühsam erworbene Lektion ist ein Leitfaden, selbst ohne eine Gruppierung darum.
• Dimension 3 – ein Detail, das in vielen Sitzungen in tasks wiederkehrt (der Benutzer fragt immer wieder nach demselben).

Lege einmalige Einrichtungsschritte und einzelne beiläufige Bemerkungen beiseite. Behalte kurze Notizen: benannte Gruppen, jeweils mit ihrer Sitzungsanzahl, dominantem main_dir(s), dem Feedback / den wiederholten Anfragen, die sie enthalten, und einigen Beispiel-paths, die als nächstes als Belege geöffnet werden können.

4. Beurteilen und Generieren

Lies references/quality-bar.md und wende dessen Tor an: wiederholbar UND (Feedback ODER wiederholte Anfrage).

1. Kennt die Landschaft. Überprüfe deine vorhandenen Skills darauf, was erweitert werden kann – insbesondere einen, dessen Feedback besagt, dass er zu kurz kam; wenn ein Kandidat ihn überschneidet, öffne diese SKILL.md und bearbeite sie direkt. Um Skill-Dateipfade zu finden:

   python3 scripts/skills_inventory.py
   

   Verwende es nur, um zu bearbeitende Dateien zu finden; dein Kontext bleibt die Quelle der Wahrheit für die Landschaft. Wenn sich ein Kandidat auf ein bestimmtes Repository konzentriert, überprüfe, welche Markdown-Dokumente dort bereits existieren (README.md, Design-Dokumente, Pläne); wenn das wiederkehrende Wissen eher in diese Dokumente als in einen Skill gehört, empfehle dies dem Benutzer in deinem Bericht.
2. Bestätige anhand der Transkripte. Öffne für jeden Leitfaden 1–3 Beispiel-Transkripte (das path-Feld), um zu bestätigen, dass das Signal echt ist, und um die Einzelheiten zu erfassen – die genaue Regel, den genauen Fehler und Workaround, den besseren Weg, den der Benutzer aufgezeigt hat, die wiederholte Anfrage. Lies die Worte des Benutzers um jede Korrektur herum und um [skill used: X]-Marker. Die kondensierten Zeilen zeigen nur Benutzereingaben, daher ist das Transkript der Ort, an dem du überprüfst, was die Umgebung tatsächlich getan hat. Unterscheide eine wiederkehrende Eigenheit (schreibe sie auf) von einer einmaligen Einrichtung (höchstens ein einzeiliger Stolperstein).
3. Entscheide, gegen das Tor. Ein Leitfaden wird nur dann zu einem Skill, wenn er wiederholbar ist UND entweder Verbesserungspotenzial (Feedback) oder eine wiederholte Anfrage aufweist. Die drei Dimensionen haben gleiches Gewicht – lasse eine mühsam erworbene Lektion nicht fallen, nur weil die Aufgabe einmal vorkam, wenn sie eindeutig wiederkehrt, und bringe keine wiederholbare Aufgabe heraus, die nichts zu verbessern und keine wiederholte Anfrage hat.
4. Generiere / modifiziere ≤ 5 Skills. Schreibe jeden als konkreten Inhalt: die Regel, den Auslöser, die Schritte/Befehle, die Eigenheit + Workaround – mit Dateipfaden relativ zum Repo-Root (src/pages/Run.tsx), niemals maschinenspezifische Absolutpfade (/home/<user>/…) aus einem Transkript kopiert. Wo es landet:
   • Erweiterung eines bestehenden Skills → bearbeite ihn direkt am Skill-Pfad. Forke oder kopiere ihn nicht.
   • Ein brandneuer Skill → schreibe ihn unter ~/.agents/skills/generated-skills/<name>/, bereitgestellt zur Überprüfung und Beförderung durch den Benutzer – lege neue Skills nicht direkt in ein aktives Home ab.
5. Bericht. Liste auf, was du erstellt/geändert hast, und für jedes, aus welcher(n) Dimension(en) es stammt. Gib für jeden bemerkenswerten abgelehnten Kandidaten in einer Zeile an, welche Dimension er verfehlt hat. Füge alle Repo-Dokumente hinzu, von denen du denkst, dass sie stattdessen oder zusätzlich zu den Skill-Änderungen aktualisiert werden sollten.

Erweiterung auf andere Agenten

Jeder Agent speichert Transkripte anders. Um einen neuen zu unterstützen (Gemini CLI, Cursor, …) füge ein (discover_fn, parse_fn)-Paar zu common.py:ADAPTERS hinzu, das den normalisierten Datensatz (_norm(...)) liefert. Der Rest der Pipeline bleibt unverändert. Cursor (sqlite state.vscdb) ist noch nicht angeschlossen – opencodes Adapter ist eine DB-unterstützte (SQLite) Vorlage, der man folgen kann.

Hinweise

• Schreibschutz über deine Transkripte; die einzigen Schreibvorgänge sind die --out-Artefakte und die Skills, die du zu generieren oder verbessern wählst – neue Skills landen bereitgestellt unter ~/.agents/skills/generated-skills/, Bearbeitungen erfolgen direkt am vorhandenen Skill.
• Sub-Agent-/Review-Threads (Claude Code Sidechains, Codex thread_source: subagent) werden herausgefiltert – nur echte Benutzersitzungen werden abgebaut.

Ergebnisse anzeigen

Eigenständig ausgeführt sind die Ergebnisse einfache Dateien: die Artefakte unter ./out und die Skills, die du geändert hast (direkt bearbeitet oder unter generated-skills/ bereitgestellt). Dieses Skill wird auch mit Skill Studio ausgeliefert, einer Desktop-App, in der der Benutzer den Lauf live beobachtet, jeden neuen Skill, der unter generated-skills/ bereitgestellt wird, als Vorgeschlagene Karte zur Annahme oder Ablehnung überprüft und direkte Bearbeitungen als git-verfolgte Änderungen sieht, die als Version gespeichert oder rückgängig gemacht werden können.