Claude Skills testen: das SkillProof-Protokoll

Die ganze Seite begann mit einem Skill, der nichts tat. Ende 2025 machte ein Produktivitäts-Skill auf X die Runde, mit ein paar tausend Sternen im Rücken. Wir installierten ihn, starteten Claude Code neu, tippten den exakten Anwendungsfall aus der README, und sahen zu, wie Claude antwortete, als gäbe es den Skill nicht. Verzeichnis geprüft: Dateien vorhanden, Frontmatter gültig. Andere Formulierung getippt. Nichts. Der Skill feuerte in vierzig Minuten kein einziges Mal, und nichts auf der Repo-Seite hätte das vorhergesagt. Sterne messen, ob eine README aufregend ist. Sie sagen nichts darüber, ob der Ordner darunter funktioniert.

Dieser Abend hinterließ eine Frage, die wir nicht loswurden: Wenn ein Skill mit so viel Aufmerksamkeit bei der Ankunft tot sein kann, wie sieht dann der Rest des Ökosystems aus? Also fingen wir an, Skills auf einer sauberen Maschine zu installieren und aufzuschreiben, was passierte. Die Antwort, dokumentiert in unseren Ausfalldaten, ist, dass etwa die Hälfte der Community-Skills scheitert, bevor sie irgendwem hilft. Dieser Beitrag ist die andere Seite dieses Befunds: das exakte Protokoll hinter jedem Urteil auf SkillProof, detailliert genug, dass du es an deinem eigenen Skill laufen lassen kannst, bevor du ihn veröffentlichst.

Das Protokoll, Schritt für Schritt

Ein vollständiger Test dauert zwischen 45 Minuten und mehreren Tagen, je nach Kategorie. Ein Dokument-Skill beweist sich in einer Sitzung; ein Wochenrückblick-Skill muss eine echte Woche überstehen. So oder so sind die Schritte dieselben, und die Reihenfolge zählt, weil jeder den nächsten freischaltet. Es hat keinen Sinn, den Output eines Skills zu bewerten, der nie triggert.

Schritt 0: eine frische Umgebung

Jeder Test startet auf einem Maschinenprofil mit leerem Skills-Verzeichnis und Standard-Claude-Code-Einstellungen. Das klingt nach Zeremonie, bis es dich das erste Mal rettet. Skills interagieren: Einer kann so aussehen, als funktioniere er, weil ein anderer Skill auf der Maschine still die Schwerarbeit übernimmt. Das haben wir gelernt, als wir einen Proposal-Skill auf einer Maschine testeten, auf der bereits der docx-Skill installiert war. Der Output sah großartig aus. Auf einem sauberen Profil verschwand die Hälfte des Werts, weil der Document-Skill die ganze Zeit das polierte .docx produziert hatte.

Schritt 1: Installation nach den eigenen Anweisungen des Autors

Wir öffnen die README des Repos und folgen ihr wörtlich. Nicht "wir finden heraus, wie man es installiert." Wir tun exakt, was der Autor geschrieben hat, Tippfehler inklusive, weil das ist, was jeder echte Nutzer tun wird. Produzieren die Befehle tatsächlich ~/.claude/skills/name/name/SKILL.md, ein Verzeichnis zu tief, ist das eine gescheiterte Installation, auch wenn jeder, der das Format kennt, es in zehn Sekunden reparieren könnte. Wir könnten es auch reparieren. Der Punkt ist, dass die Neulingin, die um 23 Uhr mitliest, es nicht kann, und sie wird schließen, Claude Skills seien kaputt, statt dass ein Pfad falsch war.

Alles, was die README nicht erwähnt, zählt gegen sie: nicht deklarierte Abhängigkeiten, Anweisungen, geschrieben für eine Claude-Code-Version, die zwei Releases zurückliegt. Wir notieren die Zeit vom Klonen bis zum funktionierenden Skill, und ob wir die README verlassen mussten, um dorthin zu gelangen.

Schritt 2: die Trigger-Batterie

Ein installierter Skill, der nie aktiviert, ist Dekoration. Also führen wir vor jeder echten Aufgabe eine Fünf-Prompt-Batterie durch: drei Formulierungen, die triggern sollten, zwei, die es nicht sollten.

Die drei positiven Prompts sind bewusst unterschiedlich. Für einen Word-Dokument-Skill: "mach aus diesen Notizen einen Bericht, den ich als .docx verschicken kann", dann "entwirf diesen Vertrag als Word-Datei", dann etwas Umständliches wie "ich brauche das ordentlich formatiert für die rechtliche Prüfung." Der erste ist das eigene Beispiel der README. Der zweite nutzt andere Vokabeln für dieselbe Absicht. Der dritte nennt nie das Dateiformat, was testet, ob die Beschreibung den Job abdeckt statt nur die Stichwörter.

Die zwei negativen Prompts prüfen Übertriggerung, den Fehler, über den niemand spricht. Ein Dokument-Skill, der feuert, wenn du fragst "fass dieses Dokument zusammen" (eingefügter Text, keine Datei beteiligt), injiziert Anweisungen in Unterhaltungen, wo sie nicht hingehören, und dafür zahlst du in Kontext und in seltsamen Outputs. Ein Skill, der bei allem feuert, ist schlimmer als einer, der bei nichts feuert; zumindest ist der tote leicht zu diagnostizieren.

Fünf von fünf ist ein sauberes Ergebnis. Darunter notieren wir, welche Formulierungen scheiterten; das Muster ist meist aufschlussreich. Ein Skill, der nur bei der exakten Wortwahl der README feuert, hat eine Beschreibung, geschrieben als Tagline statt als Trigger-Spezifikation.

Schritt 3: der Baseline-Lauf

Das ist das Herzstück des Tests und der Grund, warum das Protokoll existiert. Wir nehmen eine echte Aufgabe aus der Domäne des Skills und führen sie zweimal aus: einmal mit installiertem Skill, einmal mit dem nackten Modell bei identischem Prompt. Dann vergleichen wir.

Der Vergleich ist die einzige Frage, die zählt: Ist der Output mit Skill eindeutig besser als das, was Claude ohnehin produziert? Claude ist bereits in vielem gut. Ein "Schreibverbesserungs"-Skill, der gegen ein Modell antritt, das gut schreibt, muss eine Delta zeigen, und die meisten können das nicht. Als wir frontend-design testeten, führten wir dasselbe Landingpage-Briefing beide Wege aus. Die Version mit Skill hatte eine echte Typografie-Skala und eine bewusste Farbpalette; die Baseline hatte den Neon-Gradient-Look, den jeder erkennt. Diese Delta verdiente eine 10. Wenn sich die beiden Outputs kaum unterscheiden lassen, hat der Skill keinen Grund zu existieren, wie angenehm auch immer seine README ist.

Echte Inputs zählen so viel wie der Vergleich. Eine Tabelle mit fehlerhaften Kopfzeilen, ein Rechnungsordner, in dem ein Drittel der Dateien Scans sind. Demo-Daten-Performance ist Marketing; wir testen die Dienstagnachmittag-Version des Jobs, weil das die Version ist, die du ihm geben wirst.

Schritt 4: der Doku-Abgleich

Zuletzt lesen wir die gesamte SKILL.md und alles, worauf sie verweist, und vergleichen dann die Behauptungen mit dem, was wir beobachtet haben. Verspricht die README Fähigkeiten, die der Skill nicht hat? Legt sie ihre Abhängigkeiten offen? Gibt es irgendwo mittendrin etwas, das weniger nach Aufgabenanleitung aussieht und mehr nach Prompt-Injection, oder einen Netzwerkaufruf, den die Doku nie erwähnt?

Dieser Schritt schlägt vielleicht bei einem von zehn Skills an, aber die, die er erwischt, zählen am meisten. Ein Skill ist Text, der in den Kontext deines Modells injiziert wird. Jede Zeile zu lesen, bevor man ihm vertraut, ist das Minimum, und wir behandeln dieses Lesen als Teil des Produkts.

Die vier Scores, und warum Output doppelt zählt

Jeder getestete Skill bekommt vier Zahlen, beschrieben auf unserer Methodik-Seite. Die Kurzversion, mit dem, was eine 5 von einer 2 unterscheidet:

Installiert sauber (von 5). Eine 5 bedeutet, eine Neulingin, die der README folgt, bekommt einen funktionierenden Skill auf einem frischen Setup ohne Umwege. Eine 2 bedeutet, wir haben es letztlich mit Wissen zum Laufen gebracht, das die README nicht enthält: Pfade reparieren, Quellcode lesen. Der Skill mag exzellent sein; die Tür dazu ist kaputt.

Triggert zuverlässig (von 5). Eine 5 ist fünf von fünf in der Batterie: alle drei positiven Formulierungen feuern, beide Negativen bleiben still. Eine 2 feuert nur bei Wortwahl, die aus der eigenen README übernommen wurde, oder feuert bei unbeteiligter Arbeit, oder beides. Häufige Ursache in beiden Richtungen: ein Beschreibungsfeld, geschrieben, um Menschen zu beeindrucken, statt das Modell zu informieren.

Output vs. Baseline (von 10). Eine 9 oder 10 bedeutet, das Ergebnis mit Skill ist bei einer echten Aufgabe unverkennbar besser, die Art Unterschied, den du auch ohne Scorecard bemerken würdest. Eine 4 bedeutet, wir mussten genau hinschauen. Eine 2 bedeutet, der Baseline-Lauf war genauso gut oder besser, was häufiger vorkommt, als Autoren glauben möchten.

Doku und Ehrlichkeit (von 5). Eine 5 bedeutet, die README entspricht der Realität: akkurate Behauptungen, deklarierte Abhängigkeiten, nichts Verschwiegenes. Eine 2 bedeutet Versprechen, die der Skill nicht halten kann, oder Verhalten, das die Doku nie erwähnt.

Output wird von 10 bewertet, während alles andere von 5 bewertet wird, und diese Gewichtung ist bewusst: Output-Qualität ist so viel wert wie alle anderen Kriterien zusammen. Installationsprobleme haben Workarounds. Trigger-Probleme lassen sich durch das Bearbeiten eines Beschreibungsfelds patchen. Aber ein Skill, dessen Output die Baseline nicht schlägt, ist auf keine relevante Weise reparierbar. Die anderen Scores messen, ob du den Wert erreichen kannst. Der Output-Score misst, ob es überhaupt einen gibt.

Zwei Tests aus dem Log: eine 24 und eine 17

Zahlen bedeuten mehr mit den dazugehörigen Tests. Hier einer von jedem Ende der veröffentlichten Bandbreite.

Systematic-debugging, aus Jesse Vincents Superpowers-Sammlung, erzielte 24 von 25: Installation 5, Trigger 5, Output 9, Doku 5. Die Installation sind zwei Plugin-Befehle, die exakt wie geschrieben funktionierten, und die Trigger-Batterie ging fünf von fünf durch. Der Baseline-Lauf ist der Teil, den wir im Gespräch immer noch erwähnen: Wir gaben ihm eine Race Condition, die das Baseline-Claude bereits dreimal "gefixt" hatte, jeder Fix eine Vermutung, die das Symptom nur verschob. Mit geladenem Skill hörte Claude auf zu raten. Es bildete eine Hypothese, schrieb einen Test, um sie zu prüfen, sah den Test fehlschlagen und lief diese Schleife ab, bis es die tatsächliche Grundursache fand. Die Doku verspricht einen disziplinierten Debugging-Prozess, und genau das haben wir beobachtet. Er ist seither ein Fixpunkt auf unserer Coding-Seite.

Proposal-builder, ein Community-Skill, erzielte 17: Installation 3, Trigger 4, Output 7, Doku 3. Der erste Lauf war schlicht ein Fehlschlag. Out of the box, auf einem sauberen Profil, konnte er nicht liefern, was seine README verspricht: Der polierte .docx-Output hängt still davon ab, dass der docx-Skill installiert ist, und die gebrandete Formatierung hängt von einer Proposal-Vorlage ab, die die README kaum erwähnt. Folgt man den Anweisungen wörtlich, wie eine neue Nutzerin es täte, bekommt man eine Wand aus Markdown, wo ein Angebot stehen sollte. Nachdem wir den Begleit-Skill installiert und eine Vorlage eingerichtet hatten, stellte er ein wirklich nützliches gebrandetes Angebot aus Gesprächsnotizen und Preisen zusammen. Die Fähigkeit ist echt. Der Weg dorthin steht nicht in der README, und die Scores sagen genau das, bis hin zu den fehlenden Schritten, die in den Testnotizen aufgeschlüsselt sind.

Diese Lücke ist die, die die Sternezahl nicht sehen kann. Beide Repos wirken von außen kompetent. Eines funktioniert in dem Moment, in dem man seinen eigenen Anweisungen folgt. Das andere funktioniert nur, wenn man bereits weiß, was es zu erwähnen vergessen hat.

Was ein Urteil bedeutet

Die Scores rollen zu einem von drei Urteilen zusammen. Das mittlere verwirrt Leute, also seien wir präzise.

Bestanden bedeutet, der Skill installierte nach den eigenen Anweisungen des Autors, triggerte korrekt und schlug die No-Skill-Baseline bei einer echten Aufgabe. Von den 73 Skills im Katalog tragen 35 dieses Urteil.

Funktioniert mit Setup bedeutet, der Skill liefert echten Wert, aber nicht out of the box. Er braucht zuerst einen Begleit-Skill oder einen Konfigurationsschritt, und der Eintrag sagt, welchen. Zehn Skills stehen hier, und das Urteil ist kein Euphemismus für Versagen. Manche Skills brauchen Setup per Design: Ein Marken-Richtlinien-Skill soll nutzlos sein, bis du deine Palette und Stimme eingetragen hast, und ein Pipeline-Review-Skill kann keine Pipeline reviewen, die er nicht sehen kann. Das Urteil existiert, damit du weißt, was eine ehrliche halbe Stunde Konfiguration bringt, bevor du sie investierst.

In der Testwarteschlange bedeutet, wir haben den Skill gelistet, weil er vielversprechend aussieht, und haben das Testen noch nicht abgeschlossen. Kein Urteil ist in irgendeine Richtung impliziert; 28 Skills warten. Skills, die den Test klar nicht bestehen, werden auch nicht still gelöscht: Die Testnotizen sagen, was wir ausprobiert haben und was kaputtging, denn ein dokumentierter Fehlschlag ist nützlicher für dich als eine Lücke im Katalog.

Retesten, weil Claude sich ständig ändert

Ein Urteil ist eine Momentaufnahme, und der Boden darunter bewegt sich. Skills sitzen auf einem Modell, und Modelle werden aktualisiert. Eine Beschreibung, die in einem Claude-Code-Release zuverlässig triggerte, kann im nächsten anfangen fehlzuzünden, weil Triggering davon abhängt, wie das Modell Beschreibungen liest, und diese Lesart verschiebt sich. Drift ist nicht hypothetisch; wir haben beobachtet, wie ein zuverlässiger Skill nach einem Release anfing, eine seiner drei positiven Formulierungen zu ignorieren, ohne dass sich am Skill ein einziges Zeichen geändert hätte.

Also trägt jeder Eintrag ein Testdatum und die Claude-Code-Version, und größere Releases setzen die ganze Bestanden-Liste zurück in die Retest-Warteschlange, meistinstallierte Skills zuerst. Ändert sich ein Urteil, ändert sich der Eintrag. Ein alterndes Testdatum ist dein Hinweis, das Urteil entsprechend zu gewichten; das sind die ehrlichen Kosten, gegen eine sich bewegende Plattform zu testen.

Was wir nicht testen, und wo die Methode schwach ist

Ein Protokoll, das man nicht kritisieren kann, ist ein Protokoll, das niemand ehrlich beschrieben hat. Die bekannten Grenzen:

Beispielaufgaben können nicht jede Nutzung abdecken. Wir führen ein oder zwei echte Aufgaben pro Skill aus, ausgewählt, um repräsentativ zu sein, und ein Skill, der bei unserer 40.000-Zeilen-Tabelle glänzt, kann bei deiner 400.000-Zeilen-Tabelle trotzdem stolpern. Das Urteil ist Evidenz, nie eine Garantie.

Der Doku-Score stützt sich auf das Urteil einer einzelnen Testperson. Eine SKILL.md auf Ehrlichkeit zu lesen ist näher an Redigieren als an Messen, und zwei sorgfältige Leser können denselben vagen Satz unterschiedlich gewichten. Wir veröffentlichen Testnotizen teils, damit du uns prüfen kannst.

Wir testen nicht im großen Maßstab oder über lange Zeiträume. Eine saubere Maschine, Tage statt Monate. Langsame Verschlechterung und Workflows mit mehreren Skills gleichzeitig liegen derzeit außerhalb der Reichweite der Methode.

Sicherheitsreview ist ein Lesen, kein Audit. Wir prüfen auf nicht offengelegte Netzwerkaufrufe und injektionsförmige Anweisungen, aber ein entschlossener böser Akteur könnte etwas an einem manuellen Lesen vorbeischmuggeln. Behandle unseren Doku-Score als Filter, und bleib wachsam bei allem, was Zugangsdaten berührt.

Und die Baseline selbst bewegt sich. "Schlägt nacktes Claude" bedeutet nacktes Claude zum Testdatum; wenn sich das Basismodell verbessert, werden manche bestandenen Skills ihre Delta gegen null schrumpfen sehen. Ein weiterer Grund, warum Retesten nicht optional ist.

Das Protokoll an deinem eigenen Skill laufen lassen

Willst du gleich einen Skill veröffentlichen, dauert eine verkürzte Version davon etwa eine Stunde und bringt dich vor die halbe Konkurrenz im Ökosystem.

1. Frisches Profil. Leeres Skills-Verzeichnis, Standardeinstellungen. Deine tägliche Maschine versteckt deine Bugs.
2. Installier nur nach deiner README. Besser: Gib die README jemandem, der das Repo nie gesehen hat, und schau zu. Jede Frage, die er stellt, ist ein fehlender Satz.
3. Führ die Fünf-Prompt-Batterie aus. Drei Formulierungen, die triggern sollten, einschließlich einer, die nie deine Schlüsselwörter nutzt, plus zwei angrenzende Prompts, die es nicht sollten. Behebe Fehltreffer durch Umschreiben des Beschreibungsfelds, nicht durch Hinzufügen von README-Vorbehalten.
4. Mach den Baseline-Vergleich. Dieselbe Aufgabe, mit und ohne deinen Skill. Kannst du die Outputs nicht auseinanderhalten, überdenk, wofür der Skill da ist, bevor du veröffentlichst.
5. Lies deine SKILL.md noch mal als Skeptiker. Jede Behauptung, die du nicht belegen kannst, streich. Jede Abhängigkeit, deklariere.
6. Lint das Format. Frontmatter-Fehler sind die vermeidbarste Fehlerklasse, die wir sehen, und ein Validator erwischt sie in Sekunden.

FAQ

Wie lange dauert es, einen Claude Skill zu testen?

Der verkürzte Selbsttest dauert etwa eine Stunde. Unser vollständiges Protokoll läuft 45 Minuten für einen einfachen Dokument-Skill und bis zu einer Woche für Skills, deren Wert sich erst über Zeit zeigt, wie Wochenrückblick-Skills. Die Trigger-Batterie dauert Minuten; der Baseline-Vergleich ist, wo die Stunden hingehen.

Kann ich einen Skill ohne zweite Maschine testen?

Ja. Du brauchst ein sauberes Profil, keine saubere Hardware. Richte Claude Code auf ein leeres Skills-Verzeichnis (oder verschieb deins beiseite), und du bekommst die Isolation, die zählt: keine anderen Skills, die um Trigger konkurrieren, keiner, der still für den getesteten mitdeckt.

Was ist der häufigste Grund, warum Skills den Test nicht bestehen?

Output, der die Baseline nicht schlägt, bei etwa 35 % der Fehlschläge, mit kaputten Installationen dicht dahinter bei 30 %. Die Installationsfehler schmerzen am meisten, weil sie am günstigsten zu vermeiden sind: Der Autor hat die eigene README nie auf einer Maschine ausprobiert, die nicht seine war.

Wie bekomme ich meinen Skill getestet und bei SkillProof gelistet?

Reich ihn hier ein mit dem Repo-Link. Er kommt in die Entdeckungswarteschlange, wird nach Zugkraft und Kategorie-Passung triagiert, und durchläuft dann das Protokoll auf dieser Seite. Führ den Selbsttest zuerst durch, und deine Chancen auf ein Bestanden steigen, weil du dieselben Mängel findest, die wir finden würden.

Das Protokoll ist nicht clever. Es ist eine saubere Maschine, eine README beim Wort genommen, fünf Prompts, ein ehrlicher Vergleich. Was es funktionieren lässt, ist, dass niemand sonst in der Pipeline auch nur so viel tut: Autoren testen auf ihrer eigenen Maschine, und Sterne messen Begeisterung. Die Lücke zwischen beidem ist, wo dieser tote Produktivitäts-Skill von Ende 2025 lebte. Wir schließen sie weiter, eine Installation nach der anderen.