01 / Die Geschichte
Es begann mit 78 installierten Skills
Die erste Frage war praktisch. Sollten wir einen Skill behalten, seine Beschreibung ändern, ihn mit einem anderen zusammenführen oder entfernen? Ein Ordner voller Anweisungen beantwortet das nicht. Wir mussten sehen, was jeder Skill vorgab, wann der Agent ihn nutzte und ob andere Anweisungen dieselbe Aufgabe bereits abdeckten.
Wir begannen mit einem lokalen Skillsbaum. Das Dashboard ermöglichte es, die von uns gelesenen Dateien mit den tatsächlichen Nutzungsaufzeichnungen zu vergleichen. WhichSkills entstand aus der nächsten Frage: Könnten wir eine konsistente Methode auf eine grössere öffentliche Stichprobe anwenden und andere Leute die Ergebnisse überprüfen lassen?
02 / Das Problem
Ein installierter Skill ist nicht unbedingt ein nützlicher Skill
Aufrufzahlen allein erklären den Kontext nicht. Ein Skill kann eine seltene Aufgabe abdecken, sich mit einem anderen überschneiden oder eine Beschreibung haben, die ihn nie auslöst. Die Beliebtheit eines Repositorys erklärt keinen dieser Fälle.
Auch Sicherheitsprüfungen haben Grenzen. Derselbe Befehl kann eine Handlungsanweisung, ein dokumentiertes Beispiel oder Bestandteil eines Tests sein. Wir mussten einen Mustertreffer von einer begründeten Schlussfolgerung unterscheiden. Die gespeicherten Nachweise sollen es anderen ermöglichen, diese Schlussfolgerung zu hinterfragen.
03 / Wie es funktioniert
Dateien, Bewertungen und Prüfung zusammenführen
Das Dashboard lädt Skill-Dateien und Plugin-Manifeste. Es sucht in lokalen Transkripten nach Nutzungsbelegen und vergleicht die Skills auf Überschneidungen. Jev ergänzt Bewertungen zu Nutzen, Redundanz und Verständlichkeit. Seine Empfehlung bleibt von unserer dokumentierten Entscheidung getrennt. Wenn kein Aufruf protokolliert wurde, ist das ein Anlass zur Prüfung. Es beweist nicht, dass ein Skill wertlos ist.
Dieselben Fragen an einer grösseren Stichprobe prüfen
Für den am 20. September 2026 veröffentlichten Stand haben wir GitHub nach Suchbegriffen und Themen durchsucht. Wir schlossen Forks aus und wählten die 200 Repositorys mit den meisten Sternen. Davon enthielten 157 Skills oder Plugin-Manifeste. Der Ladevorgang fand 18.041 Skills und 557 Manifeste.
Wir haben die Quell-Commits aufgezeichnet, damit jeder Befund auf die tatsächlich gelesene Datei verweist. Die Sterne bestimmten die Stichprobe mit. Sie entschieden nicht darüber, welche Skills nützlich oder sicher waren. Die Ergebnisse beziehen sich auf diesen Erhebungszeitpunkt und sind keine vollständige Bestandsaufnahme aller verfügbaren Skills.
Zuerst einfache Prüfungen, dann den Kontext lesen
Die statische Prüfung untersuchte begleitende Textdateien auf 14 Musterklassen. Dazu gehörten externe Datenübertragungen, versteckte Anweisungen, Zugriff auf Zugangsdaten und automatische Hooks. Wir wählten bewusst eine empfindliche Erkennung. Auch ein Deployment-Befehl oder eine Sicherheitsanleitung kann einen Treffer auslösen, ohne ein Angriff zu sein.
Ausgewählte Treffer gelangten in die Prüfwarteschlange. Vor der Bewertung durch Jev entfernten wir doppelte Textinhalte. Wiederholte Anweisungen mussten dadurch nur einmal bewertet werden. Der veröffentlichte Lauf enthält 545 verschiedene von Jev gelesene Texte, keine 18.041 Modellbewertungen.
Für jeden Text beantwortete Jev zwei festgelegte Fragen. Wie riskant erschienen die Anweisungen auf einer Skala von null bis drei? Welche Risikoart beschrieb sie am besten? Das Ergebnis bestand aus Wahrscheinlichkeitsverteilungen. Anschliessend öffneten wir jeden Text mit mindestens 1,5 Punkten im festgehaltenen Commit und dokumentierten unsere Befunde.
Für den Jev-Durchlauf wurden ungefähr 4,2 Millionen Eingabetokens und 93 Sekunden gemessen. Diese Werte gelten für diesen Lauf und sind keine Zusage für spätere Prüfungen. Die veröffentlichte Methode enthält die Fragen, Warteschlangenregeln und Datendateien.
Die nützlichsten Erkenntnisse erforderten eine menschliche Lektüre
Eine Datei mit hoher Risikobewertung war ein absichtlich manipuliertes Testbeispiel in NVIDIAs SkillSpector-Repository. Andere Treffer stammten aus Lehrmaterial zur offensiven IT-Sicherheit. Die Texte enthielten echte Angriffsbeispiele, dienten aber Tests oder der Ausbildung. Jeden Treffer als Schadsoftware einzuordnen, wäre falsch gewesen.
Eine relevantere Erkenntnis war ein Plugin-Hook, der den Agenten anwies, zu handeln, ohne den Benutzer zu fragen. Jev hat diese Anweisung anhand des vollständigen Textes identifiziert, obwohl unsere statischen Regeln keine spezifische Kategorie für dieses Verhalten hatten.
Im geprüften Material fanden wir keine Schadsoftware, die sich gegen den installierenden Nutzer richtete. Das ist kein Sicherheitszertifikat. Binärdateien, Bilder und erst zur Laufzeit nachgeladener Code wurden nicht untersucht. Die Website dokumentiert auch übergrosse Eingaben, die die API zurückgewiesen hat.
Auch Duplikate waren weit verbreitet. Die Website meldet 36 % identische Kopien im Rahmen ihrer Vergleichsmethode, bei der Frontmatter entfernt und Leerzeichen reduziert werden. Ein Grossteil der Kopien stammte von demselben Besitzer, der an mehr als einem Ort veröffentlichte. Die Provenienzansicht unterscheidet diese Spiegel von Kopien Dritter und bezeichnet ungewisse Herkunft als die früheste bekannte Kopie in der Stichprobe.
Bewahren Sie die Nachweise neben der Empfehlung auf
Der Wortlaut der Frage war wichtig. Eine breite Aufforderung, eine Massnahme zu empfehlen, zielte tendenziell auf den Erhalt von Skills ab. Explizitere Kriterien trennten die Ergebnisse besser. Auch der Kontext spielte eine Rolle: Eine kurze Datei, die ausschliesslich aus einem Angriffsbeispiel besteht, könnte eine höhere Punktzahl erzielen als ein langes Dokument, in dem dasselbe Beispiel zitiert wird.
Deshalb hält das Dashboard die zugrunde liegenden Nachweise und Verteilungen sichtbar. Wir wollen eine Empfehlung prüfen, ihr widersprechen und eine Begründung hinterlegen. Die öffentliche Website folgt dem gleichen Prinzip mit festgeschriebenen Dateien, Überprüfungsnotizen und herunterladbaren Daten. TypeSafe hat die Arbeit weder in Auftrag gegeben noch finanziert; Wir haben die öffentliche API verwendet.
Finden Sie Ergänzungen, die zur Arbeit passen
Nachdem wir den Bestand kannten, konnten wir nach fehlenden Skills suchen. Die Upgrade-Ansicht erstellt aus lokalen Anweisungen, Skills und ihrer Nutzung ein Profil. Sie wählt Kandidaten aus dem öffentlichen Index aus und lässt Jev diese anhand des Profils prüfen. Die Rangfolge berücksichtigt sowohl die Eignung als auch die Möglichkeit, dass ein vorhandener Skill die Aufgabe bereits erfüllt.
Die jüngsten Einstiegs-Prompts können optional einbezogen werden. Dann geht dieser Text an Jev. Das Dashboard läuft lokal, aber für Modellbewertungen wird der bereitgestellte Kontext an TypeSafe gesendet. Prüfen Sie diesen Kontext, bevor Sie private Skills oder Arbeitsaufzeichnungen bewerten.
So können wir vorhandene Skills prüfen und Ergänzungen bewusst auswählen. Sehen Sie sich die veröffentlichten Ergebnisse und den durchsuchbaren Index an, bevor Sie das Werkzeug selbst ausführen.
04 / Installation
Prüfen Sie Ihre eigenen Skills
Das Dashboard benötigt Python 3 und nutzt die Standardbibliothek mit SQLite. Es gibt keinen Frontend-Build oder Paketinstallationsschritt. Klonen Sie das Repository und starten Sie den lokalen Server:
git clone https://github.com/48Nauts-Operator/skill-dash
cd skill-dash
python3 server.py --port 3345Öffnen Sie http://localhost:3345. Das Laden von Dateien und statische Prüfungen brauchen keinen Modellschlüssel. Für Jev-Bewertungen setzen Sie vor dem Serverstart TYPESAFE_API_KEY in der Serverumgebung. API-Zugang und Nutzungsgebühren sind separat.
Die folgenden Anleitungen führen durch die Einrichtung, Sammlung, Überprüfung und Freigabe. Sie bieten auch eine angeheftete Coderevision zum Verfolgen des aufgezeichneten Arbeitsablaufs.
