Claude Skills: Der Schuss ins eigene Knie — mit Ansagen!

…und wie man trotzdem sinnvoll mit Skills in Claude arbeiten kann

AI generated symbolic picture of bubbles showing the text “Claude Skills”

Beim Einarbeiten in die Thematik “Claude Skills” sind mir schon nach kurzer Zeit mehrere Sachen durch den Kopf gegangen:

• “Claude entscheidet dann selbst, welche hinterlegten Skills es verwendet” — ok… HowTheF*** soll man das transparent abbilden? Was, wenn der Skill für “Marketing” benutzt wird, es aber um den Skill für “Buchhaltung” ging?
• Das Ganze erinnert mich an “Global Commands” bei ChatGPT — dort hat man relativ schnell (ich arbeite seit über zwei Jahren damit) Probleme, Effekte von alten, Anno Dunnemals hinterlegten Global Commands — und deren Effekte auf aktuelle Prompts — auch nur annähernd zu erahnen! Man muss dann nachfragen: “Wie kommst Du auf die beknackte Idee im aktuellen Zusammenhang?” — worauf der Bot antwortet “Du hast vor 1,5 Jahren eine globale Anweisung dazu hinterlegt”… ohne Worte…
• Und: Warum wird DIE PROBLEMATIK nirgendwo thematisiert? Es gibt Hunderte “so baust Du Deine Skills in Claude”, “So wirst Du der Skill-Hero” uswusf… aber was ist mit USE CASES!!! Konkret und inspirierend?

Besonders bei Punkt drei hatte ich ein echtes Déjà-vu: Schon vor Monaten hatte ich mit einem Freund darüber gesprochen, wie technisch, technokratisch und praktisch komplett useless viele “howtos” im Netz sind, wenn es um neue Technologien (grade im Bereich AI) geht. Damals ging es um MCP-Server… nur “wie geht das”, NULL “konkreter UseCase” — reiner Article-ClickBait.

Nach einem heftigen Brainstorming mit Claude ist dann dieser Artikel entstanden

HTH!

Claude Skills:

Das Versprechen der Spezialisierung — und die ungewollten Nebeneffekte

Ende 2024 rollte die nächste Welle durch die Tech-Bubble: “Claude Skills” — eine Erweiterung für Anthropics Sprachmodell, die aus dem generalistischen Assistenten einen Spezialisten für jede erdenkliche Aufgabe machen sollte. Tech-Blogs explodierten mit Begeisterung: “10 Skills, die alles verändern!”, “Produktivität auf dem nächsten Level!”, “Claude wird zum Experten-Orchester!” 🎻

Kennt man mittlerweile, dieses Muster. Neue Funktion erscheint → Marketing-Maschinerie läuft an → Early Adopters berichten euphorisch → wer nicht sofort aufspringt, fürchtet den Anschluss zu verpassen. Wieder eine Sau durchs Dorf getrieben, wieder alle hinterher — ohne innezuhalten und zu fragen: Brauchen wir das wirklich? Wozu genau? Und vor allem: Was passiert da eigentlich im Hintergrund?

Kritische, reflektierte Einschätzungen zu neuen KI-Features? Mangelware. Nicht, weil sie unmöglich wären, sondern weil der Hype-Zyklus schneller dreht als die Nachdenklichkeit. Gerade bei Skills lohnt sich der zweite Blick — hinter dem eleganten Versprechen verbergen sich Mechanismen, die nicht nur erweitern, sondern auch einschränken können.

Was Skills eigentlich sind — ein nüchterner Blick — beyond the Hype

Lee Hanchung hat die Architektur von Claude Skills in einem ausführlichen Deep-Dive minutiös dekonstruiert. Beeindruckend detailliert, zweifellos — und zugleich ein Paradebeispiel dafür, wie technische Exzellenz nicht automatisch zu praktischer Klarheit führt. Während die Implementierung elegant ist, bleibt die Frage nach dem “Wann” und “Wozu” merkwürdig unterbelichtet.

Skills sind — vereinfacht gesagt — spezialisierte Prompt-Templates, die Claude in bestimmten Situationen automatisch zur Verfügung gestellt werden. Anders als herkömmliche Tools (etwa das Lesen von Dateien oder die Ausführung von Code) führen Skills keine direkten Aktionen aus. Sie injizieren stattdessen umfangreiche Anweisungen in den Konversationskontext und modifizieren die Ausführungsumgebung:

• Welche Werkzeuge Claude nutzen darf
• Welches Modell zum Einsatz kommt
• Wie der Arbeitsprozess strukturiert sein soll

Ein Beispiel: Ein “PDF-Skill” würde Claude nicht nur sagen “Extrahiere Text aus dieser Datei”, sondern ihm eine detaillierte Anleitung mitgeben — welches Tool zu nutzen ist (pdftotext), wie die Ausgabe zu formatieren ist, was bei Fehlern zu tun ist, welche Schritte in welcher Reihenfolge zu durchlaufen sind. Temporär verwandelt sich Claude in einen PDF-Spezialisten.

Entscheidender Mechanismus: Claude selbst entscheidet durch reine Sprachverarbeitung, wann ein Skill aktiviert wird. Kein algorithmisches Matching, keine Keyword-Suche, keine Intent-Klassifikation auf Code-Ebene. Stattdessen sieht Claude eine Liste aller verfügbaren Skills mit ihren Beschreibungen und wählt aus, was zur Anfrage passt. Pure LLM-Reasoning — elegant, aber auch fehleranfällig.

Use Cases, die tatsächlich Sinn ergeben ✅

Fairerweise: Es gibt Szenarien, in denen Skills tatsächlich glänzen. Repetitive, komplexe Workflows mit klaren Regeln sind prädestiniert dafür.

Wenn eine Firma immer wieder dieselben Reports erstellen muss — identische Struktur, festgelegtes Format, spezifische Compliance-Anforderungen — dann lohnt sich ein Skill. Einmal definiert, hundertfach genutzt, konsistent ausgeführt. Das funktioniert.

Ähnlich bei technischen Prozessen: Ein Code-Review-Skill, das systematisch durch eine Checkliste geht (PEP8-Konformität, Type Hints, Docstrings, Security-Checks), kann tatsächlich Qualität heben und Zeit sparen. Oder ein Skill für Datenverarbeitungs-Pipelines, das PDFs einliest, Text extrahiert, parst und in eine Datenbank überführt — Schritt für Schritt, immer gleich, ohne dass jeder Teilschritt neu erklärt werden muss.

Gemeinsamer Nenner: Abgegrenzte, wiederholbare Aufgaben mit klarem Start- und Endpunkt. Institutionelles Wissen, das sich formalisieren lässt. Workflows, die von menschlicher Inkonsistenz befreit werden sollten. In solchen Kontexten — typischerweise in Unternehmen, wo Prozesse standardisiert werden müssen — machen Skills durchaus Sinn.

Bedenken, die der Hype verschweigt ⚠️

Die Realität ist komplexer, als die Feature-Ankündigungen suggerieren.

Konkrete Problemfelder zeichnen sich ab, sobald man über idealisierte Use Cases hinausdenkt. Und genau da wird es interessant.

1. Spezialisierungs-Paradox: Fokus als Falle

Spezialisierung macht Claude fokussierter — aber eben auch begrenzter. Was als Stärke verkauft wird, ist zugleich eine Einschränkung.

Konkretes Beispiel: Skill für den persönlichen Schreibstil — locker, direktes “du”, kurze Absätze, gelegentliche Emojis. Funktioniert hervorragend für Blog-Posts und Social Media. Bis mitten im Chat plötzlich ein formeller Geschäftsbrief benötigt wird. Skill ist aktiv, Claude folgt den Anweisungen — und produziert einen Brief, der beginnt mit “Hey, lass uns mal über den Vertrag quatschen! 😊”.

Unangenehm. Peinlich, wenn es an den falschen Empfänger geht.

Tiefer liegt das Problem hier: Skills modifizieren nicht nur Anweisungen, sondern auch Werkzeug-Berechtigungen. Ein PDF-Skill mit Zugriff nur auf Bash und Read-Befehle kann plötzlich keine Web-Recherche mehr durchführen, selbst wenn der Kontext danach verlangt. Spezialisierung wird zur Scheuklappen-Situation — Claude brilliert in seinem Fachgebiet, verliert aber periphere Fähigkeiten.

Je präziser ein Skill definiert ist, desto gefährlicher wird es bei Off-Topic-Fragen. Und weil Claude durch reine Sprachverarbeitung entscheidet, wann ein Skill aktiviert wird, sind Fehlzuordnungen unvermeidbar. Skills werden aktiviert, obwohl sie nicht passen — oder bleiben inaktiv, obwohl sie gebraucht würden. Flexibel, ja. Fehlerfrei? Niemals.

2. Skill-Overflow: Wenn niemand mehr durchblickt 🌀

Praktischer, aber nicht weniger relevant: die schiere Anzahl. Wer heute schon mit KI-Assistenten arbeitet, kennt das Phänomen — nach Wochen verliert man den Überblick, in welchem Chat welches Problem wie angegangen wurde. Skills verschärfen dieses Problem potenziert.

Szenario: 15 Skills, gewachsen über Wochen. Eines für Medium-Artikel, eines für LinkedIn-Posts, eines für Code-Review in Python, eines für Datenanalyse, eines für Firmen-Memos nach Vorlage A, eines nach Vorlage B, eines für… irgendwann weiß niemand mehr, welche Anweisungen gerade aktiv sind, welche Regeln gelten, warum Claude sich plötzlich anders verhält als gestern.

System zeigt zwar an, wenn ein Skill geladen wird — aber diese Meldung verschwindet im Chat-Verlauf. Nach 20 Nachrichten? Unsichtbar. Man arbeitet mit einem Assistenten, dessen Verhalten von versteckten Variablen gesteuert wird. Variablen, die man selbst definiert hat — aber nicht mehr überblickt.

Das ist keine Produktivitätssteigerung. Das ist Komplexitäts-Eskalation.

Versuchung liegt nahe, für jede wiederkehrende Situation ein Skill zu bauen. Doch anders als physische Werkzeuge, die sichtbar im Werkzeugkasten liegen, sind digitale Skills unsichtbar — bis sie unerwartet aktiviert werden und Verhalten produzieren, das sich nicht mehr nachvollziehen lässt.

3. Geister-Effekt: Wenn vergessene Skills zuschlagen 👻

Noch skurriler wird es, wenn Skills in Vergessenheit geraten. Szenario, das aus ChatGPT mit Custom Commands bekannt ist — übertragbar eins zu eins auf Claude Skills:

Vor drei Monaten wurde ein Skill erstellt. “Schreib immer mit nautischen Metaphern” oder “Beende jeden Text mit einem Kant-Zitat” oder “Verwende keine Passiv-Konstruktionen”. Damals schien das sinnvoll. Vielleicht war es ein Experiment. Vielleicht sollte es nur temporär sein.

Drei Monate später: Plötzlich antwortet Claude merkwürdig. Texte klingen schräg. Formulierungen wirken unpassend. Man fragt sich: “Was ist hier los?”

Und dann die Auflösung, wenn man nachfragt:

“Du hast das vor drei Monaten mit dem Skill ‘nautischer-Stil’ so festgelegt. Soll ich das ändern?”

Aha. Vergessen. Komplett vergessen.

Anders als bei Custom Commands, die in ChatGPT wenigstens zentral sichtbar sind, leben Skills in einer verteilten Struktur — irgendwo in Ordnern, in Projekten, als Plugin-Ergänzungen. Kein zentrales Dashboard zeigt: “Diese 12 Skills sind aktuell geladen.” Keine Warnmeldung sagt: “Achtung, dieses Skill ist seit 90 Tagen aktiv, aber ungenutzt.”

Ergebnis: Geister-Skills, die still und heimlich im Hintergrund wirken, längst vergessen von denen, die sie erstellt haben — aber nicht vergessen vom System. Claude verhält sich mysteriös, Antworten wirken inkonsistent, niemand versteht warum. Bis man zufällig oder durch explizite Nachfrage auf die Ursache stößt.

Das ist keine theoretische Gefahr. Das passiert bereits bei ChatGPT Custom Commands. Und bei Skills wird es schlimmer, weil die Architektur dezentraler und weniger transparent ist.

4. Wartungshölle: Erosion in Zeitlupe 🔧

Zeitlicher Aspekt, nicht weniger kritisch: Skills sind nicht statisch. Arbeitsweisen ändern sich, Anforderungen verschieben sich, Tools werden aktualisiert. Ein Skill, das vor drei Monaten perfekt funktionierte, kann heute veraltet sein — aber wer denkt daran, es anzupassen?

Anders als Code, der durch Tests und CI/CD-Pipelines kontinuierlich validiert wird, gibt es für Skills keine automatische Qualitätssicherung. Sie sind Prosa, keine Programme. Können semantisch driften, ohne dass es auffällt. Code-Review-Skill berücksichtigt vielleicht neue Best Practices nicht. Firmen-Memo-Skill verwendet noch die alte Vorlage. Schreibstil-Skill repräsentiert die eigene Stimme von vor einem Jahr, nicht die von heute.

Konsequenz: Entweder kontinuierlich Zeit in die Pflege investieren — was den Produktivitätsgewinn relativiert — oder mit schleichender Qualitätserosion leben. Beides suboptimal.

Alternative: Weniger ist tatsächlich mehr

Nüchterne Erkenntnis: Skills sind kein Allheilmittel, sondern ein Spezialtool für spezielle Situationen. Industrie verkauft sie als nächste Produktivitäts-Revolution, dabei sind sie eher eine Option für Edge Cases — sinnvoll in Unternehmen mit standardisierten Prozessen, fragwürdig für Einzelnutzer mit wechselnden Anforderungen.

Für viele Anwendungsfälle gibt es einfachere, flexiblere Alternativen:

Claude Projects erlauben verschiedene Kontexte mit unterschiedlichen Dokumenten und Anweisungen — ohne die technische Komplexität von Skills. Hochgeladene Stilvorlage in einem Projekt? Funktioniert genauso gut wie ein Skill, ist aber transparenter und leichter anzupassen.

Custom Instructions — globale Anweisungen für alle Gespräche — decken persönliche Präferenzen ab, ohne dass eine Skill-Architektur aufgebaut werden muss.

Für wirklich einmalige Anforderungen reicht oft ein durchdachter Prompt, der präzise beschreibt, was gewünscht ist.

Faustregel: Aufgabe tritt öfter als drei Mal im Monat in exakt derselben Form auf? Könnte ein Skill sinnvoll sein. Wenn nicht? Vermutlich Overengineering. Skills sollten die Ausnahme sein, nicht die Regel.

Größeres Muster: Feature-Inflation als Geschäftsmodell 📈

Was sich an Skills beobachten lässt, ist symptomatisch für einen breiteren Trend: Features werden entwickelt, weil sie technisch möglich sind — nicht zwingend, weil sie ein drängendes Problem lösen. Implementierung elegant, Dokumentation umfangreich, Marketing-Botschaft klar. Aber die kritische Frage “Braucht das jemand wirklich?” bleibt merkwürdig unterbelichtet.

Keine Verschwörung, keine böse Absicht. Einfach die Dynamik einer Industrie unter enormem Innovationsdruck. Wer nicht ständig neue Features liefert, verliert die Aufmerksamkeit. Wer nicht den nächsten Produktivitäts-Boost verspricht, wirkt stagnierend. Marktlogik treibt zu immer neuen Funktionen — unabhängig davon, ob sie tatsächlich die Nutzererfahrung verbessern oder nur die Feature-Liste verlängern.

Skills sind technisch beeindruckend. Architektur durchdacht, Implementierung sauber, Möglichkeiten vielfältig. Aber technische Eleganz ist kein Selbstzweck. Und dass etwas möglich ist, bedeutet nicht, dass es auch nützlich ist.

Lehre: Kritisches Denken schlägt blinde Adoption 🧠

Am Ende bleibt eine Erkenntnis, die über Skills hinausgeht: In einer Welt, in der ständig neue KI-Features lanciert werden, ist Skepsis keine Ablehnung, sondern Pragmatismus. Nicht jede Innovation verdient sofortige Adoption. Nicht jedes Feature rechtfertigt den Aufwand, es zu implementieren und zu pflegen.

Relevantere Frage ist nicht “Wie funktioniert dieses neue Feature?”, sondern “Löst es ein Problem, das tatsächlich existiert?”. Und wenn die Antwort nicht eindeutig ja ist, dann ist Abwarten oft die klügere Strategie.

Nächste Sau wird ohnehin schon morgen durchs Dorf getrieben — niemand muss jeder hinterherlaufen.

Skills mögen für manche Nutzer, in manchen Kontexten, für manche Workflows tatsächlich einen Mehrwert bieten. Für die meisten anderen sind sie vermutlich eine Lösung auf der Suche nach einem Problem. Und das ist vollkommen in Ordnung — solange man es erkennt, bevor Zeit und Energie in ein System investiert werden, das am Ende mehr Komplexität schafft als Nutzen stiftet.

Zukunft der KI-Assistenten liegt nicht darin, immer mehr Features zu stapeln, sondern darin, die richtigen Features zur richtigen Zeit auf die richtige Weise einzusetzen. Manchmal ist die beste Innovation, einfach das zu nutzen, was bereits funktioniert — ohne dem Druck nachzugeben, ständig das Neueste ausprobieren zu müssen.

Claude Skills sind ein interessantes Experiment. Aber vielleicht, nur vielleicht, ist das Interessanteste daran die Frage, die sie aufwerfen:

Wann ist genug genug? 🤔

Interested in more on topics like this?

SStay in touch: I regularly share insights on OpenCode, AI tools & GenAI workflows — no Medium membership needed (*)

→ http://www.linkedin.com/in/christoph-schweres

*() But I really advise you to become a member here on Medium — it’s totally free! And you can add articles and authors to your timeline.**

Dieser Post wird teilweise unter Zuhilfenahme Generativer KI aus einem laufenden Projekt heraus erzeugt und entsprechend lektoriert.