Claude Skills prüfen: Warum 5 von meinen 32 Skills durchgefallen sind

Einen fremden Claude Skill prüfst du mit einem einzigen Befehl: skillspector scan <Ordner oder Adresse> --no-llm. Der Scanner heißt SkillSpector, kommt von NVIDIA, ist kostenlos und braucht rund dreißig Sekunden pro Skill. Ich habe ihn über mein komplettes Setup laufen lassen: 32 Skills, davon 24 selbst gebaut und 8 aus dem Netz geladen. Ergebnis waren 176 Funde und fünf Skills mit der Ansage „nicht installieren“ — drei davon habe ich selbst geschrieben. Der wichtigere Teil dieses Beitrags ist aber nicht der Befehl, sondern was danach kommt: Ein guter Teil dieser Funde ist Fehlalarm, und wer das nicht weiß, wirft entweder das Werkzeug weg oder deinstalliert aus Panik das Falsche.

Im Video gehe ich die vier interessantesten Funde aus meinem eigenen Lauf am Bildschirm durch — inklusive dem Skill, den der Scanner gar nicht erst prüfen wollte.

Inhalt

• Was ein Skill wirklich ist: ein Zettel mit Schlüsselbund
• Wie viele Skills tatsächlich Schwachstellen haben
• Der Scan in zwei Zeilen — und die vier Fälle
• Der Selbsttest: 32 Skills, 176 Funde, ein unangenehmer Ordner
• Treffer oder Rauschen? Die Regel, die alles entscheidet
• Warum 100 von 100 nichts über Bösartigkeit sagt
• Was der Scanner nicht prüft
• Wenn im Betrieb mehrere mit KI arbeiten

Was ein Skill wirklich ist: ein Zettel mit Schlüsselbund

Ein Skill sieht in der Dateiliste aus wie eine Textdatei. Das ist der Grund, warum ihn kaum jemand prüft. Tatsächlich sind es zwei Dinge in einem Paket: eine Arbeitsanweisung, die deine KI liest und befolgt, und ein Bündel Skripte, die dabei ausgeführt werden, samt der Ordner, die sich dabei öffnen.

Ein Zettel mit Arbeitsanweisung, an dem ein Schlüsselbund hängt. Du installierst den Zettel und übergibst den Bund gleich mit. Und ab dann arbeitet der Skill mit deinen Rechten — er sieht, was du siehst, und darf, was du darfst.

Wie viele Skills tatsächlich Schwachstellen haben

Dazu gibt es Zahlen. Eine Untersuchung von Anfang 2026 hat 31.132 Skills von zwei großen Marktplätzen automatisiert geprüft. 26,1 Prozent enthalten mindestens eine Schwachstelle, 5,2 Prozent sehen nach Absicht aus (Liu et al., „Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale“, arXiv 2601.10338, eingereicht am 15.01.2026 — Stand: 2026-09-03).

Also: jeder vierte Skill hat eine Lücke, jeder zwanzigste ist vermutlich mit Absicht gebaut. Das ist keine Panikzahl, sondern ein guter Grund, dreißig Sekunden zu investieren, bevor du etwas installierst.

Der Scan in zwei Zeilen — und die vier Fälle

Installiert wird einmal, danach ist es eine Zeile pro Skill. Der Schalter --no-llm lässt den Scanner rein statisch laufen: kein API-Schlüssel, keine Kosten, keine Daten, die irgendwohin gehen.

uv tool install git+https://github.com/NVIDIA/skillspector.git

# Skill, den du schon hast
skillspector scan ~/.claude/skills/mein-skill/ --no-llm

# Besser: VOR dem Download direkt die Adresse prüfen
skillspector scan https://github.com/autor/skill-name --no-llm

Der zweite Fall ist der eigentliche Gewinn. Du prüfst die Adresse, ohne dass etwas auf deinem Rechner landet. Was du bekommst, ist eine Zahl zwischen null und hundert, eine Einstufung und eine Liste von Funden, jeder mit Datei, Zeile und Kürzel.

Der Selbsttest: 32 Skills, 176 Funde, ein unangenehmer Ordner

Ich habe nicht ausgewählt, sondern alles gescannt, was bei mir liegt. 176 Funde, 80 davon in der höchsten Stufe, fünf Skills mit „nicht installieren“. Drei dieser fünf sind meine eigenen. Das ist unangenehm, aber es ist der beste Lehrfall, den ich anbieten kann — denn ich weiß bei meinen eigenen Skills genau, was drinsteht, und kann deshalb Zeile für Zeile sagen, was echt ist und was nicht.

Der Fund, bei dem mir kurz anders geworden ist: In einem meiner Skills liegt ein Ordner mit vorkompiliertem Python — Maschinencode, kein lesbarer Text. Der Scanner meldet ihn nicht, weil dort etwas Böses steckt, sondern weil solche Ordner bei der normalen Prüfung übersprungen werden. Genau deshalb wäre es der ideale Platz für etwas, das keiner sehen soll, während der sichtbare Quelltext daneben blitzsauber aussieht. Bei mir ist es Beifang vom Programmieren. In einem fremden Skill wäre es die Stelle, an der ich abbreche.

Der zweite: Ein Skript von mir liest die Datei, in der meine Zugangsschlüssel liegen. Der Scanner stuft das als Zugriff auf Zugangsdaten ein, höchste Stufe. Sachlich völlig richtig. Bei mir ist es gewollt, weil das Skript Bilder von einem Stock-Anbieter holt und dafür einen Schlüssel braucht.

Warum braucht ein Skill, der angeblich nur Texte formatiert, deine Schlüsseldatei?

Das ist die Frage, die du bei jedem fremden Skill zu Ende denken musst. Nicht „liest er Schlüssel“, sondern „passt das zu dem, was er zu tun behauptet“.

Treffer oder Rauschen? Die Regel, die alles entscheidet

Jetzt die Seite, die in den meisten Empfehlungen fehlt. Ein Design-Skill, den ich mir aus dem Netz geladen hatte, kam auf 83 Punkte und „nicht installieren“. Ich habe alle neun Funde einzeln angesehen: vier davon sind HTML-Kommentare. Also Zeilen wie <!-- Loading Screen -->, die jeder Entwickler in seinen Beispielcode schreibt, damit man ihn versteht. Der Scanner erkennt darin eine versteckte Anweisung, weil sich versteckte Anweisungen tatsächlich gern in Kommentaren verstecken. Hier war es eben ein Kommentar in einem Lehrbeispiel.

Das ist der Punkt, an dem die meisten das Werkzeug wieder wegwerfen. Die bessere Reaktion ist eine Sortierregel:

• Abbrechen: Signaturen von Schadsoftware, ein Skill, der sich selbst verändert oder sich per Autostart einnistet, Zugangsdaten die ins Netz fließen, Code der aus dem Netz nachgeladen und ausgeführt wird, Anweisungen im Stil von „ignoriere deine Regeln“.
• Hinschauen: Zugriff auf Schlüssel und Umgebungsvariablen, vorkompilierter Code im Paket, Werkzeugzugriff ohne Grenzen, unsichtbare Zeichen in den Metadaten.
• Ignorieren: nicht angeheftete Paketversionen, unscharfe Auslöser, Kommentare in Beispieldateien.

Und darüber steht die eine Regel, die alles trägt: Halte jeden Fund gegen den Zweck des Skills. Wer Bilder von einer Stock-Seite holt, darf eine Schnittstelle rufen und einen Schlüssel lesen. Wer Texte formatiert, darf beides nicht. Nicht die Kategorie entscheidet, sondern die Kategorie im Verhältnis zur Aufgabe.

Warum 100 von 100 nichts über Bösartigkeit sagt

Der Score ist eine Addition, keine Bewertung. Jeder Fund der höchsten Stufe bringt 25 Punkte, ein kritischer 50, und enthält der Skill ausführbare Skripte, wird die Summe mit 1,3 multipliziert (Quelle: SkillSpector-Dokumentation, Version 2.11.0 — Stand: 2026-09-03).

Heißt im Klartext: Vier harmlose Meldungen der höchsten Stufe reichen für 100 von 100. Ein Skill mit Skripten ist praktisch nie grün. Deshalb liest du die Kategorien und nicht die Zahl — die Zahl sagt dir nur, wie viel Lesearbeit vor dir liegt.

Was der Scanner nicht prüft

Drei Stellen bleiben offen, auch wenn der Bericht grün ist.

• Deine Konfiguration. Ein Skill kann bei der Installation Einträge in deine lokale Konfigurationsdatei schreiben, die danach bei jedem Bearbeiten einer Datei etwas ausführen. Bei mir ist das passiert, harmlos, aber unangekündigt. Nach jeder Installation einmal hineinsehen.
• Verknüpfungen. Zeigt der Ordner nur auf einen anderen Ort, bricht der Scanner ab statt zu raten. Bei mir war ein Skill genau so gebaut, und die Meldung lautete wörtlich: Refusing to resolve a symlinked input. Kein Ergebnis ist kein grünes Licht.
• Spätere Änderungen. Geprüft ist immer nur der Stand von heute. Ein Update kann alles ändern.

Der abgebrochene Scan ist übrigens mein Lieblingsmoment aus dem ganzen Lauf. Ein Werkzeug, das im Zweifel „konnte ich nicht prüfen“ sagt, ist deutlich mehr wert als eins, das immer irgendwas Grünes anzeigt.

Wenn im Betrieb mehrere mit KI arbeiten

Als Einzelner entscheidest du selbst, was du installierst. In einem Betrieb mit fünf oder zwanzig Leuten sieht das anders aus. Es reicht, dass ein Kollege irgendwo einen Skill findet, der ihm Arbeit abnimmt. Er installiert ihn, weil er hilfreich ist. Geprüft hat ihn niemand.

Für Ordner mit Kundendaten braucht es dann kein böses Genie, sondern nur einen hilfsbereiten Zettel mit Schlüsselbund. Zwei Regeln reichen als Anfang: Legt fest, wer Skills installieren darf, und führt eine gemeinsame Liste der freigegebenen Skills. Wer darüber hinaus festlegen will, was die KI im Betrieb überhaupt allein entscheiden darf, braucht dieselbe Übung eine Ebene höher: klare Erlaubnis-Stufen statt Einzelfallentscheidungen.

Der Spickzettel für die Prüfung

Die Sortierarbeit ist der Teil, der im Alltag entscheidet. Deshalb habe ich sie zusammengefasst: alle Kategorien mit Kürzel und Handlungsempfehlung als Ampel-Liste, die Befehle zum Kopieren, die komplette Score-Formel und ein fertiger Prompt, mit dem du eine KI den Skill gegenlesen lässt. Sechs Seiten, kostenlos.

Und wenn du das Prüfen einmal machst, mach es an der richtigen Stelle: vorher, nicht nachher. Prüfen kostet dreißig Sekunden. Aufräumen kostet einen Tag.