skill-stocktake — Skill-Qualitätsaudit
Bewerte installierte Skills ganzheitlich, alles in einem Kontext, und weise jedem ein
Urteil zu: Keep / Improve / Update / Retire / Merge. Dieses Skill führt die Verbesserung NICHT selbst durch – sobald ein Urteil vorliegt, übergibt es an skill-creator (die Verbesserungsmaschine). Diese Grenzziehung ist der Kern: stocktake ist das Qualitätsgate, skill-creator der Beheber.
Designhinweis: Die alte Version rief externe Scan-Skripte auf und teilte die Bewertung in Batches von ~20 Skills pro Unteragent auf. Mit einem 1M-Kontext ist das nicht nur unnötig, sondern schädlich – Batch-Verarbeitung blendet jeden Unteragenten für Skills in anderen Batches, sodass übergreifende Überschneidungen übersehen werden. Jetzt nutzen wir Glob und lesen jeden Skill in einen einzigen Kontext. Die Erkennung von Überschneidungen hängt von dieser Ein-Kontext-Ansicht ab.
Modi ($ARGUMENTS)
| Argument | Verhalten |
|---|---|
keines / full | Alle Skills lesen und bewerten (Standard) |
changed | Nur Skills neu bewerten, deren SKILL.md-Änderungsdatum neuer ist als evaluated_at in results.json; die übrigen Urteile aus dem Ledger übernehmen |
changed erkennt Änderungen inline (kein Skript):
find ~/.claude/skills -name SKILL.md -newermt "$(jq -r .evaluated_at ~/.claude/skills/skill-stocktake/results.json)"
Phase 1 – Inventur
Ermittle die Skill-Definitionsdateien mit Glob (kein Skript nötig):
~/.claude/skills/*/SKILL.md~/.claude/skills/learned/*.md- Wenn das aktuelle Arbeitsverzeichnis
.claude/skills/enthält, zusätzlich{cwd}/.claude/skills/*/SKILL.md(Projekt-Skills)
Da Glob nur
SKILL.md/learned/*.mdanvisiert, werden Abhängigkeits-Markdown-Dateien unter.venvoder.pytest_cachestrukturell ausgeschlossen (kein manuelles Aussortieren nötig). Das Rauschen, das das altefind -name "*.md"hereingezogen hat, kann nicht auftreten.
Nutzungszahlen: Lese ~/.claude/metrics/skill-usage.jsonl inline (der PostToolUse-Hook
log-skill-usage.sh hängt Daten an – eine unabhängige Messebene) und zähle Pro-Skill-Ereignisse
über 7 / 30 / 90 Tage. Jede Zeile ist ein JSON {ts,event,skill,path,project}; zähle sowohl
invoke- als auch read-Ereignisse. Aggregiere mit einem Einzeiler (python3/jq), anstatt
manuell zu zählen – das Log wächst mit der Zeit und manuelles Zählen verschwendet einen
Tool-Aufruf pro Ausführung.
- Wenn das Log fehlt oder das erste Ereignis jünger als 90 Tage ist, zeige die Nutzung als
—(nicht gemessen) an. Zeige es niemals als 0 – „nicht gemessen" und „ungennutzt" sind unterschiedliche Fakten.
Gib das Scan-Ergebnis zu Beginn aus: welche Pfade durchsucht wurden, wie viele Skills gefunden wurden und ob die Nutzung messbar ist.
Phase 2 – Bewertung (vollständig inline, ganzheitlich)
Lese den Inhalt jedes Ziel-Skills und bewerte sie einzeln, während das gesamte Set sichtbar bleibt. Checkliste:
- Inhaltliche Überschneidungen mit anderen Skills (ein dokumentierter Orchestrator/Sub-Skill-Aufteilung ist KEINE Überschneidung – z. B. paper-ecosystem → seine Reviewer, citation-sync → release-doi/wikidata. Unterscheide beabsichtigte Schichtung von echter Duplizierung.)
- Überschneidungen mit MEMORY.md / CLAUDE.md / Regeln
- Aktualität technischer Referenzen (wenn CLI-Flags / APIs / Tool-Namen veraltet wirken, mit WebSearch bestätigen)
- Nutzungshäufigkeit (ignoriere das Signal, wenn nicht gemessen)
Die Bewertung ist ganzheitliches Urteil, keine numerische Rubrik. Leitende Dimensionen: Handlungsorientierung (konkrete Beispiele/Schritte, die man umsetzen kann), Umfangspassung (Name, Trigger und Inhalt stimmen überein – nicht zu breit oder zu eng), Einzigartigkeit (nicht durch MEMORY / einen anderen Skill ersetzbar), Aktualität (Referenzen funktionieren in der aktuellen Umgebung).
Aggregierte Kosten (Set-Ebene, nicht pro Skill): Einen Skill zu halten ist nicht kostenlos, selbst wenn der einzelne Skill in Ordnung ist. Skill-Vorteile sind fragil – eine große, ungepflegte Bibliothek verschlechtert die Fähigkeit des Agenten, den richtigen Skill auszuwählen, und zieht das Verhalten wieder in Richtung des „Kein-Skill"-Baseline. Daher steigt die Keep-Hürde mit der Bibliotheksgröße: Wenn das Set groß ist, ist ein bloß ausreichender Skill (seltene Nutzung, geringe Einzigartigkeit, starke Nähe zu anderen) allein aufgrund der aggregierten Verdünnung ein Retire/Merge-Kandidat – unabhängig von Mängeln im Skill selbst. Dies ist ein Urteilsinput, niemals eine Quote; nicht ausmustern, um eine Zahl zu erreichen.
| Urteil | Bedeutung |
|---|---|
| Keep | Nützlich, aktuell, einzigartiger Wert |
| Improve | Erhaltenswert, aber spezifische Verbesserungen nötig |
| Update | Referenzierte Technologie ist veraltet (mit WebSearch bestätigen) |
| Retire | Geringe Qualität, veraltet oder kostenasymmetrisch |
| Merge in [X] | Wesentliche Überschneidung mit einem anderen Skill; das Ziel benennen |
Null-Nutzungs-Regel: Wenn das erste Ereignis im Nutzungslog mindestens 90 Tage alt ist UND ein
Skill use_90d == 0 aufweist, MUSS er als Retire-Kandidat genannt werden (die endgültige Entscheidung
trifft der Benutzer). Solange das Log jünger als 90 Tage ist, greift diese Regel nicht, und die Urteile
basieren allein auf dem ganzheitlichen Urteil.
Die Bewertung ist ursprungsblind: keine Unterscheidung zwischen ECC / selbst erstellt / automatisch extrahiert. Dieselbe Checkliste gilt für jeden Skill.
Phase 3 – Zusammenfassung
Erstelle eine Tabelle: Skill | 7d | 90d | Urteil | Begründung.
Phase 4 – Konsolidierung
- Retire / Merge: Pro Datei präsentiere (1) den spezifischen gefundenen Mangel, (2) was stattdessen das gleiche Bedürfnis abdeckt (Retire: welcher bestehende Skill/welche Regel; Merge: das Ziel und welcher Inhalt integriert werden soll), (3) die Auswirkungen der Entfernung (abhängige Skills, MEMORY-Referenzen). Handle erst nach Bestätigung durch den Benutzer.
- Improve / Update: Biete an, zu übergeben – „Skill
<name>an skill-creator zur Verbesserung übergeben?" – und rufe bei Zustimmungskill-creatormit dem Ziel-Skill auf. Stocktake führt niemals selbst Verbesserungsarbeiten durch. - Aktualisiere das Ledger: Lese
results.json→ füge die Urteile dieses Durchlaufs ein → schreibe es zurück (evaluated_at= echte UTC vondate -u +%Y-%m-%dT%H:%M:%SZ). Imchanged-Modus behalte die bisherigen Urteile von Skills bei, die du nicht neu bewertet hast. - Wenn MEMORY.md mehr als 100 Zeilen hat, schlage eine Komprimierung vor.
Begründungsqualität (erforderlich)
Jede begründung muss in sich geschlossen sein – die Entscheidung alleinstehend ermöglichen.
„Unverändert" allein ist verboten; wiederhole stets die Belege.
- Retire: Nenne den Mangel + den Ersatz. Schlecht:
"Überholt"/ Gut:"disable-model-invocation: true bereits gesetzt; continuous-learning-v2 deckt die gleichen Muster plus Konfidenzbewertung ab. Kein einzigartiger Inhalt verbleibt." - Merge: Nenne das Ziel + was integriert werden soll. Schlecht:
"Überschneidet sich mit X"/ Gut:"42 Zeilen dünner Inhalt; Schritt 4 von chatlog-to-article deckt diesen Workflow bereits ab. Integriere den Tipp zum 'Artikelwinkel' dort als Anmerkung." - Improve: Welcher Abschnitt, welche Änderung (ggf. Zielgröße). Schlecht:
"Zu lang"/ Gut:"276 Zeilen; 'Framework-Vergleich' (Z80–140) dupliziert ai-era-architecture-principles. Lösche es, um ~150 Zeilen zu erreichen." - Keep (nur mtime-Änderung im
changed-Modus): Wiederhole die ursprüngliche Begründung. Schlecht:"Unverändert"/ Gut:"Inhalt unverändert. Einzigartige Python-Referenz, die explizit von rules/python/ importiert wird; keine Überschneidung."
results.json (schlankes Ledger)
{
"evaluated_at": "2026-06-24T11:09:00Z",
"skills": {
"<skill-name>": {
"path": "~/.claude/skills/<name>/SKILL.md",
"verdict": "Keep",
"reason": "...",
"mtime": "2026-01-15T08:30:00Z"
}
}
}
Ein Ledger nur für Urteilsverlauf und Zeitstempel der letzten Prüfung. Aktualisiere es inline mit Read/Write, nicht mit einem Skript. Nur globale Skills (Projekt-Skills werden frisch aus dem aktuellen Verzeichnis gelesen, hier nicht zwischengespeichert).
Verwandte Skills
skill-creator– die Verbesserungsmaschine; übergib Improve/Update-Arbeiten an sie.config-gc– GC über Skill-Existenz und das gesamte ~/.claude (Hooks/Berechtigungen/MCP/Cache); stocktake bewertet Skill-Qualität.harness-sync– verwende es, um dieses Skill mit seinem öffentlichen Repository zu synchronisieren.- Nutzungsmessung:
~/.claude/hooks/log-skill-usage.sh→~/.claude/metrics/skill-usage.jsonl(eine von stocktake unabhängige Messebene).