Zhr65/SkillFresh

Skill Auditor — Fähigkeitsverlust und Passgenauigkeit von KI-Agenten bewerten

Übersicht

Ein Skill ist ein Wertgegenstand, der an Wert verliert. Neue Modellversionen erscheinen alle paar Monate. Ein Skill, der im letzten Quartal noch funktioniert hat, kann leise nachlassen – falsche Ausgabeformate, kaputte Tool-Aufrufe, verpasste Auslöser – und niemand sagt dem Benutzer, dass sein Agent dümmer geworden ist.

Dieser Skill ist die Bewertungsmethodik. Er beantwortet drei Fragen:

1. Verschlechtert sich ein Skill? – Fähigkeitsverlust über Modellversionen hinweg.
2. Ist ein neuer Skill tatsächlich gut? – Effektivität vs. Kosten.
3. Passt ein Skill zu DIESEM Benutzer? – Auslöser-Genauigkeit + Umgebung + Stil.

Das Skill enthält fünf ausführbare Einstiegspunkte:

• scripts/console.py – die residente Konsole (Datenebene): verwaltet registry.<host>.json pro Host, erkennt Modellversionsänderungen (bump/check) und zeigt das Empfehlungs-/Entfernungs-Panel an. Siehe USAGE.md für den vollständigen Befehlssatz.
• scripts/regress.py – berechnet bei gegebenen Wiedergabeergebnissen eines Golden Sets die Bestehensraten-Matrix, kennzeichnet Verschlechterungen (Schwellwert + Richtung) und kennzeichnet FINGERPRINT-DRIFT, wenn stattdessen eine Datei bearbeitet wurde.
• scripts/baseline.py – erstellt eine Wiedergabe-Checkliste und führt dann die aufgezeichneten Bewertungen in baseline-results.json zusammen (nach Skill; --replace für eine vollständige Überschreibung). Entwurfs-Golden-Cases werden übersprungen, es sei denn, --allow-draft wird verwendet.
• scripts/fingerprint.py – eigenständiges Berichts-CLI; ein dünner Wrapper um denselben Hashing-Code, den scan verwendet. Schreibt nur fingerprint-report.*; es schreibt nicht die Registry.
• scripts/install.py – installiert diesen Skill in jeden Agenten-Host auf dem Rechner (~/.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 eine Baseline. Verschlechterung = signifikanter Rückgang der Bestehensrate bei unverändertem Fingerabdruck – niemals "fühlt sich dümmer an".

Multi-Host-Architektur (Skills vs. Plugins)

Eine Kern-Engine, Adapter pro Host. Die gleiche Fingerprint-/Baseline-/Regressions-/Empfehlungs-/Bedarfssuggestionslogik läuft überall; ein Adapter weiß nur, wo die Assets leben und wie ihr Manifest gelesen wird.

Host	Art	Standard-Stammverzeichnis	Manifest
workbuddy	skill	Stammverzeichnis der Skills, das diesen Skill enthält	SKILL.md
claude-code	skill	~/.claude/skills	SKILL.md
deepseek	插件	~/.dsh/profiles/desktop (liest package.json Abhängigkeiten)	package.json / plugin.json
generic	asset	--root übergeben	plugin.json / manifest.json / SKILL.md / package.json

• Jeder Host führt eine eigene Registry: registry.<host>.json – keine hostübergreifende Überschreibung.
• Baseline-Ergebnisse + Golden Sets werden gemeinsam genutzt, abgelegt nach Asset-Name.
• Ausführen mit --host <name> --root <path>; benutzerdefinierte Hosts in hosts.json hinzufügen.
• console.py hosts zeigt jedes Profil, sein aufgelöstes Stammverzeichnis und die Anzahl der erkannten Assets.

In WorkBuddy bewertest du also Skills; im DeepSeek-Harness bewertest du Plugins – gleiche Befehle, anderer Adapter. Das Hinzufügen eines neuen Hosts ist ein Eintrag in hosts.json (Art + Stammverzeichnis + Manifest-Dateinamen), keine Codeänderung.

Wann verwenden

• Vor dem Bereitstellen eines neuen Skills oder Plugins ("做个 skill，按评测流程走").
• Nach einem Modellversions-Update, um zu prüfen, ob vorhandene Skills nachgelassen haben.
• Wenn ein Skill "sich falsch anfühlt" – mit Daten bestätigen, nicht mit Bauchgefühl.
• Bei der Entscheidung, ob ein Skill behalten / umgeschrieben / ausgemustert werden soll.
• Bei der Empfehlung eines Skills oder Plugins für einen Benutzer (Passgenauigkeit + Beleg).

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

Kernkonzept: Der Versions-Fingerabdruck

Der Fingerabdruck ist die Zeile der Abwertungsmatrix.

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

Was zählt als Fähigkeitsoberfläche (die Dateien, deren Änderung tatsächlich das Verhalten verä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-Änderung verändert keine Fähigkeit, aber das Hashen verschiebt den Fingerabdruck und erzeugt einen falschen FINGERPRINT-DRIFT ("das Asset wurde bearbeitet"), obwohl sich funktional nichts geändert hat. Plugins machen das schlimmer – ein installiertes Plugin kann 16 MB gebündelte Ausgabe plus eine 57 KB große README mitbringen.

Regeln:

• Fingerabdruck unverändert ⇒ die Zeile bleibt bestehen; ein Rückgang der Bestehensrate ist eine Modellregression.
• Fingerabdruck geändert ⇒ die Änderung liegt in der Verantwortung des Skills, nicht des Modells. Alte und neue Zeilen existieren nebeneinander, sodass Skill-Bearbeitungen niemals fälschlicherweise einer Modellabweichung zugeschrieben werden.

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

Fähigkeitsoberfläche (warum Plugins eine zweite Achse brauchen)

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 erlaubter Tools), scripts

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

[caps] 1 asset hat eine geänderte Fähigkeitsoberfläche (das bedeutet "was es nach außen bereitstellt, hat sich geändert", unabhängig von der Bestehensrate):
       plug-a                                   +bin

Warum das für Plugins wichtig ist: Ein Plugin verschlechtert sich, indem es seine Tools nicht registriert / seine Routen mit 404-Fehlern beantwortet / seine Hooks nicht ausführt – nicht durch "schlechtere Antworten". Ein Golden Set von Aufforderungen misst für ein Plugin das Falsche. Der Oberflächenvergleich erfasst "v1.1.0 hat einen Einstiegspunkt entfernt", ohne den Host starten zu müssen.

Bekannte Grenze (nicht darüber hinwegtäuschen): Die Oberfläche ist die deklarierte Fähigkeit, nicht die beobachtete Fähigkeit. Bei einem Plugin, dessen Manifest lügt (einen Patch deklariert, der nicht geladen werden kann), kann dies nicht erkannt werden.

Laufzeitnachweise (die dritte Achse und was sie nicht kann)

Es gibt zwei sehr unterschiedliche Dinge, die "eine Laufzeitüberprüfung" genannt werden. Vermische sie nicht:

	Aktive Sonde (active probe)	Passive Beweise (passive evidence) – 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 (pro Host konfigurierbar über "logs" in hosts.json), parst <iso> [level] [source] message, ordnet Zeilen, deren source einem installierten Asset-Namen entspricht, und markiert Zeilen, die Fehlervokabular enthalten (fail|error|ENOENT|unavailable|timeout|…).

Tatsächlicher Treffer, auf diesem Rechner:

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

Dateien vorhanden, Manifest gültig, caps=4 – jede statische Prüfung besteht. Das Plugin wird geladen und seine Tools sind registriert, aber sie können nicht funktionieren: Das bsk-CLI, an das es auslagert, ist nicht im PATH. Keine noch so große Datei-Hashing findet das.

Blinde Flecken (benenne sie, verstecke sie nie): Ein Plugin, das nichts loggt, ist unsichtbar; Log-Rotation löscht alte Fehler; ein Plugin, das niemand benutzt hat, hat keine Beweise; Fehler auf info-Ebene werden durch Schlüsselwortabgleich erfasst, daher sind sowohl Fehltreffer als auch falsch Positive möglich. Abwesenheit von Beweisen ist kein Beweis für Gesundheit – probe gibt diesen Satz selbst aus, anstatt einen grünen Haken zu setzen.

Implementiert vs. Nur-Methodik (verwische diese Linie nicht)

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

Bereich	Status
Fingerabdruck über der Fähigkeitsoberfläche, scan/status, Fähigkeitsvergleich	implementiert
Golden-Set-Gerüst + Baseline-Erfassung (Zusammenführung nach Asset, Entwurfssperre)	implementiert (baseline.py)
Bestehensraten-Matrix, ≥20pp Schwellwert + Richtung, FINGERPRINT-DRIFT	implementiert (regress.py)
Modelländerungserkennung (bump/check), Host-spezifische Stempel	implementiert – aber die Ereignisquelle ist manuell; eine geplante check bleibt grün, bis jemand bump ausführt
Empfehlungs-/Entfernungs-Panel, Bedarfssuggestion, aus der Historie abgeleitete Entwürfe	implementiert (heuristisch; Vorschläge sind keine Beweise)
Laufzeitnachweise aus Host-Logs	implementiert (passiv; nur was das Plugin geloggt hat)
Ablation, Schattenmodus-Adoptionsrate, Nettowert / Token-Telemetrie	nur Methodik – kein Code
Auslöser-Präzision/Recall, Umgebungsabgleich, Stil-Baseline	nur Methodik – kein Code
K≥3 Wiederholungen, LLM-Judge-Kreuzvalidierung	nicht implementiert; aktuelle Bewertungen sind K=1 Selbsteinschätzung
risk-Spalte	Proxys für die Wartungsoberfläche – kein Wert

Wenn eine Behauptung in dieser Datei nicht auf eine Zeile mit dem Status "implementiert" zurückgeführt werden kann, behandle sie als Ratschlag für den Menschen, der die Prüfung durchführt, nicht als etwas, das das Werkzeug für ihn tun wird.

Beurteilung 1 – Fähigkeitsverlust

Vier Schritte:

1. Baue das Golden Set aus der Historie, nicht von Hand. Durchforste vergangene Sitzungen: Benutzer hat ohne Widerspruch übernommen → positive Wiedergabe; Benutzer hat widersprochen / eine Neufassung verlangt → negative. Wiedergabe IST Regression. Die eigene Nutzungshistorie des Benutzers ist das Korpus – kein erfundener Testsatz.
2. Führe beide Modelle auf demselben Golden Set aus, K≥3 (LLM-Judge-Bewertungsfälle: K≥5, weil der Richter verrauscht ist). Zeichne die Bestehensrate pro (Fingerabdruck, Modellversion) auf.
3. Entscheidungsregel: Abfall von ≥20pp UND richtungsmäßig konsistent → Verschlechterung melden; unter dem Schwellwert → "Volatilitätsbeobachtung". Dies verwandelt "diese Ausgabe ist komisch" in ein reproduzierbares Kriterium.
4. Zuschreiben, nicht nur markieren. Untersuche die Zwischenergebnisse:
   • Tool-Aufruffehler / Format geändert → Tool-Beschreibung korrigieren.
   • Ausgabestruktur richtig, Inhalt falsch → Anweisungen umschreiben.
   • Hätte ausgelöst werden sollen, wurde aber nicht → Auslöserbeschreibung korrigieren.
   • Alle Zwischenergebnisse richtig, nur das Endergebnis falsch → modellinterne Regression; Skill als "einzelmodellabhängig" markieren, auf Modellkorrektur warten.

Die Zeile "7 verschlechtert, 2 zur Neufassung empfohlen" ist der zuschreibbare Teil der Ausgabe von Schritt 4 – das macht den Bericht handlungsorientiert.

Beurteilung 2 – Ist ein neuer Skill gut?

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

1. Ablation vor der Bereitstellung. Gleicher Aufgabenbatch, zwei Arme: A ohne Skill, B mit Skill. Erfolgsrate, Anzahl menschlicher Korrekturen, Token-Kosten aufzeichnen. Nettonutzen = Erfolgsratensteigerung x Aufgabenhäufigkeit − Grenzkosten Ein Skill, der die Erfolgsrate um 30% steigert, aber 3×/Jahr bei +50k Token pro Auslösung ausgelöst wird, ist eine Belastung, kein Wertgegenstand.
2. Schattenmodus nach der Bereitstellung. Neuer Skill läuft im Stillen: Erzeugt Vorschläge, führt sie aber nicht automatisch aus; protokolliert, "was passiert wäre". Beobachte die Adoptionsrate (akzeptiert vs. überschrieben). Die Adoptionsrate ist der ultimative Gradmesser für "gut", ehrlicher als jeder Offline-Messwert. Grenze: Schreiboperationen-Skills (Datei löschen, E-Mail senden) können im Schattenmodus nur simulieren/annotieren, niemals wirklich ausführen.
3. Nettowert-Karte. Ein Dashboard pro Skill: Aufrufanzahl, Erfolgsrate, Adoptionsrate, durchschnittliche Token, kumulativer Nettonutzen. 90 Tage netto negativ → Neufassung oder Ausmusterung vorschlagen. Dies ist die Konsumentenseite der Abwertungstabelle.

Beurteilung 3 – Passt es zu DIESEM Benutzer?

"Passt zu dir" = Auslöser genau + Annahmen halten + Stil passt. Alles automatisierbar:

1. Auslöser-Präzision (beeinflusst das Gefühl am meisten, wird am meisten übersprungen). Beispiele aus der Historie positiv (sollte auslösen) und negativ (sieht ähnlich aus, sollte nicht – "behebe diesen Fehler" vs. "erkläre, was ein Fehler ist"). Wiedergabe → Präzision/Recall. Niedrige Präzision = nervig (übermäßiges Auslösen); niedriger Recall = verschwendete Installation. Zuerst 10–20 manuell labeln, dann halbautomatisch, keine LLM-Kosten.
2. Umgebungsabgleich (installiert ≠ funktioniert). Skill-Metadaten deklarieren Abhängigkeiten: welche Tools / MCP / Berechtigungen / Pfadgewohnheiten / Sprache, plus implizite Modellfähigkeitsannahmen (langer Kontext, Codeausführung, multimodal). Mit der tatsächlichen Umgebung des Benutzers abgleichen; fehlend → rote Flagge. "Setzt macOS voraus", "gibt Japanisch aus", "benötigt 200k Kontext" – unsichtbare Annahmen sind der häufigste Grund, warum ein Skill ungenutzt bleibt. Dies fließt auch zurück in Beurteilung 1: eine fehlgeschlagene Fähigkeitsannahme = stiller Fähigkeitsverlust.
3. Stil-Baseline (niedrigstes Gewicht). Verwende die historische Ausgabe des Benutzers + USER.md als Referenz; LLM-Judge vergleicht Format, Sprache, Ausführlichkeit. Wird nur verwendet, um Gleichstände zwischen Skills mit gleicher Bewertung zu brechen.

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

Wenn der Benutzer darum bittet, einen Skill zu erstellen, führe das Protokoll inline vor der Auslieferung aus:

1. Umgebungsabgleich – erfüllt die Umgebung des Benutzers die deklarierten Abhängigkeiten + Fähigkeitsannahmen des Skills?
2. Auslöser-Wiedergabe – 10–20 gesamplete Fälle wiedergeben; Präzision/Recall melden.
3. Ablation – in einem kleinen Aufgabenbatch die Steigerung vs. Kosten messen.
4. Überwachung starten – bei Bestehen Fingerabdruck + Golden Set registrieren; die residente Konsole wird bei jedem Modell-Update neu ausgeführt.

Bedarfsgesteuerter Vorschlag (wenn kein Skill passt)

Dies ist das Verhalten für den "leeren Laden": Ein Benutzer (insbesondere einer mit null Skills/Plugins) fragt nach etwas, das kein installierter Skill abdeckt. Sage nicht einfach "Ich kann nicht" – zeige die Lücke auf und biete an, sie zu füllen.

1. Erkenne den Bedarf aus dem Gespräch: Aufgabentyp + Domäne (z.B. "quartalsweiser Finanzbericht" → Finanzen/Analyse; "entferne den KI-Ton" → Humanizer; "baue ein Dashboard" → Frontend/Diagramm).
2. Überprüfe zuerst die Registry – python scripts/console.py suggest --need "<need>". Es gibt entweder Folgendes zurück:
   • ✓ Du hast bereits einen geeigneten Skill / ein geeignetes Plugin: <name> → verwende es, installiere nichts; oder
   • 💡 Vorschlag für Neuzugang: [install:<slug>] <title> → keine Abdeckung, empfehle die Kategorie.
3. Wenn nicht abgedeckt, durchsuche den Marktplatz nach echten Kandidaten (Skills/Plugins/Experten) und präsentiere eine Karte mit Belegen: was es tut, warum es zu diesem Bedarf passt, Quelle. Niemals automatisch installieren – der Benutzer wählt aus.
4. Bei Integration (durch den Benutzer bestätigt) – führe die ersten drei Schritte des eingebetteten Workflows aus, um sicherzustellen, dass es tatsächlich funktioniert und passt, bevor es in den dauerhaften Pool aufgenommen wird.