Letzten Monat habe ich fast einen ganzen Freitag wegen eines „kampferprobten" Claude Code Skills verloren, den jemand in einem Discord geteilt hatte. Vierhundert Sterne. Das README hatte ein Diagramm. Es verschluckte auch jeden Fehler der API, die es umhüllte, sodass mein Agent munter weiterlief, als diese API anfing, 429-Fehler zurückzugeben. Selbstsicher. Und schrieb Müll in eine echte Tabelle, die ich dann manuell bereinigen musste.
Das ist ein schlechter Skill. Und ihn zu erkennen, bevor er irgendetwas Wichtiges berührt, ist still und leise zu einem Teil der Arbeit geworden. Es gibt jetzt Tausende davon, und sie alle sehen im Screenshot toll aus.
Hier ist die Checkliste, die ich durchgehe, bevor ich einem AI Agent Skill, einem MCP-Server oder einer Cursor-Regel vertraue. Keine Theorie. Die Dinge, die ich mir gewünscht hätte, vor jenem Freitag geprüft zu haben.
Was ein schlechter Skill wirklich ist
Ein schlechter Skill täuscht Kompetenz vor, die er nicht hat. Er ist darauf ausgelegt, adoptiert zu werden, nicht dafür, den Kontakt mit der Produktion zu überleben. Guter Name, selbstsicheres README, ein Demo-GIF, in dem die Sonne immer scheint. Dann fällt er in dem Moment auseinander, in dem die Realität aufhört, der Glückspfad zu sein.
Das Anzeichen ist die Lücke zwischen dem, wie poliert er aussieht, und wie wenig er tatsächlich mitgemacht hat. Code, der eine Weile in der Produktion lief, trägt Narben: seltsame Guard-Klauseln, ein Kommentar, der sagt „das nicht entfernen, auf die harte Tour gelernt," ein Retry, den jemand offensichtlich um 2 Uhr nachts hinzugefügt hat. Schlechte Skills haben nichts davon. Sie haben gutes Copywriting.
Man sieht es bei Claude Code Skills, Cursor-Regeln, MCP-Servern, Agent-Templates. Jeder kann an einem Nachmittag einen veröffentlichen, und ein Modell schreibt bereitwillig ein überzeugendes README dazu. Das Angebot stieg vertikal. Die Qualität bewegte sich nicht.
Wie man einen AI Agent Skill prüft: Die 5-Punkte-Überprüfung
Ich lese nicht die ganze Sache von oben nach unten. Ich gehe auf die Jagd nach bestimmten Gerüchen, in dieser Reihenfolge.
1. Behandelt er den unglücklichen Pfad? Ich mache grep nach Fehlerbehandlung, bevor ich irgendeine Hauptlogik lese. Kein try/catch, keine Fehlerverzweigungen, keine Retries, kein Timeout? Dann wurde er gegen ein Demo geschrieben und gegen ein Demo getestet. Ein Skill, der dem Modell nicht sagen kann „das ist fehlgeschlagen, hier ist der Grund, Stopp," lässt deinen Agent mitten durch den Fehler halluzinieren. Das ist die gefährliche Art. Er crasht nicht. Er lügt, und er klingt dabei großartig.
2. Sagt er dem Modell, wann es NICHT handeln soll? Fast niemand prüft das. Ein guter Skill baut Grenzen in seine Anweisungen ein: wann er abbrechen soll, wann er zuerst fragen soll, was er niemals anfassen darf. Schlechte Skills beschreiben nur das, was sie gut machen. Kein „wenn du unsicher bist, Stopp." Gib das einem autonomen Agent und du hast einem Ding ein Elektrowerkzeug gegeben, das keine Ahnung hat, wo seine eigenen Hände sind.
3. Werden Eingaben validiert oder nur angenommen? Finde heraus, wo Daten hereinkommen. Wird irgendetwas überprüft? Schlechte Skills setzen voraus, dass das Modell immer sauberes JSON zurückgibt, die Datei immer existiert, das Feld immer befüllt ist. Produktion ist genau der Ort, wo dieses Feld null zurückgibt, während du schläfst.
4. Was war der letzte Commit, und was enthielt er? Ein Skill, der acht Monate lang unberührt war und auf Tooling liegt, das monatlich Breaking Changes veröffentlicht, ist ein Fossil. Lies auch, was die Commits wirklich sagen. Alles „update README" und kein „fix edge case"? Niemand führt ihn wirklich aus. Echter Einsatz erzeugt echte Bug-Fixes. Das Commit-Log wird die Wahrheit sagen, die das README nicht sagen wird.
5. Was ist der Explosionsradius? Die dümmste Frage, der größte Gewinn. Was kann dieses Ding wirklich anfassen? Ein Skill, der behauptet, deine Commit-Nachrichten zu formatieren, aber still Schreibzugriff auf das gesamte Repository plus Netzwerk-Egress hält, ist eine Haftung in einem nützlichen Kostüm. Der Umfang muss zur Aufgabe passen. Wenn er das nicht tut, ist das die ganze Geschichte.
Das meiste davon geht schnell. Ein paar Greps und ein Blick auf die Commit-Historie fängt den offensichtlichen Müll ab, bevor ich echte Zeit investiert habe.
Der Teil, der dich wirklich kostet
Hier ist das Ding beim richtigen Prüfen von Skills. Das Auditing ist nicht schwer. Es ist das Volumen, das dich zermürbt, und es hört nicht auf.
Du prüfst nie nur einen. Du wählst aus neun, die alle behaupten, dieselbe Aufgabe zu erledigen, und sie sind verstreut. GitHub. Zwei verschiedene Discord. Ein paar „awesome-skills"-Listen, die im Frühjahr veraltet sind. Ein Reddit-Thread. Jemandes Blogpost. Jeder Kandidat möchte das Grep, den Commit-Geruch, die Umfangsprüfung, den Issues-Tab, um zu sehen, ob jemand bereits den Bug getroffen hat, über den man sich Sorgen macht. Jeder ist ein frischer Stapel Tabs.
Ich habe einmal versucht, das wirklich zu erfassen. Ich brauchte einen einzigen anständigen Skill für eine MCP-Integration. Die Kandidaten finden, jedes Repository öffnen, die verdächtigen Teile lesen, Issues prüfen, herausfinden, welcher Fork aktiv ist und welcher aufgegeben wurde. Ich zählte irgendwo um die neun Stunden über zwei Tage. Für einen einzigen Slot in meiner Toolchain.
Und die Antwort wird alt. Der Skill, den ich gewählt hatte, war im Mai solide. Ist er es noch? Keine Ahnung, und nichts sagt es mir. Sterne sind eine Beliebtheitswahl, die in der Vergangenheit eingefroren ist. Download-Zahlen wissen nicht, ob das Ding letzten Dienstag kaputt ging, als die Upstream-API ihre Response-Form änderte. Es gibt nirgends ein Signal für „dieser hat angefangen, diese Woche zu versagen." Also werde ich das gesamte Audit im nächsten Quartal von vorne machen.
Jeder Entwickler, mit dem ich darüber gesprochen habe, beschreibt dieselbe Routine. Öffnen, greppen, die Commits zusammenkneifen, hoffen. Allein. Die Notizen von niemandem gehen auf jemand anderen über. Wir alle entdecken privat neu, einen verschwendeten Freitag nach dem anderen, dass derselbe beliebte Skill still seine Fehler frisst.
Das Fazit
Die Checkliste funktioniert. Fehlerbehandlung. Stoppbedingungen. Eingabevalidierung. Die Wahrheit im Commit-Log. Explosionsradius. Führe sie durch und du wirst dem meisten Schaden ausweichen. Klebe sie über deinen Monitor, wenn du möchtest.
Aber führe sie ein paar Monate lang durch und das eigentliche Problem taucht auf. Das Suchen ist nicht der teure Teil. Die Jagd ist es, und die Tatsache, dass du sie allein machst, jedes Mal, gegen eine Liste, die niemand aktuell hält.
Ein Skill, der produktionsbereit aussieht, und einer, der es ist, liegen etwa zehn Minuten Lesezeit auseinander. Das Problem ist, dass fast niemand zehn freie Minuten und einen vertrauenswürdigen Ausgangspunkt hat.
Überprüfe den Explosionsradius zuerst. Das ist die günstigste Frage, und sie ist die, die mich gerettet hat, als keine andere es getan hat.