Wie viele Claude Skills sollten Sie installieren?

Weniger als man denkt. Für die meisten, die normale Arbeit in Claude Code erledigen, liegt die Zahl, die sich über Monate bewährt, bei fünf bis acht aktiv genutzten Skills, ohne die, die in einem Plugin gebündelt sind und die man nicht einzeln ausgewählt hat. Das ist keine starre Obergrenze. Es ist der Punkt, an dem das Portfolio, auf das man tatsächlich zugreift, nicht mehr wächst, egal wie viele weitere man installiert.

Der Grund für die geringe Anzahl ist nicht die Unordnung in einer Ordneransicht. Jeder Skill, den man installiert, ob man ihn nutzt oder nicht, platziert seine Trigger-Beschreibung bei jeder Anfrage, für immer, vor Claude. Jede zusätzliche Beschreibung ist eine weitere Sache, die Claude korrekt ignorieren muss. Ab einem bestimmten Punkt erhöht das Hinzufügen von Skills nicht die Funktionalität. Es fügt Rauschen hinzu, gegen das die guten Skills ankämpfen müssen.

Dieser Beitrag beleuchtet die Arithmetik hinter dieser Zahl: was ein installierter, aber ungenutzter Skill kostet, warum zwei überlappende Skills schlechter sind als jeder einzelne allein, und die Portfolio-Struktur, die wir selbst verwenden, nachdem wir 73 davon katalogisiert und getestet haben.

Was ein installierter Skill tatsächlich kostet

Skills werden in zwei Stufen geladen. Beim Start einer Sitzung liest Claude nur das Frontmatter, den name und die description, jedes Skills, den es finden kann, typischerweise 50 bis 150 Tokens pro Skill. Diese Metadaten verbleiben für die gesamte Sitzung im Kontext, unabhängig davon, ob der Skill jemals ausgelöst wird. Der vollständige Inhalt, die eigentlichen Anweisungen, wird nur geladen, wenn eine Anfrage der Beschreibung entspricht. Das ist progressive Offenlegung, und es ist der Grund, warum Skills besser skalieren als eingefügte Prompts. Den Mechanismus haben wir in was Claude Skills sind behandelt.

Der ständig aktive Teil ist der, den man zu zählen vergisst. Angenommen, man hat 30 Skills installiert, mit durchschnittlich 100 Tokens Frontmatter pro Skill: Das sind 3.000 Tokens, die bei jeder Nachricht, jedem Turn, jeder Sitzung vor Claude stehen, unabhängig davon, ob sie relevant sind oder nicht. Bei 30 Turns in einer Arbeitssitzung sind das 90.000 Tokens, die für das erneute Lesen einer Metadatenliste aufgewendet werden, bevor Claude etwas tut, das man angefordert hat. Über 22 Arbeitstage hinweg sind das fast 2 Millionen Tokens pro Monat an reiner 'Stehzeit'-Gebühr. Nichts davon ist für sich genommen teuer, ein paar Cent zu Sonnet-Tarifen. Aber es konkurriert um Platz im Kontextfenster und summiert sich mit allem anderen, was mitläuft: CLAUDE.md, MCP tool schemas, Sitzungsverlauf. Die vollständige Aufschlüsselung haben wir in Claude Token-Kosten senken vorgenommen.

Die größeren Kosten sind nicht monetär. Es ist Aufmerksamkeit. Claude entscheidet, welcher Skill geladen werden soll, indem es die Anfrage mit einem Stapel von Beschreibungen abgleicht. Dieser Abgleich wird unzuverlässiger, je größer der Stapel wird und je mehr sich Beschreibungen im Vokabular überlappen. Ein Skill, den man im März installiert und seitdem nicht mehr verwendet hat, befindet sich immer noch in diesem Stapel, jedes Mal, wenn man im April etwas anfordert. Er macht den korrekten Abgleich stillschweigend zu einer Option von 41 statt einer Option von 8.

Das Kollisionsproblem: zwei Skills, eine Anfrage

Installiert man genügend Skills, werden irgendwann zwei davon dieselbe Aufgabe mit unterschiedlichen Worten beschreiben. Das ist keine Hypothese. Wir stießen darauf, als wir unseren eigenen Testkatalog erstellten: Zwei nebeneinander installierte Marketing-Pakete lieferten beide einen Skill für Outreach-Texte, cold-email und email-sequences, mit Beschreibungen, die sich so weit überlappten, dass ein einziger Prompt wie "schreibe mir eine Follow-up-E-Mail" plausibel zu beiden passen konnte.

Wenn das passiert, tritt eines von drei Dingen ein, und keines davon wird einem mitgeteilt. Claude wählt stillschweigend einen aus, basierend darauf, welche Beschreibung als geringfügig bessere Übereinstimmung für die genaue Formulierung erscheint, sodass derselbe Prompt, auf zwei verschiedene Arten gestellt, zwei verschiedene Skills auslösen kann. Oder eine harte Kollision im name-Feld bedeutet, dass ein Skill den anderen vollständig überschattet; der zweite wird einfach nie geladen, und man erhält keine Fehlermeldung darüber. Oder, im schlimmsten Fall, versucht Claude, beide partiellen Übereinstimmungen gleichzeitig zu erfüllen und erzeugt eine Ausgabe, die aus zwei Anweisungssätzen zusammengesetzt ist, die nie zur Zusammenarbeit konzipiert waren: der E-Mail-Skill und der Tone-of-Voice-Skill versuchen beide, denselben Satz zu 'besitzen'.

Die Lösung ist diagnostisch, nicht präventiv, denn man weiß im Allgemeinen nicht, dass zwei Skills kollidieren, bis es passiert. Die vollständige Sechs-Punkte-Checkliste dafür haben wir in Claude Skill löst nicht aus beschrieben, aber die Kurzversion speziell für die Portfoliogröße lautet: Wenn man nicht in einem Satz erklären kann, warum Skill A eine Anfrage statt Skill B bearbeitet, überlappen sie zu stark, um beide installiert zu bleiben. Man sollte sie zusammenführen, einen löschen oder die schwächere Beschreibung umschreiben, um einen engeren, nicht überlappenden Teil der Aufgabe herauszuarbeiten. Die Anzahl der Kollisionen in einem Portfolio skaliert ungefähr mit dem Quadrat seiner Größe, was die mathematische Version von "halte es klein" ist.

Der Portfolio-Ansatz: Anker, Situative, Experimente

Sobald man akzeptiert, dass jeder installierte Skill laufende Kosten verursacht, verschiebt sich die Frage von "soll ich das installieren" zu "in welche Kategorie gehört es". Wir ordnen unsere eigenen in drei Kategorien ein.

• Anker sind die zwei bis fünf Skills, deren Fehlen man innerhalb eines Tages bemerken würde. Dokumentengenerierung, wenn man wöchentlich Berichte schreibt. Eine Debugging-Disziplin, wenn man täglich Code schreibt. Ein Ton- oder Bearbeitungs-Skill, wenn die Arbeit aus Worten besteht. Diese erhalten ein dauerhaftes Zuhause in ~/.claude/skills/, sind in jedem Projekt verfügbar, und sie sind die einzige Kategorie, die es wert ist, auf Vertrauen installiert zu werden, bevor man bewiesen hat, dass der Trigger speziell für einen funktioniert.
• Situative Skills sind real und nützlich, aber auf einen Kontext beschränkt: eine Migrations-Checkliste für eine Codebasis, die spezifische Markenstimme eines Kunden, ein Compliance-Skill, den nur das regulierte Projekt benötigt. Diese gehören in den .claude/skills/-Ordner eines Projekts, nicht in den persönlichen. Sie reisen mit dem Repo, sind für Teamkollegen sichtbar, die es klonen, und entscheidend ist, dass ihre Beschreibung nur in Sitzungen um Aufmerksamkeit konkurriert, in denen sie tatsächlich relevant sind. Die globale Installation eines kundenspezifischen Skills bedeutet, dass seine Beschreibung auch bei jedem anderen, nicht verwandten Projekt, das man bearbeitet, mitgeführt wird.
• Experimente sind alles, was man ausprobiert, weil ein Kollege es empfohlen hat oder ein Katalogeintrag gut bewertet wurde. Man sollte diesen eine feste Zwei-Wochen-Frist ab der Installation geben. Wenn man einen Skill nicht unaufgefordert, natürlich und ohne besonderen Aufwand zum Testen verwendet hat, sollte man ihn nach zwei Wochen löschen. Die meisten Experimente bestehen diesen Test nicht, und das ist in Ordnung; dafür ist die Testphase da. Der Fehler ist nicht das Ausprobieren von Skills, sondern das stille Befördern ungetesteter Skills in den permanenten Ankerstatus, nur weil das Löschen eines Ordners sich anfühlt, als hätte das Experiment versagt.

Diese Struktur beantwortet auch die Frage "wie viele" nützlicher als eine einzelne Zahl. Es ist nicht "man installiert insgesamt 6 Skills". Es ist "man hält seine Anker auf das beschränkt, was man wirklich vermissen würde, man beschränkt situative Skills auf das, wo sie relevant sind, und man setzt ein Ablaufdatum für alles andere".

Was auf unserer eigenen Bank überlebt hat

Wir testen jeden Skill im SkillProof-Katalog auf einer sauberen Installation, bevor er ein Urteil erhält. Separat davon werden einige dieser getesteten Skills zu denen, die wir tatsächlich täglich nutzen, Monate nachdem die Rezension veröffentlicht wurde. Diese zweite Liste ist kurz, und sie ist gerade deshalb informativ, weil sie kurz ist.

• DOCX (9.6/10) ist der Skill, dessen Fehlen wir am schnellsten bemerken würden. Anthropic's eigener Referenz-Skill, und der Grund ist unspektakulär: Wir erstellen die meisten Wochen Word-Dokumente, und er schreibt echte Dokumente, Inhaltsverzeichnisse, nachverfolgte Änderungen, Briefköpfe intakt, anstatt Markdown, das wir manuell neu formatieren müssten.
• Systematic Debugging (9.6/10) und Test-Driven Development (9.6/10), beide aus der Superpowers-Sammlung, sind das Paar, das die Art und Weise, wie unsere eigenen Sitzungen ablaufen, verändert hat, anstatt nur das Ergebnis. Keine Skripte, keine externen Tools, reine Verhaltensänderung: Red-Green-Refactor wird jedes Mal durchgesetzt, eine Debugging-Disziplin, die Claude nicht erlaubt, eine Lösung zu erraten, bevor der Fehler reproduziert wurde. Dies sind die klarsten Fälle in unserem Katalog, in denen ein Skill allein aufgrund der Ausgabe den Ankerstatus verdient.
• Memory Management (9.2/10) verdient seinen Platz, indem es auf die beste Weise unsichtbar ist: Es verhindert, dass Kontext zwischen Sitzungen verloren geht, ohne dass wir eine Notizdatei manuell verwalten müssen.

Beachten Sie, was fehlt. Unser Katalog enthält 73 Skills; 35 haben ein klares "pass"-Urteil. Wir nutzen vielleicht acht dieser 35 als echte tägliche Anker. Die anderen 27 sind gut, getestet und ehrlich in dem, was sie tun, und die meisten befinden sich für uns immer noch im situativen oder experimentellen Status, denn "getestet und gut" und "gehört zu Ihren permanenten fünf bis acht" sind unterschiedliche Maßstäbe. Ein Skill kann in einer Rezension 9/10 Punkte erreichen und trotzdem falsch sein, wenn er global installiert bleibt, wenn man seinen Anwendungsfall nur zweimal im Quartal nutzt.

Das monatliche Aufräumritual

Portfolios driften ab. Ein für ein Projekt installierter Skill überdauert das Projekt. Ein Experiment überlebt seine Zwei-Wochen-Frist, weil das Löschen von Dingen niemandes Lieblingsaufgabe ist. Die Lösung ist ein wiederkehrender Zehn-Minuten-Durchlauf, keine einmalige Bereinigung.

Einmal im Monat geht man dies durch:

1. Man listet auf, was tatsächlich installiert ist. ls ~/.claude/skills/ und ls .claude/skills/ für jedes Projekt, in dem man sich befindet. Wenn man einen Ordnernamen nicht erkennt, ist das bereits die Antwort.
2. Man fragt, wann jeder Skill zuletzt ausgelöst wurde. Wenn man sich nicht erinnern kann, ihn im letzten Monat verwendet zu haben, und es kein Anker ist, den man in Schüben nutzt (Steuersaison, Quartalsberichte), ist er ein Kandidat zum Entfernen.
3. Man überprüft auf Überlappungen. Man liest das description-Feld jedes Skills nebeneinander. Zwei, die plausibel denselben Prompt beantworten könnten, sind eine drohende Kollision; siehe den Abschnitt oben.
4. Man bestätigt, dass projektbezogene Skills tatsächlich projektbezogen sind. Alles, was spezifisch für einen Client oder ein Repo ist, hat in dem persönlichen Ordner nichts zu suchen, da es sonst bei jedem nicht verwandten Projekt mitgeführt wird.
5. Löschen, nicht archivieren. Ein irgendwo deaktivierter Skill darf nicht mit einem aktiven verwechselt werden. Wenn er seinen Platz nicht verdient, entfernt man den Ordner.
6. Man testet die Anker erneut. Man fragt nach etwas, das jeder Anker handhaben sollte, ohne ihn namentlich zu nennen, so wie wir Trigger für den Katalog testen. Wenn er nicht sauber auslöst, überschattet ihn wahrscheinlich etwas, das seitdem hinzugefügt wurde.

Zehn Minuten, einmal im Monat, und das Portfolio bleibt in einer nützlichen Größe, anstatt zu einer Größe anzuschwellen, die sich nur ansammelt.

Qualität schlägt Quantität

Dies ist die gesamte These von SkillProof, komprimiert in einem Abschnitt, und es ist hier wichtig, sie klar auszudrücken, denn "wie viele Skills" ist eigentlich ein Stellvertreter für eine andere Frage: Was ist der Grenzwert des nächsten Skills, den man installieren möchte?

Von den 45 Skills, die wir vollständig getestet haben, bestanden 35 sauber und 10 benötigten zusätzliche Einrichtung, um überhaupt zu funktionieren. Das ist keine Kritik am Ökosystem; das Format ist bewusst offen, jeder kann ohne Überprüfung veröffentlichen, weshalb es schnell gewachsen ist. Aber es bedeutet auch, dass der durchschnittliche Skill auf GitHub unüberprüft ist, und die Installation von zehn mittelmäßigen Skills ergibt nicht einen guten. Es summiert sich zu zehn Trigger-Beschreibungen, die mit den guten um dieselbe Übereinstimmung konkurrieren, zehn ungenutzten Metadatenblöcken bei jeder Anfrage und einer wachsenden Anzahl von Paaren, die sich stillschweigend gegenseitig behindern könnten. Wir haben uns ausführlich mit den spezifischen Fehlerursachen befasst – vage Beschreibungen, die nie auslösen, Ausgaben, die nicht besser sind als Claudes Standard, fehlende Einrichtungsschritte – in warum die Hälfte der Claude Skills nicht funktioniert.

Die praktische Version: Bevor man etwas installiert, sollte man sich fragen, ob es die Zwei-Wochen-Experimentierfrist überstehen würde und ob es etwas wesentlich Besseres leistet, als Claude unaufgefordert tun würde. Wenn man beides nicht mit Ja beantworten kann, kostet es nicht viel, es zu überspringen, aber es hilft auch nicht. Unsere Effizienz-Rankings sortieren getestete Skills speziell nach diesem "Output-über-Baseline"-Maßstab, was ein schnellerer Filter ist, als zwanzig READMEs selbst zu lesen.

FAQ

Gibt es eine harte Grenze für die Anzahl der Claude Skills, die man installieren kann?

Keine technische Obergrenze, die wir beim Testen erreicht haben. Claude scannt jeden Skill-Ordner, den es findet, und lädt das gesamte Frontmatter beim Sitzungsstart, egal ob es 5 oder 150 Skills sind. Die relevante Grenze ist keine von Claude erzwungene Barriere, sondern der Punkt, an dem die ständig aktive Metadaten-Gebühr und die steigende Wahrscheinlichkeit von Beschreibungsüberlappungen mehr kosten, als ein neuer Skill hinzufügt. Dieser Punkt liegt für die meisten Menschen tendenziell bei 30 bis 40 installierten Skills, lange bevor eine formatbezogene Obergrenze erreicht wird.

Verlangsamen ungenutzte Skills Claude oder kosten sie nur Tokens?

Hauptsächlich Tokens und Abgleichgenauigkeit, nicht die reine Latenz in dramatischer Weise. Das Frontmatter eines ungenutzten Skills befindet sich bei jedem Turn im Kontext, was geringe, aber reale Kosten verursacht, die sich über einen Monat summieren. Zudem ist es eine weitere Beschreibung, die Claude abwägen muss, wenn es entscheidet, was ausgelöst werden soll. Eine Handvoll ungenutzter Skills ist wirklich harmlos. Vierzig davon sind eine andere Geschichte, hauptsächlich weil die Wahrscheinlichkeit, dass ein veralteter Skill eine wichtige Anfrage überschattet oder nur teilweise abgleicht, mit der Anzahl steigt.

Wie weiß man, ob ein installierter Skill tatsächlich verwendet wird?

Man fragt nach etwas, das er handhaben sollte, ohne ihn namentlich zu nennen, derselbe Trigger-Test, den wir für jeden Katalogeintrag durchführen. Wenn sich Claudes Verhalten sichtbar ändert, zum Beispiel ein echtes .docx anstelle von eingefügtem Markdown erzeugt wird, wurde er ausgelöst. Wenn sich nichts ändert, stimmt entweder die Beschreibung nicht mit der Art und Weise überein, wie man Anfragen formuliert, oder ein anderer Skill gewinnt den Abgleich zuerst. Unser Leitfaden "Skill löst nicht aus" enthält den vollständigen Sechs-Punkte-Prozess, um diese beiden zu unterscheiden.

Sollten persönliche und projektbezogene Skills gegen dieselbe Grenze zählen?

Man behandelt sie getrennt. Persönliche Skills in ~/.claude/skills/ werden bei jedem Projekt mitgeführt, das man bearbeitet, daher sollten sie die kurze Ankerliste sein, die man täglich vermissen würde, unabhängig vom Kontext. Projektbezogene Skills in .claude/skills/ laden ihr Frontmatter nur in Sitzungen innerhalb dieses Repositorys, sodass ein Projekt vernünftigerweise mehr situative Skills enthalten kann, ohne die andere Arbeit zu belasten. Der häufigste Fehler, den wir sehen, ist das Ablegen von client- oder repo-spezifischen Skills im persönlichen Ordner, wo sie jedes nicht verwandte Projekt für immer belasten.

Was ist der schnellste Weg, eine überladene Skill-Liste zu kürzen?

Man führt das monatliche Aufräumritual sofort einmal durch, anstatt auf den nächsten geplanten Durchlauf zu warten. Man listet alles Installierte auf, entfernt alles, von dem man sich nicht erinnern kann, dass es im letzten Monat ausgelöst wurde und kein bekannter, schubweise genutzter Anker ist, man überprüft die Verbleibenden auf Beschreibungsüberlappungen und verschiebt alles client- oder projektspezifische aus dem persönlichen Ordner. Die meisten überladenen Setups reduzieren sich im ersten Durchlauf von über 30 Skills auf unter zehn, da der Großteil der Liste aus Experimenten besteht, die niemand gelöscht hat.