Was mich das Erstellen von über 30 Claude Code Skills gelehrt hat

Was mich das Erstellen von über 30 Claude Code Skills gelehrt hat

Vor drei Monaten habe ich vierzehn Skills aus meinem Claude Code-Setup massenhaft gelöscht. Nicht archiviert. Gelöscht. Das waren Skills, in die ich echte Zeit investiert hatte — Aufbau, Tests und Iteration. Skills, auf die ich stolz war.

Sie machten meine Arbeit schlechter.

Nicht dramatisch schlechter — das wäre leicht aufgefallen. Subtil schlechter. Ein Content-Generierungs-Skill, der Claudes verbesserte native Schreibfähigkeiten überschrieb. Ein Commit-Message-Skill, der starre, formelhafte Ausgaben produzierte, während das Modell gelernt hatte, selbst bessere zu schreiben. Ein Code-Review-Skill, so vorschreibend, dass Claude Kästchen abhakte, anstatt wirklich über Codequalität nachzudenken.

Die Massenlöschung lehrte mich etwas, das ich in keiner Dokumentation gelesen hatte: Skills zu bauen ist der einfache Teil. Skills zu bauen, die nützlich bleiben, die gut miteinander zusammenarbeiten, die deinen Workflow sechs Monate später tatsächlich verbessern — das ist eine völlig andere Disziplin. Und es ist eine Disziplin, die ich auf die harte Tour lernen musste.

Ich habe inzwischen über dreißig aktive Skills aufgebaut und gepflegt — für vier verschiedene Markenwebsites, eine Content-Erstellungs-Pipeline, einen Security-Audit-Workflow und meine tägliche Entwicklungsumgebung. Einige dieser Skills laufen seit fast einem Jahr. Andere hielten eine Woche, bevor ich erkannte, dass sie das falsche Problem lösten.

Was folgt, ist kein Tutorial zum Erstellen deines ersten Skills. Wenn du das brauchst, helfen dir Anthropics offizielle Dokumentation und ihr Skilljar-Kurs über Agent Skills beim Einstieg. Hier geht es darum, was nach deinen ersten zehn Skills passiert — die Muster, die sich abzeichnen, die Fehler, die sich wiederholen, und die Architekturentscheidungen, die Skills, die du jahrelang nutzt, von Skills trennen, die du innerhalb eines Monats löschst.

Die Frage, die alles für mich veränderte: Welche Art von Skill baue ich eigentlich?

Warum die meisten Skills jung sterben — und ein Umdenken, das es behebt

Ich dachte immer, ein Skill ist ein Skill ist ein Skill. Du schreibst ein paar Markdown-Anweisungen, fügst vielleicht ein oder zwei Scripts hinzu, legst es in .claude/skills/ ab und machst weiter. Dieser Ansatz funktionierte gut, als ich drei Skills hatte. Als ich fünfzehn hatte, war mein Setup ein Chaos.

Skills standen miteinander in Konflikt. Einige luden Kontext, der 90% der Zeit irrelevant war. Andere waren so generisch, dass sie Claudes Output kaum verbesserten. Ein Skill — mein ursprünglicher „Code Quality"-Skill — widersprach tatsächlich meinem „Testing Practices"-Skill auf Weisen, die ich wochenlang nicht bemerkte.

Der Wendepunkt kam, als ich begann, meine Skills danach zu kategorisieren, was sie tatsächlich tun, nicht worum es in ihnen geht. Nachdem ich alles in meinem Setup katalogisiert und studiert hatte, wie Anthropics interne Teams ihre eigenen Skills organisieren (sie haben einiges davon öffentlich geteilt), fiel mir auf, dass jeder nützliche Skill sauber in eine von etwa neun Kategorien passt. Die verwirrenden, schwer zu wartenden Skills? Die versuchten immer, mehrere Kategorien gleichzeitig abzudecken.

Hier ist die Taxonomie, die ich jetzt verwende, bevor ich etwas Neues baue.

Library- und API-Reference-Skills erklären, wie man ein bestimmtes Tool, SDK oder eine interne Library korrekt verwendet. Mein Aria-Skill fällt genau hier hinein — er kodiert Markenrichtlinien, Stimmregeln, SEO-Anforderungen und Content-Architekturmuster für vier verschiedene Websites. Ohne ihn schreibt Claude kompetente Beiträge, die überhaupt nicht nach meiner Marke klingen.

Product-Verification-Skills beschreiben, wie man testen oder verifizieren kann, dass die Ausgabe tatsächlich korrekt ist. Kombiniert mit Playwright, tmux oder benutzerdefinierten Scripts. Hier habe ich monatelang zu wenig investiert. Dazu später mehr.

Data-Fetching- und Analysis-Skills verbinden sich mit deinen Daten- und Monitoring-Stacks — Grafana Datasource UIDs, Dashboard IDs, gängige Abfragemuster. Claude hört auf, bei Spaltennamen zu raten, und beginnt, Abfragen zu schreiben, die tatsächlich funktionieren.

Business-Process- und Team-Automation-Skills automatisieren repetitive Workflows. Mein Standup-Post-Skill aggregiert GitHub-Aktivitäten, Ticket-Updates und Slack-Nachrichten zu einem formatierten täglichen Update. Einfache Anweisungen, wachsender Wert.

Code-Scaffolding- und Template-Skills generieren Boilerplate für bestimmte Muster in deiner Codebase. Ein Laravel-„neue Migration"-Skill mit den Konventionen und Fallstricken deines Teams spart jedes Mal dreißig Minuten.

Code-Quality- und Review-Skills setzen Standards durch. Mein Adversarial-Review-Setup startet einen Sub-Agenten, der Code kritisiert, Fixes implementiert und iteriert, bis die Befunde zu Kleinigkeiten herabgestuft werden.

CI/CD- und Deployment-Skills helfen beim Fetchen, Pushen und Deployen. Mein Babysit-PR-Skill überwacht PRs, wiederholt flaky CI, löst Merge-Konflikte und aktiviert Auto-Merge.

Runbook-Skills nehmen ein Symptom und durchlaufen eine Multi-Tool-Untersuchung, um einen strukturierten Bericht zu erstellen. Goldgruben für On-Call-Rotationen.

Infrastructure-Operations-Skills behandeln routinemäßige Wartung mit Leitplanken — Dependency-Workflows, Kostenuntersuchung, Bereinigung verwaister Ressourcen mit obligatorischer Bestätigung vor destruktiven Aktionen.

Ab dem Moment, in dem ich anfing zu fragen „In welche Kategorie gehört das?", bevor ich eine einzige Zeile Markdown schrieb, wurden meine Skills schärfer. Wenn ein Skill versucht, sowohl ein Codequalitäts-Checker ALS AUCH ein Scaffolding-Template zu sein, teile ich ihn in zwei. Wenn er in keine Kategorie sauber passt, hinterfrage ich, ob er überhaupt existieren sollte.

Aber das Kategorisieren von Skills ist nur der Ausgangspunkt. Das eigentliche Handwerk liegt darin, wie du sie schreibst.

Die Gotchas-Sektion ist mehr wert als der Rest des Skills zusammen

Ich werde eine Behauptung aufstellen, die vielleicht extrem klingt: Der wertvollste Teil jedes Skills ist seine Gotchas-Sektion. Nicht die Anweisungen. Nicht die Beispiele. Nicht die Konfiguration. Die Gotchas.

Hier ist der Grund. Claude weiß bereits viel. Es weiß, wie man Python schreibt, wie man eine React-Komponente strukturiert, wie man eine REST API baut. Wenn du einen Skill schreibst, der die grundlegende Verwendung von etwas erklärt, das Claude bereits versteht, verschwendest du Tokens und schränkst die Flexibilität des Modells ein. Aber wenn du die spezifischen Fehlermodi dokumentierst — die Randfälle, auf die Claude wiederholt stößt, die Annahmen, die es macht und die in deinem spezifischen Kontext falsch sind, die subtilen Bugs, die nur in Produktion auftreten — das ist, wo Skills ihren Wert beweisen.

Mein Aria-Content-Skill hat eine „Verbotene Phrasen"-Sektion, die über fünfzig Einträge lang ist. Dinge wie „In today's fast-paced world" und „Let's dive in" und „Furthermore" — Phrasen, die sofort KI-generierten Content signalisieren. Ich habe diese Liste nicht auf einmal geschrieben. Ich habe sie über drei Monate aufgebaut, indem ich Claude dabei ertappte, in KI-Sprache zurückzufallen, jeden Übeltäter zur Gotchas-Liste hinzufügte und beobachtete, wie die Ausgabequalität mit jeder Ergänzung besser wurde.

Dasselbe Muster bei meinem Laravel-Migrations-Skill. Die eigentliche Migrationssyntax? Die kennt Claude auswendig. Aber die Gotchas — „verwende nie ->change() bei einer Spalte, die einen Index in MySQL 5.7 hat", „füge immer ->after('column_name') hinzu, um die Spaltenreihenfolge beizubehalten", „unsere Staging-Datenbank verwendet eine andere Collation als Produktion" — diese Einträge verhindern Bugs, die sonst Stunden zum Debuggen brauchen würden.

Die praktische Erkenntnis: Beginne jeden neuen Skill mit einem minimalen Anweisungsset und einer leeren Gotchas-Sektion. Nutze den Skill eine Woche lang. Jedes Mal, wenn Claude etwas Falsches oder Unerwartetes tut, füge es zu Gotchas hinzu. Nach einem Monat wird deine Gotchas-Sektion der am besten verfeinerte, kampferprobte Teil des Skills sein. Es wird auch der Teil sein, der dir am meisten Zeit spart.

Ich überprüfe meine Gotchas-Sektionen jetzt monatlich. Einige Einträge werden in die Hauptanweisungen befördert, weil sie so grundlegend sind. Andere werden entfernt, weil Claude sich verbessert hat und diesen Fehler nativ nicht mehr macht. Dieser Wartungszyklus ist langweilig, aber er macht den Unterschied zwischen einem Skill, der scharf bleibt, und einem, der langsam verrottet.

Diese monatliche Review-Gewohnheit führt direkt zu einer weiteren Lektion, die ich peinlich lange brauchte, um sie zu lernen.

Skills sind Ordner, nicht Dateien — und das verändert alles

Ein weit verbreitetes Missverständnis, das ich viel zu lange hatte: Ein Skill ist „nur eine Markdown-Datei." Technisch gesehen ist eine SKILL.md-Datei alles, was du brauchst. Aber sobald du Skills als Ordner behandelst — mit Scripts, Referenzdateien, Templates und Daten — vervielfacht sich ihre Kraft.

So sieht die Struktur meines Aria-Content-Skills heute aus:

aria/
  SKILL.md              # Core instructions, loaded on trigger
  aria-system-prompt.md # Full brand guidelines, loaded on demand
  references/
    banned-phrases.md   # AI detection trigger phrases
    footer-templates.md # Brand-specific CTA footers
    headline-formulas.md # Proven header structures by brand
  assets/
    post-template.md    # Skeleton for new blog posts
  scripts/
    word-count.sh       # Validates 3,000-5,000 word requirement

Die SKILL.md-Datei wird unter 500 Zeilen gehalten. Sie enthält die Kernidentität, die Schreibphilosophie und Verweise auf Referenzdateien. Wenn Claude einen Beitrag für mejba.me generiert, liest es die markenspezifischen Abschnitte aus dem System-Prompt. Wenn es eine Überschrift gegen bewährte Formeln prüfen muss, greift es auf references/headline-formulas.md zu. Die Liste der verbotenen Phrasen lebt in einer eigenen Datei, weil sie sich häufig ändert und ich nicht möchte, dass Änderungen daran meine Kernanweisungen verunreinigen.

Das ist Progressive Disclosure in Aktion. Claude lädt nicht alles auf einmal. Die YAML-Frontmatter — Name und Beschreibung — gelangt beim Sitzungsstart in den Prompt. Das sind ungefähr 100 Tokens. Der SKILL.md-Body wird geladen, wenn Claude feststellt, dass der Skill relevant ist. Die Referenzdateien werden nur geladen, wenn SKILL.md Claude ausdrücklich anweist, sie zu lesen.

Warum ist das wichtig? Weil Context-Window-Management eine echte Einschränkung ist. Jeder Token an Skill-Anweisungen ist ein Token, der nicht für die eigentliche Aufgabe verwendet werden kann. Wenn ich mein gesamtes Aria-System — Markenrichtlinien für vier Websites, fünfzig verbotene Phrasen, Footer-Templates, Überschriften-Formeln, den vollständigen Content-Architektur-Blueprint — in eine einzige SKILL.md-Datei packen würde, wären das Tausende von Tokens, die für jedes Gespräch geladen werden, selbst wenn ich Claude nur bitte, einen Tippfehler zu korrigieren.

Die Ordnerstruktur macht auch die Wartung drastisch einfacher. Wenn ich verbotene Phrasen aktualisieren muss, bearbeite ich eine Datei. Wenn ich eine neue Marke hinzufüge, aktualisiere ich den System-Prompt, ohne die Kern-Skill-Logik anzutasten. Wenn ein Teammitglied verstehen will, was der Skill tut, liest es SKILL.md. Wenn es die tiefgreifenden Markenrichtlinien verstehen will, liest es die Referenzdateien.

Ein Muster, das ich kürzlich begonnen habe zu verwenden: Template-Dateien in assets/ einbinden, die Claude kopiert und ausfüllt, anstatt von Grund auf zu generieren. Mein Blogpost-Template enthält den Metadatenblock, die Phasenstruktur-Marker und den obligatorischen Footer. Claude muss sich nicht an das exakte Format erinnern — es kopiert einfach das Template und füllt die Lücken. Weniger Formatfehler, konsistentere Ausgabe.

Wenn du lieber jemanden hättest, der diese Art von Skill-Architektur für deine eigenen Workflows baut, übernehme ich individuelle Claude Code-Setups und Integrationen. Du kannst sehen, was ich gebaut habe, unter fiverr.com/s/EgxYmWD.

Es gibt hier allerdings eine Feinheit, die ich fast übersehen hätte — und es geht darum, was du nicht in den Skill packst.

Was ich darüber gelernt habe, Claude nicht auf Schienen zu setzen

Meine Skills der ersten Generation waren Diktatoren. Jeder Schritt vorgeschrieben. Jedes Ausgabeformat festgelegt. Jede Entscheidung im Voraus getroffen.

Die Ergebnisse waren konsistent. Sie waren auch mittelmäßig.

Das Problem beim Überspezifizieren eines Skills ist, dass du Claudes Fähigkeit verlierst, sich anzupassen. Du verwandelst im Grunde eine intelligente Reasoning-Engine in einen Template-Ausfüller. Und Template-Ausfüller können keine Randfälle handhaben. Sie überraschen dich nicht mit einem besseren Ansatz als dem, den du geplant hattest. Sie fangen keine Fehler in deinen eigenen Anweisungen auf.

Ich lernte diese Lektion mit meinem Code-Review-Skill. Version eins war eine Zwanzig-Schritte-Checkliste: Prüfe auf ungenutzte Imports, verifiziere Fehlerbehandlung, bestätige Testabdeckung, validiere Namenskonventionen... Claude würde methodisch jeden Punkt durchgehen und eine perfekt formatierte Review produzieren. Aber die Reviews verpassten die Dinge, die wirklich zählten — Architekturbedenken, Performance-Implikationen, Sicherheitslücken, die nicht sauber in ein Checklisten-Element passten.

Version zwei strich die Checkliste auf fünf Prinzipien und eine Gotchas-Sektion herunter. Anstelle von „prüfe auf ungenutzte Imports" stand da „priorisiere Befunde nach tatsächlichem Einfluss auf die Produktionszuverlässigkeit." Anstatt das Ausgabeformat vorzuschreiben, stand da „strukturiere deine Review so, dass der Autor das Warum hinter jedem Befund versteht."

Die Reviews wurden dramatisch besser. Claude begann, Dinge zu finden, die die Checkliste nie abgedeckt hatte — Race Conditions, API-Vertragsverletzungen, subtile State-Management-Bugs. Es dachte über den Code nach, anstatt Kästchen abzuhaken.

Das Prinzip, dem ich jetzt folge: Gib Claude die Informationen, die es braucht, und die Flexibilität, sich an die Situation anzupassen. Sage, was wichtig ist, nicht genau, was es tun soll. Nimm deine Gotchas und Einschränkungen auf, aber lass Raum, damit das Modell sein eigenes Urteil anwenden kann.

Es gibt einen konkreten Weg zu testen, ob du überspezifiziert hast: Führe dieselbe Aufgabe dreimal mit deinem Skill aus. Wenn die Ausgaben in Struktur und Inhalt nahezu identisch sind, ist dein Skill wahrscheinlich zu starr. Wenn sie in der Qualität konsistent, aber im Ansatz variiert sind, hast du den Sweet Spot getroffen.

Dieses Flexibilitätsprinzip gilt auch für Skill-Trigger — und hier wird das Description-Feld entscheidend.

Das Description-Feld ist Marketing an das Modell, nicht an Menschen

Wenn Claude Code eine Sitzung startet, erstellt es eine Auflistung jedes verfügbaren Skills mit seiner Beschreibung. Diese Auflistung scannt Claude, um zu entscheiden „gibt es einen Skill für diese Anfrage?" Das Description-Feld ist keine Zusammenfassung für menschliche Leser. Es ist eine Trigger-Spezifikation für das Modell.

Diesen Fehler machte ich bei meinem ersten Batch Skills. Mein Commit-Message-Skill hatte eine Beschreibung wie: „Hilft, bessere Commit Messages zu schreiben." Vage. Generisch. Claude triggerte ihn für alles, was auch nur entfernt mit Git zu tun hatte, einschließlich Momenten, in denen ich nur ein Log oder Diff ansehen wollte.

Die überarbeitete Beschreibung: „Verwende, wenn der Benutzer darum bittet, einen Commit zu erstellen, eine Commit Message zu schreiben, oder /commit sagt. Triggere nicht für git log, git diff, git status oder andere schreibgeschützte Git-Operationen."

Wie Tag und Nacht. Claude triggert den Skill jetzt genau dann, wenn ich ihn brauche, und bleibt aus dem Weg, wenn nicht.

Einige Muster, die ich für Beschreibungen effektiv finde:

Positive Trigger — was den Skill aktivieren soll: „Verwende, wenn der Benutzer darum bittet, einen Blogbeitrag zu erstellen, einen Artikel zu schreiben, Content zu generieren, oder eine dieser Marken erwähnt: mejba.me, ramlit.com, colorpark.io, xcybersecurity.io."

Negative Trigger — was ihn NICHT aktivieren soll: „Triggere nicht für Code Reviews, Bugfixes oder technische Dokumentation."

Kontextbedingungen — wann der Skill gilt: „Nur relevant bei der Arbeit in Repositories, die Laravel 11+ mit Livewire verwenden."

Das richtig hinzubekommen verhindert ein Problem, das größere Skill-Sammlungen plagt: Trigger-Konflikte. Wenn zwei Skills beide behaupten, „Schreibaufgaben" zu behandeln, muss Claude raten, welchen du willst. Spezifische, gut abgegrenzte Beschreibungen eliminieren das Raten.

Das wird noch wichtiger, wenn du anfängst, Skills miteinander zu kombinieren — und hier zeigt sich die echte Stärke.

Skills kombinieren: Wo der Multiplikator-Effekt einsetzt

Einzelne Skills sind nützlich. Skills, die aufeinander verweisen und aufeinander aufbauen, sind transformativ.

Meine Content-Pipeline funktioniert so: Der Aria-Skill übernimmt die Content-Generierung. Er verweist auf einen SEO-Toolkit-Skill für Keyword-Recherche und Optimierung. Der SEO-Skill wiederum verweist auf einen Datenanalyse-Skill, der Traffic-Daten und Search-Console-Metriken abrufen kann. Wenn ich Claude bitte, „einen Beitrag für mejba.me über Docker Networking zu erstellen", koordinieren sich diese drei Skills automatisch.

Die Komposition wird nicht von einem Dependency-System verwaltet — Claude Code hat noch kein natives Dependency Management für Skills. Stattdessen verweise ich auf andere Skills namentlich in meinen SKILL.md-Dateien: „Für SEO-Analyse, rufe den seo-toolkit-Skill auf." Claude liest diese Anweisung und ruft den referenzierten Skill auf, wenn er installiert ist.

Das funktioniert in der Praxis überraschend gut. Aber es gibt eine Falle: zirkuläre Verweise. Wenn Skill A sagt „prüfe bei Skill B" und Skill B sagt „verifiziere bei Skill A", gerät Claude in eine Schleife. Das passierte mir mit meinen Code-Review- und Testing-Skills — der Review-Skill sagte „verifiziere, dass Tests existieren" und der Testing-Skill sagte „prüfe Code-Review-Befunde." Die Lösung war, die Abhängigkeit unidirektional zu machen: Code Review kann Testing Practices aufrufen, aber nicht umgekehrt.

Ein weiteres Kompositionsmuster, das sich ausgezahlt hat: die Verwendung eines einfachen „Orchestrator"-Skills, der alle deine anderen Skills kennt und Aufgaben an den richtigen weiterleitet. Mein Development-Workflow-Skill erledigt selbst keine eigentliche Arbeit — er weiß nur, dass Code Scaffolding zum Scaffolding-Skill geht, Reviews zum Review-Skill und Deployments zum CI/CD-Skill. Es ist ein Dispatcher, und er verhindert, dass ich mir merken muss, welcher Skill was macht.

Das Orchestrator-Muster macht auch das Onboarding neuer Teammitglieder trivial. Sie installieren einen Skill, und er leitet automatisch an alles weiter, was sie brauchen. Was die Frage aufwirft, wie man Skills überhaupt im Team teilt.

Wie ich Skills verteile, ohne Chaos zu verursachen

Skills zu teilen klingt einfach. Checke sie in dein Repo unter .claude/skills/ ein und jeder hat sie. Fertig.

Nur dass es nicht fertig ist. Denn jeder Skill, der ins Repo eingecheckt wird, fügt dem Kontext hinzu, den Claude für jedes Teammitglied lädt, ob sie den Skill brauchen oder nicht. Ein Team von fünf Personen mit je zehn Skills bedeutet fünfzig Skills im Kontext. Das ist viel Rauschen.

Der Ansatz, bei dem ich gelandet bin, verwendet zwei Ebenen.

Ebene eins: Repo-Level-Skills gehen in .claude/skills/ und werden in das Repository eingecheckt. Das sind Skills, die jeder Mitwirkende braucht — Codestil-Durchsetzung, Testkonventionen, Deployment-Prozeduren. Wenn du an dieser Codebase arbeitest, brauchst du diese Skills. Punkt. Ich halte diese Liste bewusst klein: drei bis fünf Skills pro Repo, maximal.

Ebene zwei: Persönliche und rollenspezifische Skills werden als Plugins über ein gemeinsames Verzeichnis verteilt. Meine Content-Skills, meine SEO-Tools, meine Design-System-Referenzen — die werden pro Benutzer installiert. Entwickler im Team brauchen meinen Aria-Content-Skill nicht. Ich brauche ihren Datenbank-Migrations-Skill nicht. Jeder installiert, was für seine Arbeit relevant ist.

Für Teams mit mehr als etwa zehn Personen würde ich empfehlen, einen internen Plugin-Marktplatz zu bauen — ein gemeinsames GitHub-Repo, in dem Leute verfügbare Skills durchsuchen, Beschreibungen lesen und installieren können, was sie brauchen. Anthropics interne Teams machen etwas Ähnliches: Skills starten in einem Sandbox-Verzeichnis, Leute teilen sie über Slack, und sobald ein Skill Traction hat, reicht der Owner einen PR ein, um ihn in den offiziellen Marktplatz zu verschieben.

Der Kurationschritt ist wichtiger, als du denkst. Unkontrolliert wachsen Skill-Sammlungen schnell. Leute erstellen Skills für jede kleine Unannehmlichkeit, und innerhalb weniger Monate hast du vierzig Skills, wo zehn ausreichen würden. Bevor ich etwas zu einem gemeinsamen Marktplatz hinzufüge, frage ich: „Würden mindestens drei Leute in diesem Team diesen Skill mindestens einmal pro Woche nutzen?" Wenn die Antwort nein ist, bleibt er persönlich.

Noch eine Verteilungslektion, die ich auf die harte Tour gelernt habe — die auch zufällig eines der mächtigsten Features ist, von dem die meisten Leute nichts wissen.

On-Demand-Hooks haben verändert, wie ich über Sicherheit denke

Skills können Hooks registrieren, die nur aktiviert werden, wenn der Skill aufgerufen wird, und die für die Dauer der Sitzung bestehen bleiben. Das unterscheidet sich von globalen Hooks, die die ganze Zeit laufen. On-Demand-Hooks sind kontextuelle Leitplanken.

Mein /careful-Skill ist das beste Beispiel. Wenn ich kurz davor bin, an Produktionsinfrastruktur zu arbeiten, rufe ich ihn auf. Der Skill registriert PreToolUse-Hooks, die rm -rf, DROP TABLE, Force-Push und kubectl delete blockieren. Diese Hooks fangen jeden Bash-Befehl ab, den Claude auszuführen versucht, und lehnen alles ab, was den gefährlichen Mustern entspricht.

Ich möchte nicht, dass diese Hooks die ganze Zeit laufen — sie wären wahnsinnig nervig bei normaler Entwicklung. Aber wenn ich an Produktionsdatenbanken oder Live-Kubernetes-Clustern arbeite, sind sie nicht verhandelbar. Der Skill gibt mir einen Schalter: maximale Sicherheit, wenn ich sie brauche, null Overhead, wenn nicht.

Ein weiterer On-Demand-Hook, den ich verwende: /freeze, der jede Edit- oder Write-Operation außerhalb eines bestimmten Verzeichnisses blockiert. Wenn ich ein Produktionsproblem debugge, möchte ich, dass Claude frei lesen und analysieren kann, aber nicht versehentlich etwas ändert. Der Freeze-Skill sperrt das Dateisystem, während der Lesezugriff offen bleibt.

Das Hook-System ermöglicht auch Messungen. Ich betreibe einen PreToolUse-Hook, der jede Skill-Aufrufung protokolliert — welcher Skill, wann er getriggert wurde, in welchem Kontext er lief. Nach einem Monat Daten kann ich sehen, welche Skills beliebt sind, welche zu wenig triggern (was bedeutet, dass ihre Beschreibungen Arbeit brauchen), und welche zu viel triggern (was bedeutet, dass ihr Scope zu breit ist).

Diese Art von Instrumentierung klingt nach Overkill, bis du dreißig Skills verwaltest und versuchst herauszufinden, warum deine Claude Code-Sitzung langsamer ist als sie sein sollte. Die Logging-Daten sagen dir genau, wohin das Kontextbudget geht.

Apropos Kontextbudgets — es gibt ein Memory-Pattern, das ich gerne vom ersten Tag an verwendet hätte.

Deinen Skills das Erinnern beibringen

Einige meiner effektivsten Skills behalten den Zustand zwischen Sitzungen bei. Nicht über eine ausgefeilte Datenbank — über einfache Textdateien.

Mein Standup-Post-Skill pflegt eine standups.log-Datei. Jedes Mal, wenn er einen Standup generiert, hängt er die Ausgabe an. Am nächsten Morgen liest Claude seine eigene Geschichte und weiß genau, was sich seit gestern geändert hat. Die Standups entwickelten sich von generischen Zusammenfassungen zu präzisen Delta-Berichten: „Den Auth-Refactor-PR gemergt, der seit Dienstag blockiert war. Drei neue Tickets eröffnet, alle in den aktuellen Sprint triagiert."

Mein Content-Pipeline-Skill trackt, welche Themen ich behandelt habe, welche Keywords ich gezielt habe und welche internen Links ich platziert habe. Wenn ich nach einem neuen Beitrag frage, prüft Claude das Protokoll und vermeidet das Duplizieren von Blickwinkeln, die ich bereits veröffentlicht habe. Es kann auch interne Links zu bestehendem Content vorschlagen, weil es weiß, was bereits vorhanden ist.

Die Implementierung ist denkbar einfach. Eine JSON-Datei oder ein Append-Only-Log in einem stabilen Verzeichnis. Claude Code stellt ${CLAUDE_PLUGIN_DATA} als stabiles Verzeichnis pro Plugin speziell für diesen Zweck bereit — hier gespeicherte Daten bleiben auch beim Upgrade des Skills erhalten.

// ${CLAUDE_PLUGIN_DATA}/content-history.json
{
  "posts": [
    {
      "date": "2026-03-10",
      "brand": "mejba.me",
      "slug": "opus-4-6-hands-on-review",
      "primary_keyword": "Claude Opus 4.6 review",
      "internal_links": ["claude-sonnet-5-agentic-coding", "claude-agent-teams-guide"]
    }
  ],
  "keywords_used": ["Claude Opus 4.6", "agentic coding", "agent teams"],
  "next_suggested": ["Claude Code skills deep dive", "hook development patterns"]
}

Eine Warnung: Speichere Memory-Daten nicht im Skill-Verzeichnis selbst. Wenn du einen Skill upgradest, kann das Verzeichnis überschrieben werden. Ich habe zwei Monate Standup-Historie verloren, als ich diese Lektion lernte. Verwende immer einen stabilen externen Pfad.

Das Memory-Pattern eröffnet auch etwas Mächtiges — Skills, die sich im Laufe der Zeit selbst verbessern. Jedes Mal, wenn Claude auf einen neuen Randfall stößt und ich ihn zur Gotchas-Sektion hinzufüge, ist das manuelle Verbesserung. Aber ein Skill, der seine eigenen Fehler protokolliert und sie zur Überprüfung vorlegt? Das kommt der Selbstverbesserung nahe. Ich habe diese Schleife noch nicht vollständig automatisiert, aber die Logging-Infrastruktur macht es möglich.

Gut — das deckt die Prinzipien ab. Wie sieht das in der Praxis aus, wenn du alles zusammenfügst?

Wie mein tatsächlicher Workflow im März 2026 aussieht

Das ist ein typischer Montagmorgen. Ich öffne Claude Code und starte eine Sitzung. Drei Repo-Level-Skills laden automatisch aus .claude/skills/: Codestil-Durchsetzung, Testkonventionen und unsere Deployment-Checkliste. Meine persönlichen Plugins laden auch: Aria (Content), SEO Toolkit, Commit-Konventionen, Code Review, TDD-Workflow und ein paar Utility-Skills.

Gesamter Kontext-Overhead beim Sitzungsstart: ungefähr 600 Tokens für alle Skill-Beschreibungen. Die eigentlichen Skill-Bodies sind noch nicht geladen — sie warten auf Relevanz.

Ich tippe: „Erstelle einen Beitrag für mejba.me über Docker Networking Best Practices."

Claude scannt die Skill-Beschreibungen, identifiziert Aria als relevant und lädt den SKILL.md-Body. Arias Anweisungen sagen Claude, das Content-History-Log zu prüfen, das in ${CLAUDE_PLUGIN_DATA} liegt. Claude liest die Geschichte, bestätigt, dass ich diesen speziellen Blickwinkel noch nicht behandelt habe, und identifiziert zwei bestehende Beiträge, die intern verlinkt werden sollten.

Der Aria-Skill verweist auf das SEO Toolkit. Claude lädt auch diesen Skill, führt Keyword-Analyse durch und bestimmt primäre und sekundäre Keywords. Beide Skills sind jetzt aktiv und arbeiten zusammen.

Claude generiert das vollständige Content-Paket — Metadaten, 3.500-Wörter-Artikel, markengerechter Footer. Das Wortzähl-Script in aria/scripts/ validiert die Länge. Wenn es unter 3.000 oder über 5.000 Wörter ist, passt Claude es an. Das Content-History-Log wird mit den neuen Beitragsdetails aktualisiert.

Gesamtzeit: etwa acht Minuten. Dieselbe Arbeit ohne Skills — Markenrichtlinien erklären, SEO-Anforderungen, Content-Architektur, verbotene Phrasen, Footer-Format, interne Verlinkungsstrategie — würde vierzig Minuten Prompt Engineering kosten, bevor Claude überhaupt anfängt zu schreiben.

Das ist kein Produktivitäts-Hack. Das ist eine fundamentale Verschiebung in der Art, wie ich mit KI arbeite.

Die drei Fehler, die ich immer wieder sehe (und manchmal noch mache)

Nachdem ich einem Dutzend Entwicklern geholfen habe, ihre eigenen Skill-Systeme aufzusetzen, tauchen dieselben drei Fehler immer wieder auf.

Fehler eins: Skills für Dinge bauen, die Claude bereits gut kann. Wenn du einen Skill schreibst, der Claude erklärt, wie man eine For-Schleife schreibt oder eine JSON-Antwort strukturiert, verschwendest du Mühe. Skills sollten Wissen kodieren, das Claude nicht hat — deine spezifischen Konventionen, deine internen APIs, die Fehlermodi deines Teams. Teste das, indem du die Aufgabe zuerst ohne den Skill ausführst. Wenn die Ausgabe bereits 80% von dem ist, was du willst, brauchst du wahrscheinlich keinen Skill. Du brauchst einen Satz in deiner CLAUDE.md-Datei.

Fehler zwei: Skills nach der Erstellung nie aktualisieren. Skills sind keine einmaligen Artefakte. Claude verbessert sich mit jedem Modell-Update. Deine Codebase entwickelt sich weiter. Deine Team-Konventionen ändern sich. Ein Skill, der vor drei Monaten perfekt war, kann heute aktiv schädlich sein. Ich plane ein monatliches „Skill Audit" — dreißig Minuten, in denen ich jeden Skill überprüfe, veraltete Gotchas beschneide und teste, ob der Skill die Ausgabe im Vergleich zum Betrieb ohne ihn noch messbar verbessert.

Fehler drei: Skills zu breit machen. Ein „Development Helper"-Skill, der Codestil, Testing, Deployment und Dokumentation abdeckt, sind vier Skills in einem Trenchcoat, die so tun, als wären sie einer. Teile ihn auf. Jeder Skill sollte einen einzigen, klaren Zweck haben, den du in einem Satz formulieren kannst. Wenn du das Wort „und" brauchst, um zu beschreiben, was ein Skill tut, sind es wahrscheinlich zwei Skills.

Es gibt einen vierten Fehler, der subtiler und schwerer zu erkennen ist: Nicht in Verifikations-Skills investieren. Ich habe Monate damit verbracht, Generierungs-Skills zu bauen — Skills, die Claude helfen, Dinge zu erstellen. Aber ich investierte kaum in Skills, die Claude helfen, seine eigene Ausgabe zu verifizieren. Verifikations-Skills sind langweilig zu bauen, aber sie fangen Fehler, bevor sie die Produktion erreichen. Ein Signup-Flow-Driver, der die vollständige User Journey testet. Ein Checkout-Verifizierer, der Stripe-Testkarten durchspielt. Ein Deployment-Smoke-Test, der bestätigt, dass Health Checks bestehen. Diese Skills produzieren keine beeindruckenden Ausgaben. Sie verhindern peinliche Fehler. Wenn ich zurückgehen und meine Skill-Bauzeit umverteilen könnte, würde Verifikation 40% des Budgets bekommen statt der 10%, die sie tatsächlich bekam.

Was als Nächstes für Skills kommt (und worauf ich hinarbeite)

Das Skills-Ökosystem per März 2026 reift schnell. Anthropics offizieller Skill-Marktplatz hat explosives Wachstum erlebt — der Frontend-Design-Skill allein hat über 277.000 Installationen. Community-Plattformen wie skills.sh bieten durchsuchbare Verzeichnisse, organisiert nach Kategorie, Autor und Installationsanzahl. Der npx skills add-Befehl hat die Installation trivial einfach gemacht.

Aber die echte Evolution liegt darin, wie Skills zusammenstellen und kommunizieren. Derzeit wird Skill-Komposition über Namensverweise in Markdown abgewickelt — „rufe den X-Skill auf." Es funktioniert, aber es ist manuell und fragil. Ich erwarte natives Dependency Management innerhalb des nächsten Jahres, bei dem die Frontmatter eines Skills Voraussetzungen deklarieren kann, die automatisch geladen werden.

Ich beobachte auch die Schnittstelle von Skills und Hooks aufmerksam. On-Demand-Hooks, die pro Skill aktiviert werden, sind bereits mächtig. Der nächste Schritt sind Hooks, die sich über Skills hinweg koordinieren — ein Code-Review-Skill, der automatisch einen Testing-Skill triggert, der eine Deployment-Readiness-Prüfung triggert, alles in einer verifizierten Pipeline. Derzeit verdrahte ich diese manuell. Bald werden sie deklarativ sein.

Die interessanteste Grenze sind Skills, die lernen — nicht durch Training, sondern durch strukturiertes Logging und Selbstreflexion. Ich habe einen Prototyp mit meiner Content-Pipeline laufen, bei dem Claude sein History-Log wöchentlich überprüft, Muster in den Bearbeitungen identifiziert, die ich vorgenommen habe, und Ergänzungen zur Liste verbotener Phrasen vorschlägt. Wir sind noch nicht bei autonomer Selbstverbesserung. Aber die Bausteine sind alle da.

Die Skills, die in einem Jahr am meisten zählen werden, sind nicht die auffälligsten. Es sind die, die still deine tägliche Arbeit verbessern und jeden Monat etwas schärfer werden, weil jemand sich dreißig Minuten genommen hat, die Gotchas zu überprüfen.

Fang dort an. Baue diese Woche einen Skill für die Aufgabe, die du am häufigsten erledigst. Halte die Anweisungen minimal und die Gotchas-Sektion leer. Nutze ihn einen Monat lang. Füge jeden Fehler zu Gotchas hinzu. Am Ende des Monats hast du etwas wirklich Nützliches. Und du wirst verstehen, auf eine Weise, die keine Dokumentation lehren kann, warum Skills der mächtigste Erweiterungspunkt in Claude Code sind.

Was ist der eine Workflow, den du jeden Tag wiederholst und der immer noch manuelles Prompting erfordert? Das ist dein erster Skill. Geh und bau ihn.

Häufig gestellte Fragen

Wie viele Claude Code Skills sollte ich gleichzeitig installiert haben?

Halte Repo-Level-Skills auf drei bis fünf pro Repository und persönliche Skills unter fünfzehn insgesamt. Darüber hinaus verbrauchen Skill-Beschreibungen spürbaren Kontext und Trigger-Konflikte werden schwerer zu handhaben. Qualität und Spezifität schlagen Quantität — jedes Mal.

Was ist der Unterschied zwischen einem Claude Code Skill und einer CLAUDE.md-Datei?

CLAUDE.md wird bei jedem Gespräch in einem Projekt geladen und deckt allgemeinen Codebase-Kontext ab. Skills laden nur, wenn sie durch relevante Anfragen getriggert werden, können Scripts und Referenzdateien enthalten und unterstützen Hooks. Verwende CLAUDE.md für universelle Projektfakten; verwende Skills für spezifische Workflows.

Wie oft sollte ich meine Claude Code Skills aktualisieren?

Monatliche Reviews funktionieren gut für die meisten Teams. Prüfe jeden Skill gegen Claudes aktuelle native Fähigkeiten, beschneide veraltete Gotchas und teste, ob der Skill die Ausgabe im Vergleich zum Betrieb ohne ihn noch messbar verbessert. Modell-Updates können Capability-Uplift-Skills schnell obsolet machen.

Können Claude Code Skills andere Skills aufrufen?

Ja, über Namensverweise in deinen SKILL.md-Anweisungen. Schreibe „rufe den [Skill-Name]-Skill für diesen Schritt auf" und Claude wird ihn triggern, wenn er installiert ist. Natives Dependency Management gibt es noch nicht, also halte Verweise unidirektional, um zirkuläre Schleifen zu vermeiden.

Wo sollte ich Daten speichern, die meine Skills zwischen Sitzungen generieren?

Verwende die ${CLAUDE_PLUGIN_DATA}-Umgebungsvariable, die ein stabiles Pro-Plugin-Verzeichnis bietet, das bei Skill-Upgrades erhalten bleibt. Speichere niemals persistente Daten im Skill-Verzeichnis selbst — es kann bei Updates überschrieben werden.

Lass uns zusammenarbeiten

Du suchst Hilfe beim Aufbau von KI-Systemen, bei der Automatisierung von Workflows oder bei der Skalierung deiner technischen Infrastruktur? Ich helfe dir gerne.

• Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io