Zhr65/SkillFresh

Skill Auditor — Fähigkeitsverlust und Passungsbewertung für Agenten

Überblick

Ein Skill ist ein abwertendes Asset. Modellversionen erscheinen alle paar Monate. Ein Skill, der letztes Quartal bestanden hat, kann leise zurückgehen – falsche Ausgabeform, kaputte Tool-Aufrufe, verpasste Trigger – und niemand sagt dem Nutzer, dass sein Agent dümmer geworden ist.

Dieser Skill ist die Evaluierungsmethodik. Er beantwortet drei Fragen:

1. Verschlechtert sich ein Skill? – Fähigkeitsregression über Modellversionen.
2. Ist ein neuer Skill tatsächlich gut? – Effektivität vs. Kosten.
3. Passt ein Skill zu DIESEM Nutzer? – Trigger-Genauigkeit + Umgebung + Stil.

Er enthält fünf ausführbare Einstiegspunkte:

• scripts/console.py – die residente Konsole (Datenebene): verwaltet registry.<host>.json pro Host, erkennt Änderungen der Modellversion (bump/check) und zeigt das Empfehlungs-/Entfernungs-Panel an. Siehe USAGE.md für den vollständigen Befehlssatz.
• scripts/regress.py – berechnet bei gegebenen Wiederholungsergebnissen des Gold-Standards die Durchfallquoten-Matrix, kennzeichnet Abbau (Schwellwert + Richtung) und zeigt FINGERPRINT-DRIFT an, wenn ein Asset stattdessen bearbeitet wurde.
• scripts/baseline.py – erstellt eine Wiederholungs-Checkliste und führt die aufgezeichneten Urteile in baseline-results.json zusammen (nach Asset; --replace für eine vollständige Überschreibung). Entwurf-Gold-Fälle werden übersprungen, es sei denn, --allow-draft wird verwendet.
• scripts/fingerprint.py – eigenständiges Berichts-CLI; ein dünner Wrapper um denselben Hash-Code wie scan. Schreibt nur fingerprint-report.*; es schreibt nicht das Registry.
• scripts/install.py – installiert diesen Skill in jeden Agent-Host auf der Maschine (~/.workbuddy-ai/skills, ~/.claude/skills, ~/.agents/skills, ~/.dsh/skills, ~/.codex/skills). Überprüft nach der Installation; hinterlässt niemals ein leeres Verzeichnis; kopiert niemals persönliche Daten.

Kernprinzip: Keine Messung ohne Baseline. Abbau = signifikanter Durchfallquoten-Abfall unter einem unveränderten Fingerabdruck – niemals 'fühlt sich dümmer an'.

Multi-Host-Architektur (Skills vs. Plugins)

Eine Kernengine, Adapter pro Host. Dieselbe Logik für Fingerabdruck / Baseline / Regression / Empfehlung / Bedarfsvorschlag läuft überall; ein Adapter weiß nur, wo Assets leben und wie man ihr Manifest liest.

Host	Art	Standard-Root	Manifest
workbuddy	Skill	Skills-Root, das diesen Skill enthält	SKILL.md
claude-code	Skill	~/.claude/skills	SKILL.md
deepseek	Plugin	~/.dsh/profiles/desktop (liest package.json-Abhängigkeiten)	package.json / plugin.json
generisch	Asset	--root übergeben	plugin.json / manifest.json / SKILL.md / package.json

• Jeder Host hat sein eigenes Registry: registry.<host>.json – kein hostsübergreifendes Überschreiben.
• Baseline-Ergebnisse + Gold-Standard-Sets werden gemeinsam genutzt, nach Asset-Namen.
• Ausführen mit --host <name> --root <pfad>; benutzerdefinierte Hosts in hosts.json hinzufügen.
• console.py hosts zeigt jedes Profil, seinen aufgelösten Root und die erkannte Asset-Anzahl.

In WorkBuddy bewerten Sie also Skills; im DeepSeek Harness bewerten Sie Plugins – gleiche Befehle, anderer Adapter. Ein neuer Host erfordert einen Eintrag in hosts.json (Art + Root + Manifest-Dateinamen), keine Codeänderung.

Wann zu verwenden

• Vor der Bereitstellung eines neuen Skills oder Plugins ("Einen Skill erstellen und den Bewertungsprozess durchlaufen").
• Nach einer Modellversionserhöhung, um zu prüfen, ob vorhandene Skills zurückgegangen sind.
• Wenn ein Skill "sich komisch anfühlt" – mit Daten bestätigen, nicht mit Bauchgefühl.
• Bei der Entscheidung, ob ein Skill behalten / umgeschrieben / stillgelegt werden soll.
• Bei der Empfehlung eines Skills oder Plugins für einen Nutzer (Passung + Evidenz).

Wann NICHT zu verwenden: einmalige Aufgaben ohne wiederverwendbaren Skill; rein narrative Dokumente.

Kernkonzept: Der Versions-Fingerabdruck

Der Fingerabdruck ist die Zeile der Wertminderungsmatrix.

fingerprint = hash(Inhalt der Fähigkeitsoberfläche + relativer Pfad)        # Maß v2-faehigkeitsoberflaeche

Was zählt zur Fähigkeitsoberfläche (Dateien, deren Änderung tatsächlich das Verhalten ändert):

• eingeschlossen: SKILL.md, scripts/*, lib/*, dist/*, package.json, plugin.json, cordis.patch.yml, Vorlagen
• ausgeschlossen: README*, CHANGELOG*, LICENSE*, Bilder/Audio/Schriftarten, *.map, Sperrdateien, node_modules/, test*/, docs/

Warum ausschließen: Eine README-Bearbeitung ändert nicht die Fähigkeit, aber das Hashen verschiebt den Fingerabdruck und erzeugt einen falschen FINGERPRINT-DRIFT ("Das Asset wurde bearbeitet"), wenn sich nichts Funktionales geändert hat. Plugins machen dies schlimmer – ein installiertes Plugin kann 16 MB gebündelte Ausgabe plus eine 57 KB README mitbringen.

Regeln:

• Fingerabdruck unverändert ⇒ die Zeile bleibt bestehen; ein Durchfallquoten-Abfall ist eine Modellregression.
• Fingerabdruck geändert ⇒ die Änderung liegt in der Verantwortung des Skills, nicht des Modells. Alte und neue Zeilen koexistieren, sodass Skill-Bearbeitungen nie fälschlicherweise der Modellverschiebung zugeschrieben werden.

Führen Sie python scripts/console.py scan aus, um Fingerabdrücke zu berechnen und im Registry zu speichern. fingerprint.py ist ein eigenständiger Berichts-Wrapper; es berührt das Registry nicht.

Fähigkeitsoberfläche (warum Plugins eine zweite Achse benötigen)

Der Fingerabdruck sagt "haben sich die Dateien geändert?". Er kann nicht sagen "bietet es immer noch dasselbe an?". scan zeichnet daher auch eine Fähigkeitsoberfläche pro Asset auf und vergleicht sie mit dem vorherigen Scan:

Asset-Art	Was die Oberfläche aufzeichnet
Plugin	patch (dsh.bundle.patch), main/module, bin, exports, deps, skills, mcp, hooks, insert (cordis-Zeilen), scripts
Skill	tools (Anzahl der erlaubten Tools), scripts

Wenn sie sich ändert, gibt scan dies explizit aus:

[caps] 1 Asset hat eine geänderte Fähigkeitsoberfläche (das bedeutet 'was es extern bietet, hat sich geändert', unabhängig von der Durchfallquote):
       plug-a                                   +bin

Warum das für Plugins wichtig ist: Ein Plugin verschlechtert sich, indem es seine Tools nicht registriert / seine Routen 404 zurückgibt / seine Hooks nicht ausführt – nicht durch "schlechtere Antworten". Ein Gold-Standard-Set von Aufforderungen misst bei einem Plugin das Falsche. Das Oberflächen-Diff erfasst "v1.1.0 hat einen Einstiegspunkt fallen gelassen", ohne dass der Host gestartet werden muss.

Bekannte Einschränkung (nicht übertünchen): Die Oberfläche ist deklarierte Fähigkeit, nicht beobachtete Fähigkeit. Bei einem Plugin, dessen Manifest lügt (deklariert einen Patch, der nicht geladen werden kann), kann dies nicht erfasst werden.

Laufzeitevidenz (die dritte Achse und was sie nicht kann)

Es gibt zwei sehr unterschiedliche Dinge, die "Laufzeitsonde" genannt werden. Verwechseln Sie sie nicht:

	Aktive Sonde	Passive Evidenz – implementiert
was sie tut	Host starten, fragen "welche Tools hast du tatsächlich registriert"	das Log lesen, das der Host bereits schreibt
Kosten	DSH desktop-Profil ist Electron-exklusiv – dsh --profile desktop --dump-config wird verweigert; kein Headless-Einstieg → IPC rückentwickeln oder UI steuern	ein Dateilesevorgang, ~10 ms
erfasst	alles, einschließlich eines Plugins, dessen Manifest lügt	alles, was das Plugin geloggt hat
Status	nicht gebaut	console.py probe / skill_audit_probe

probe liest ~/.dsh/logs/*.log (konfigurierbar pro Host über "logs" in hosts.json), parst <iso> [level] [source] message, ordnet Zeilen zu, deren source einem installierten Asset-Namen entspricht, und markiert Zeilen, die Fehlervokabular enthalten (fail|error|ENOENT|unavailable|timeout|…).

Echter Fang auf dieser Maschine:

@wxg-prc-cpg/browser-skill-dsh-plugin   2 Fehleranzeichen
  bsk probe failed (spawn bsk ENOENT); Browser-Tools melden Installationsanleitung...

Dateien vorhanden, Manifest gültig, caps=4 – jeder statische Check besteht. Das Plugin wird geladen und seine Tools sind registriert, aber sie können nicht funktionieren: Das bsk-CLI, das es aufruft, ist nicht im PATH. Keine Menge Datei-Hashing findet dies.

Blinde Flecken (benennen, niemals verstecken): Ein Plugin, das nichts loggt, ist unsichtbar; Log-Rotation löscht alte Fehler; ein Plugin, das niemand verwendet hat, hat keine Evidenz; Fehler auf info-Ebene werden durch Schlüsselwortabgleich erfasst, daher sind sowohl Fehltreffer als auch falsch Positive möglich. Fehlende Evidenz ist keine Evidenz für Gesundheit – probe gibt diesen Satz selbst aus, anstatt einen grünen Haken zu setzen.

Implementiert vs. Nur-Methodik (diese Grenze nicht verwischen)

Die folgende Methodik ist umfassender als der Code. Nutzer sollten wissen, welche Hälfte sie in der Hand halten:

Bereich	Status
Fingerabdruck über die Fähigkeitsoberfläche, scan/status, Fähigkeits-Diff	implementiert
Gold-Standard-Gerüst + Baseline-Import (Zusammenführung nach Asset, Entwurfssperre)	implementiert (baseline.py)
Durchfallquoten-Matrix, ≥20pp-Schwellwert + Richtung, FINGERPRINT-DRIFT	implementiert (regress.py)
Modelländerungserkennung (bump/check), Host-spezifische Stempel	implementiert – aber die Ereignisquelle ist manuell; ein geplanter check bleibt grün, bis jemand erhöht
Empfehlungs-/Entfernungs-Panel, Bedarfsvorschlag, aus Verlauf abgeleitete Entwürfe	implementiert (heuristisch; Vorschläge sind keine Evidenz)
Laufzeitevidenz aus Host-Logs	implementiert (passiv; nur was das Plugin geloggt hat)
Ablation, Schattenmodus-Adoptionsrate, Nettonutzen / Token-Telemetrie	nur Methodik – kein Code
Trigger-Präzision/Recall, Umgebungsabgleich, Stil-Baseline	nur Methodik – kein Code
K≥3 Wiederholungen, LLM-Judge-Kreuzvalidierung	nicht implementiert; aktuelle Urteile sind K=1 Selbsteinschätzung
risk-Spalte	Stellvertreter für Wartungsoberfläche – nicht Nutzen

Wenn eine Behauptung in dieser Datei nicht auf eine als "implementiert" markierte Zeile zurückgeführt werden kann, behandeln Sie sie als Ratschlag für den Menschen, der die Prüfung durchführt, und nicht als etwas, das das Tool für ihn erledigt.

Urteil 1 – Fähigkeitsabbau

Vier Schritte:

1. Erstellen Sie den Gold-Standard aus der Historie, nicht von Hand. Durchsuchen Sie vergangene Sitzungen: Vom Nutzer ohne Widerstand übernommen → positive Wiederholung; vom Nutzer abgelehnt / Umschreibung erbeten → negativ. Wiederholung IST Regression. Der eigene Nutzungsverlauf des Nutzers ist das Korpus – kein erfundenes Test-Set.
2. Führen Sie beide Modelle auf demselben Gold-Standard aus, K≥3 (LLM-Judge-Bewertungsfälle: K≥5, weil der Judge verrauscht ist). Zeichnen Sie die Durchfallquote pro (Fingerabdruck, Modellversion) auf.
3. Entscheidungsregel: Abfall ≥20pp UND richtungskonsistent → Abbau melden; unter Schwellwert → "Volatilitätsbeobachtung". Dadurch wird "diese Ausgabe ist seltsam" in ein reproduzierbares Kriterium umgewandelt.
4. Zuschreiben, nicht nur markieren. Untersuchen Sie Zwischenartefakte:
   • Tool-Aufruffehler / Format geändert → Tool-Beschreibung korrigieren.
   • Ausgabestruktur richtig, Inhalt falsch → Anweisungen umschreiben.
   • Hätte ausgelöst werden sollen, wurde es aber nicht → Trigger-Beschreibung korrigieren.
   • Alle Zwischenergebnisse richtig, nur das Endergebnis falsch → modellinterne Regression; Skill als "einzelmodellabhängig" markieren, auf Modellkorrektur warten.

Die Zeile "7 abgebaut, 2 zur Umschreibung empfohlen" ist der zuschreibbare Teil der Ausgabe von Schritt 4 – das macht den Bericht umsetzbar.

Urteil 2 – Ist ein neuer Skill gut?

Aufteilen in zwei messbare Achsen: Effektivität (bessere Ergebnisse) und Wirtschaftlichkeit (niedrigere Kosten).

1. Vorbereitungs-Ablation. Gleicher Aufgabenstapel, zwei Arme: A ohne Skill, B mit Skill. Erfolgsquote, Anzahl menschlicher Korrekturen, Token-Kosten aufzeichnen. Nettonutzen = Erfolgsquotensteigerung × Aufgabenfrequenz − Grenzkosten Ein Skill, der die Erfolgsquote um 30% steigert, aber 3×/Jahr bei +50k Token pro Mal ausgelöst wird, ist eine Verbindlichkeit, kein Vermögenswert.
2. Nachbereitungs-Schattenmodus. Neuer Skill läuft still: Erzeugt Vorschläge, führt aber nicht automatisch aus; protokolliert "was passiert wäre". Beobachten Sie die Adoptionsrate (angenommen vs. überschrieben). Die Adoptionsrate ist der ultimative Richter über "gut", ehrlicher als jede Offline-Metrik. Grenze: Schreiboperationen-Skills (Datei löschen, E-Mail senden) können in Schatten nur simulieren/annotieren, niemals wirklich ausführen.
3. Nettonutzen-Karte. Ein Dashboard pro Skill: Aufrufanzahl, Erfolgsquote, Adoptionsrate, durchschnittliche Token, kumulierter Nettonutzen. 90 Tage netto-negativ → Umschreibung oder Stilllegung vorschlagen. Dies ist die Verbraucherseite der Wertminderungstabelle.

Urteil 3 – Passt es zu DIESEM Nutzer?

"Passt zu dir" = Trigger genau + Annahmen halten + Stil stimmt überein. Alles automatisierbar:

1. Trigger-Präzision (beeinflusst das Gefühl am meisten, wird am meisten übersprungen). Positive aus der Historie (sollte auslösen) und negative (ähnlich, sollte nicht – "diesen Fehler beheben" vs. "erklären, was ein Fehler ist") stichprobenartig auswählen. Wiederholung → Präzision/Recall. Niedrige Präzision = nervig (übermäßige Trigger); niedriger Recall = verschwendete Installation. Zuerst 10–20 manuell beschriften, dann halbautomatisch, null LLM-Kosten.
2. Umgebungsabgleich (installiert ≠ läuft). Skill-Metadaten deklarieren Abhängigkeiten: welche Tools / MCP / Berechtigungen / Pfadgewohnheiten / Sprache, plus implizite Modellfähigkeitsannahmen (langer Kontext, Codeausführung, multimodal). Mit der realen Umgebung des Nutzers abgleichen; fehlend → rote Flagge. "Setzt macOS voraus", "gibt Japanisch aus", "benötigt 200k Kontext" – unsichtbare Annahmen sind der Grund Nr. 1, warum ein Skill ungenutzt bleibt. Dies fließt auch in Urteil 1 zurück: eine fehlgeschlagene Fähigkeitsannahme = stiller Abbau.
3. Stil-Baseline (geringstes Gewicht). Die historische Ausgabe des Nutzers + USER.md als Referenz verwenden; LLM-Judge vergleicht Format, Sprache, Ausführlichkeit. Nur verwendet, um bei gleich bewerteten Skills den Ausschlag zu geben.

Eingebetteter Workflow (für "einen neuen Skill erstellen")

Wenn der Nutzer darum bittet, einen Skill zu erstellen, führen Sie das Protokoll inline vor der Auslieferung aus:

1. Umgebungsabgleich – erfüllt die Umgebung des Nutzers die deklarierten Abhängigkeiten + Fähigkeitsannahmen des Skills?
2. Trigger-Wiederholung – 10–20 stichprobenartige Fälle wiederholen; Präzision/Recall melden.
3. Ablation – bei einem kleinen Aufgabenstapel Steigerung vs. Kosten messen.
4. Überwachung starten – bei Bestehen Fingerabdruck + Gold-Standard registrieren; die residente Konsole führt bei jeder Modellerhöhung erneut aus.

Bedarfsbasierte Vorschläge (wenn kein Skill passt)

Dies ist das Verhalten bei "leerem Regal": Ein Nutzer (insbesondere einer ohne Skills/Plugins) fragt nach etwas, das kein installierter Skill abdeckt. Sagen Sie nicht einfach "Ich kann nicht" – zeigen Sie die Lücke auf und bieten Sie an, sie zu füllen.

1. Erkennen Sie den Bedarf aus dem Gespräch: Aufgabentyp + Domäne (z.B. "vierteljährlicher Finanzbericht" → Finanzen/Analyse; "den KI-Ton entfernen" → Humanizer; "ein Dashboard erstellen" → Frontend/Diagramm).
2. Überprüfen Sie zuerst das Registry – python scripts/console.py suggest --need "<need>". Es gibt entweder:
   • ✓ Sie haben bereits einen verfügbaren Skill/Plugin: <name> → verwenden, nichts installieren; oder
   • 💡 Vorschlag für Neuzugang: [install:<slug>] <titel> → keine Abdeckung, Kategorie empfehlen.
3. Wenn nicht abgedeckt, durchsuchen Sie den Marktplatz nach echten Kandidaten (Skills/Plugins/Experten) und präsentieren Sie eine Karte mit Evidenz: was es tut, warum es diesen Bedarf erfüllt, Quelle. Niemals automatisch installieren – der Nutzer wählt aus.
4. Bei in ...

[Die Originaldatei wurde hier abgeschnitten – Übersetzung des verbleibenden Teils gemäß den Markdown-Regeln.]