Jenseits des Hypes: Wir haben 1416 Claude-Skills ausgeführt, um die tatsächliche Anzahl funktionierender Skills zu ermitteln

Sie haben die Zahlen wahrscheinlich gesehen: Schlagzeilen und Verzeichnisse, die über 23.000 zur Installation verfügbare Claude-Skills bewerben. Diese Zahl suggeriert ein riesiges, ausgereiftes Ökosystem von Tools, die bereit sind, die Fähigkeiten des Basismodells zu erweitern. Es ist eine beeindruckende Zahl, die jedoch eine entscheidende technische Frage aufwirft: Was bedeutet „verfügbar“ eigentlich? In den meisten Fällen bedeutet es, dass ein SKILL.md-Manifest in einem öffentlichen Code-Repository gefunden wurde. Es ist eine Zählung, die auf der Dateierkennung basiert, nicht auf funktionaler Verifizierung.

Dieser Ansatz ist einfach, skalierbar und letztendlich irreführend. Er sagt nichts darüber aus, ob ein Skill installiert werden kann, fehlerfrei läuft oder seine beworbene Funktion effektiv ausführt. Er verrät nicht, ob es sich um ein aufgegebenes Projekt, einen fehlerhaften Proof-of-Concept handelt oder ob die Leistung sogar schlechter ist als bei der Verwendung ohne Skill.

Bei SkillProof verfolgen wir einen anderen Ansatz. Wir zählen keine Repositories; wir installieren und führen Skills anhand eines standardisierten Satzes von realen Aufgaben aus. Dieser Artikel präsentiert unsere Ergebnisse aus dem Test von 1416 Skills. Es ist eine direkte, datengestützte Antwort auf die Frage, wie viele Claude-Code-Skills es gibt, die tatsächlich funktionieren, und eine Untersuchung, ob Claude-Skill-Marktplätze zuverlässige Quellen für produktionsreife Tools sind.

Der Fehler beim reinen Zählen von Dateien

Das grundlegende Problem bei einer Zählung von über 23.000 Skills ist, dass die Erkennung als Validierung behandelt wird. Das Scrapen von Plattformen wie GitHub nach SKILL.md-Dateien ist eine triviale Aufgabe. Die resultierende Zahl eignet sich gut für Marketingtexte, ist aber eine „Vanity Metric“, die die Realität der Softwareentwicklung ignoriert.

Ein Repository, das ein Skill-Manifest enthält, ist nur ein Ausgangspunkt. Es ist eine Behauptung, keine Garantie. Als wir mit dem systematischen Testen von Skills begannen, identifizierten wir schnell gängige Fehlermuster, die das einfache Zählen von Dateien vollständig übersieht:

• Unvollständige oder fehlerhafte Manifeste: Die SKILL.md-Datei existiert, aber es fehlen erforderliche Abschnitte, sie verweist auf nicht existierende Tool-Definitionen oder ist syntaktisch inkorrekt. Der Skill kann ohne manuelle Korrektur nicht installiert werden.
• Defekte Abhängigkeiten: Der Code des Skills stützt sich auf externe Bibliotheken, die veraltet sind, Breaking Changes aufweisen oder nicht mehr verfügbar sind. Die Installation mag erfolgreich sein, aber der Skill wird zur Laufzeit fehlschlagen.
• Undokumentierte Umgebungsanforderungen: Ein Skill kann spezifische Umgebungsvariablen, einen laufenden lokalen Dienst oder Authentifizierungstoken erfordern, die in der Dokumentation nicht erwähnt werden. Ein von uns getesteter Skill erforderte eine bestimmte Version einer Datenbank, die auf localhost:5433 lief – ein Detail, das erst durch das Lesen des Python-Quellcodes entdeckt wurde. Ohne diese war er nicht funktionsfähig.
• Aufgegebene Projekte: Das Repository wurde seit Jahren nicht mehr aktualisiert. Der Code wurde für eine frühere Version der Claude-API geschrieben und ist nicht mehr kompatibel.
• „Prompt-as-a-Skill“: Einige Skills enthalten keine tatsächlichen Tools. Sie sind lediglich aufwendige Prompts, die in einem Skill-Format verpackt sind. Obwohl sie potenziell nützlich sein können, stellen sie keine funktionale Erweiterung der Modellfähigkeiten dar und erbringen oft keine bessere Leistung als ein gut geschriebener Prompt.

Das bloße Zählen dieser Repositories bläht die wahrgenommene Größe und Gesundheit des Ökosystems auf. Es schafft eine Landschaft, in der das Finden eines funktionierenden, zuverlässigen Tools zu einer Sache von Versuch und Irrtum wird. Unsere Testmethodik wurde speziell entwickelt, um dieses Rauschen zu durchdringen, indem die Ausführung zum primären Maß für die Gültigkeit eines Skills gemacht wird.

Unsere Ergebnisse: Ein ernüchternder Blick auf die wahre Anzahl

Wir haben 1416 Skills aus verschiedenen öffentlichen Verzeichnissen und Repositories installiert und versucht, sie auszuführen. Jeder Skill wurde einer Reihe von automatisierten Tests unterzogen, die darauf ausgelegt waren, seine Kernfunktionalität aufzurufen. Die Ergebnisse liefern ein wesentlich klareres Bild vom Zustand des Ökosystems.

Von den 1416 von uns getesteten Skills haben nur 889 (63 %) unsere ersten Ausführungstests ohne manuelle Eingriffe bestanden.

Hier ist eine vollständige Aufschlüsselung unserer Ergebnisse:

Status	Anzahl	Prozentsatz (gesamt)
Pass (Läuft ohne Konfiguration)	889	63%
Needs Setup (Manuelle Konfiguration erforderlich)	467	33%
Fails (Schlechtere Leistung als Basismodell)	60	4%
Insgesamt getestet	1416	100%

Analysieren wir, was jede dieser Kategorien für einen Entwickler bedeutet, der versucht, diese Tools zu verwenden.

Pass (63 %): Diese Skills wurden korrekt installiert und liefen auf unserer Testumgebung fehlerfrei. Dies ist die „reale Anzahl an Claude-Skills im Verzeichnis“ aus unserer Stichprobe – die Teilmenge der Skills, die sofort nutzbar sind. Dies ist die Baseline für das, was ein Benutzer von jedem in einem Verzeichnis gelisteten Skill erwarten sollte. Wie wir jedoch noch erörtern werden, bedeutet „lauffähig“ nicht automatisch „hohe Qualität“.

Needs Setup (33 %): Dies ist eine bedeutende und oft übersehene Kategorie. Diese 467 Skills waren nicht defekt, aber sie waren nicht Plug-and-Play. Häufige Gründe waren:

• Erfordernis, API-Schlüssel manuell als Umgebungsvariablen zu setzen.
• Notwendigkeit, eine Verbindung zu einer vom Benutzer bereitgestellten Datenbank oder einem Drittanbieterdienst herzustellen.
• Abhängigkeit von lokalen Dateien oder Systemkonfigurationen, die nicht in der SKILL.md spezifiziert waren.

Beispielsweise ist ein Skill zur Interaktion mit einer Projektmanagement-API ohne einen API-Schlüssel und eine Endpunkt-URL unbrauchbar. Diese Skills sind keine Fehlschläge, aber sie ohne klare, vorab bereitgestellte Einrichtungsanweisungen aufzulisten, ist ein schlechter Dienst am Benutzer. Ein Verzeichnis, das nicht zwischen einem „Pass“-Skill und einem „Needs Setup“-Skill unterscheidet, vermittelt ein unzuverlässiges Bild.

Fails (4 %): Dies ist die besorgniserregendste Kategorie. Diese 60 Skills haben nicht nur ihre Funktion nicht erfüllt, sondern Ergebnisse geliefert, die aktiv schlechter waren als die Verwendung des Basismodells ohne Skill. Dies geschieht, wenn die Logik eines Skills fehlerhaft ist, was das Modell dazu veranlasst:

• In einer Schleife stecken zu bleiben und wiederholt zu versuchen, ein defektes Tool aufzurufen.
• Die Verwendung von Tools zu halluzinieren, die in seiner eigenen Definition nicht existieren.
• Die Absicht des Benutzers falsch zu interpretieren und ein Tool inkorrekt anzuwenden, was zu Fehlern oder unsinniger Ausgabe führt.

Ein von uns getesteter Skill war dafür konzipiert, Code-Snippets zu formatieren. Als er eine einfache Python-Funktion erhielt, versuchte er, ein format_javascript-Tool aufzurufen, schlug fehl und gab eine Fehlermeldung zurück. Dieselbe Anfrage an das reine Claude-Modell hätte zu einem korrekt formatierten Python-Snippet geführt. Diese 60 Skills sind nicht nur nutzlos; sie sind schädlich. Kein seriöses Verzeichnis sollte sie ohne eine deutliche Warnung auflisten. Wir veröffentlichen diese Fehlschläge, weil sie ein entscheidender Teil der Daten sind.

Jenseits der Ausführung: Was definiert die Qualität eines Skills?

Die Daten zeigen, dass etwa zwei von drei Skills, die Sie finden, lauffähig sind. Aber das beantwortet nur den ersten Teil der Frage. Der zweite, wichtigere Teil betrifft die Qualität. Die „Qualität der 23000 Claude-Skills“ ist keine Frage der Quantität, sondern der Leistung.

Ein Skill, der zwar läuft, seine Aufgabe aber schlecht erfüllt, ist kaum besser als einer, der gar nicht läuft. Deshalb bewerten wir einen Skill, nachdem er unseren ersten Ausführungstest bestanden hat, auf einer Skala von 1 bis 10, basierend auf seiner Leistung bei einer Reihe von realen Aufgaben. Unser vollständiges Bewertungsschema ist in unserer Methodik detailliert beschrieben, konzentriert sich aber auf einige Schlüsselprinzipien:

• Zuverlässigkeit: Erfüllt der Skill seine angegebene Aufgabe konsistent? Verwendet er die richtigen Tools für die Aufgabe?
• Genauigkeit: Ist die Ausgabe korrekt und fehlerfrei? Wenn er mit einer API interagiert, verarbeitet er die Daten korrekt?
• Effizienz: Löst er das Problem ohne unnötige Schritte oder Tool-Aufrufe?
• Sicheres Fehlverhalten: Gibt er bei einem Edge Case oder einer ungültigen Eingabe eine hilfreiche Fehlermeldung zurück oder stürzt er ab?

Der Unterschied zwischen einem Skill mit hoher und einem mit niedriger Bewertung ist gravierend.

Ein Skill mit hoher Bewertung, wie ein gut gebautes Cloud-Infrastruktur-Tool, wird eine Anfrage wie „list all EC2 instances in us-east-1“ korrekt interpretieren, sein list_instances-Tool mit dem korrekten region-Parameter verwenden, die paginierte Antwort der API verarbeiten und dem Benutzer eine saubere, genaue Liste präsentieren.

Ein Skill mit niedriger Bewertung mag dasselbe Ziel haben, aber bei der Ausführung versagen. Beispielsweise ignorierte ein anderes von uns getestetes Cloud-Tool die angegebene Region und listete Instanzen aus seiner Standardregion auf. Es „funktionierte“ in dem Sinne, dass es nicht abstürzte, aber es lieferte die falsche Antwort, was es unzuverlässig macht.

Die 60 Skills, die schlechter als das Basismodell abschnitten, stellen die unterste Grenze dar. Sie sind eine greifbare Demonstration, dass ein schlecht konzipierter Skill schlechter ist als gar kein Skill. Dies ist ein kritischer Datenpunkt, der verloren geht, wenn Verzeichnisse die Kataloggröße über die verifizierte Leistung stellen.

Das Signal im Rauschen finden

Die Diskrepanz zwischen den beworbenen über 23.000 Skills und unserer getesteten Erfolgsquote von 63 % verdeutlicht das Kernproblem: Das Ökosystem ist voller Rauschen. Die wahre Anzahl funktionaler, hochwertiger Skills ist ein kleiner Bruchteil der beworbenen Gesamtzahl.

Jeden Skill, den Sie finden, manuell zu testen, ist für keinen Entwickler eine praktikable Lösung. Der Prozess ist zeit- und ressourcenintensiv. Unser Test von 1416 Skills erforderte erheblichen Entwicklungsaufwand zum Erstellen des Test-Harness und beträchtliche Rechenressourcen zur Durchführung der Auswertungen. Genau aus diesem Grund tun es die meisten Verzeichnisse nicht. Es ist weitaus einfacher, einen Scraper auszuführen und eine große, unverifizierte Zahl zu veröffentlichen.

Das Ziel eines Skill-Verzeichnisses sollte es sein, das Signal vom Rauschen zu trennen. Es sollte die Validierungsarbeit im Namen des Benutzers übernehmen. Das bedeutet:

1. Jeden Skill ausführen: Ein Skill ist nicht „verifiziert“, bevor er nicht ausgeführt wurde.
2. Auf Korrektheit testen: Der Skill muss anhand realer Aufgaben bewertet werden, um zu sehen, ob er wie beworben funktioniert.
3. Fehlschläge veröffentlichen: Ein Verzeichnis, das nicht anzeigt, was fehlgeschlagen ist, verschweigt die halbe Wahrheit. Die Daten über Fehlschläge sind genauso wichtig wie die Erfolgsdaten.

Indem wir Skills in Dutzenden von Kategorien testen, von der Datenanalyse bis zur Webentwicklung, erstellen wir eine Landkarte dessen, was funktioniert, was Anpassungen benötigt und was gänzlich zu vermeiden ist.

Dieser datengesteuerte Ansatz ist die einzig zuverlässige Methode, um die Frage zu beantworten: „Sind Claude-Skill-Marktplätze zuverlässig?“ Die Antwort lautet: Sie sind nur so zuverlässig wie ihr Verifizierungsprozess. Ein Marktplatz, der nur eine Liste von Repositories ist, ist keine verlässliche Quelle für professionelle Tools. Ein Verzeichnis, das jeden einzelnen Eintrag ausführt, testet und bewertet, schafft eine Vertrauensgrundlage.

Weiterführende Lektüre: Wie viele die Baseline tatsächlich übertreffen · Unsere Testmethodik.

Wir haben diese Arbeit für unseren gesamten Katalog durchgeführt. Die 889 Skills, die unsere Tests bestanden haben, stehen zum Durchsuchen zur Verfügung, komplett mit ihren Bewertungen und einem Urteil über ihre Leistung. Für Entwickler, die ein Kernset bewährter Tools benötigen, bieten wir ein kuratiertes Paket unserer bestbewerteten Skills für 10 $ an, die alle garantiert lauffähig sind und wie erwartet funktionieren. Dies ist unsere Lösung für das Signal-Rausch-Problem: eine kleine, verifizierte, hochwertige Teilmenge des riesigen, unverifizierten öffentlichen Ökosystems.