
Skills in Claude Code behandeln Arbeitsanweisungen für KI-Agenten wie Code: schreiben, versionieren, verteilen, überarbeiten. Ein Skill ist ein Ordner mit einer SKILL.md aus YAML-Frontmatter und Markdown-Anweisungen, reviewbar und eincheckbar wie jede andere Quelle.
Der Kern ist Progressive Disclosure: Der Agent lädt zunächst nur Name und Beschreibung, die vollständigen Anweisungen erst bei passender Aufgabe. So bleiben Dutzende Skills nutzbar, ohne den Kontext zu überladen.
Der eigentliche Gewinn ist organisatorisch: Konventionen durchlaufen Pull Requests, neue Teammitglieder erben sie mit dem Clone. Prompts skalieren nicht. Skills schon.
Empfehlung: nicht mit einer Skill-Bibliothek starten, sondern mit dem Ablauf, der heute am häufigsten neu erklärt wird.
Wiederkehrende Aufgaben folgen festen Regeln, nur liegen diese Regeln selten dort, wo ein KI-Assistent sie lesen kann. Skills in Claude Code machen aus implizitem Teamwissen versionierbare Artefakte.
Die erste Session mit einem Coding-Agenten beeindruckt, die zwanzigste ermüdet. Nicht weil das Modell schlechter wird, sondern weil dieselben Rahmenbedingungen immer wieder neu erklärt werden müssen: Welche Layer-Regeln gelten? Wie sieht ein Commit aus, den das Team akzeptiert? Welche Abschnitte gehören in ein Architecture Decision Record? Die Antworten stecken in einzelnen Köpfen oder in einem Prompt, den jemand vor drei Wochen formuliert und danach verloren hat. Damit verschiebt sich das Problem: Es geht nicht um die Fähigkeiten des Modells, sondern um die Reproduzierbarkeit seiner Anwendung. Skills in Claude Code behandeln Arbeitsanweisungen für Agenten deshalb wie Code: schreiben, versionieren, verteilen, überarbeiten.

Ein guter Prompt ist ein Wegwerfartefakt. Er entsteht iterativ im Dialog und verschwindet mit dem Chatverlauf. Das hat drei Folgen.
Redundanz. Wer täglich KI-gestützte Code-Reviews durchführt, tippt jedes Mal dieselben Anforderungen: Nullable-Handling prüfen, fehlende Tests melden, generierte Migrationen ignorieren, Befunde nach Schweregrad sortieren. Jede Wiederholung ist eine Gelegenheit, etwas zu vergessen.
Varianz. Zehn Entwickler formulieren zehn Prompts für dieselbe Aufgabe. Die Ergebnisse unterscheiden sich systematisch, weil das Modell jede Lücke in der Anweisung mit plausiblen Standardannahmen füllt. Wer nichts zur Fehlerbehandlung sagt, bekommt Exceptions statt eines Result-Patterns. Das ist kein Modellfehler, sondern ein Spezifikationsproblem.
Wissensverlust. Der optimierte Review-Prompt des Seniors landet im besten Fall in einem Teamchat und verrottet dort, ohne Änderungsverlauf und ohne Ort, an dem neue Kollegen ihn zwangsläufig finden.
Ein Skill ist ein Ordner mit einer Datei SKILL.md, optional ergänzt um Templates, Referenzdokumente und ausführbare Skripte. Die Datei enthält YAML-Frontmatter und darunter Markdown-Anweisungen. Verpflichtend sind genau zwei Felder: name und description.
---
name: adr-writer
description: Erstellt und aktualisiert Architecture Decision Records nach
dem internen Template. Nutze diesen Skill, wenn eine Architekturentscheidung
dokumentiert oder ein bestehendes ADR fortgeschrieben werden soll.
---
# Architecture Decision Records
## Ablauf
1. Nächste freie Nummer aus `docs/adr/` ermitteln.
2. Template aus `template.md` in diesem Skill-Ordner verwenden.
3. Betroffene Module aus dem Code verifizieren, nicht annehmen.
## Regeln
- Keine Entscheidung ohne zwei verworfene Alternativen.
- Status ausschließlich: proposed | accepted | superseded
Mehr braucht es nicht. Die Einfachheit ist Absicht: Ein Skill ist eine Textdatei, reviewbar, diffbar und eincheckbar wie jede andere Quelle.
Der entscheidende Mechanismus ist das gestufte Laden. Beim Sessionstart kennt Claude Code nur die Metadaten aller Skills, also Name und Beschreibung, einige Dutzend Token pro Skill. Erst wenn eine Aufgabe zur Beschreibung passt, lädt der Agent die vollständige SKILL.md; referenzierte Zusatzdateien folgen noch später. Ein Team kann also dreißig Skills bereitstellen, ohne den Kontext mit dreißig Regelwerken zu belasten.
Die Beschreibung wird damit zum wichtigsten Feld: Sie ist keine Dokumentation für Menschen, sondern das Routing-Kriterium des Agenten. „Hilft bei Dokumentation“ löst kaum je aus; wer Auslösesituationen und Schlüsselbegriffe nennt, trifft zuverlässig.
Zweiter, oft übersehener Punkt: Skills dürfen Skripte enthalten, die der Agent per Shell ausführt. So lassen sich deterministische Teilschritte aus dem Sprachmodell herausziehen: Ein Modell soll nicht schätzen, was ein grep exakt beantwortet.
Skills konkurrieren nicht mit den übrigen Steuerungsmechanismen. Die Projektanweisung CLAUDE.md liegt dauerhaft im Kontext, richtig für wenige universelle Fakten wie Tech-Stack und Build-Kommandos. Ein Slash-Command muss explizit aufgerufen werden, jemand muss ihn also kennen. Einen Skill wählt der Agent je nach Situation selbst. Faustregel: Was in jeder Session gilt, gehört in die Projektanweisung; was situativ gilt, in einen Skill.
Persönliche Skills liegen im Benutzerprofil und begleiten den Entwickler über alle Projekte hinweg. Projektbezogene Skills liegen im Repository unter .claude/skills/ und werden mit dem Code ausgeliefert. Für die organisationsweite Verteilung nutzt Claude Code Plugins aus Marketplaces, die sich aus einem Git-Repository speisen.
Der organisatorische Effekt ist größer als der technische. Ein eingecheckter Skill durchläuft Pull Requests, mit Autor, Historie und Reviewern. Die Diskussion über „wie wir reviewen“ findet als Kommentar an einer konkreten Zeile statt, nicht im Meeting. Neue Teammitglieder erben die Konventionen mit dem Clone. Weil dasselbe Format auch in der Claude-App und über die API funktioniert, bleibt ein Skill über Umgebungen hinweg nutzbar.
Code-Review-Standardisierung. Ausgangslage: Zwölf Entwickler, schwankende Ergebnisse: manche Reviews melden Formatierungsdetails, andere übersehen fehlende Autorisierungsprüfungen. Der Skill fixiert Prüfreihenfolge, Schweregradlogik und Ausgabeformat, verweist auf eine Datei mit sicherheitsrelevanten Prüfpunkten und enthält ein Skript, das geänderte Dateien gegen den Zielbranch ermittelt. Ergebnis: Reviews werden vergleichbar; Erkenntnisse aus Produktionsvorfällen landen als Pull Request im Skill und wirken ab dem nächsten Merge für alle.
Architekturdokumentation. Ausgangslage: Die Doku ist sechs Monate alt, weil das Zusammensuchen von Modulgrenzen aufwendig ist. Der Skill beschreibt, wie der Agent eine Ist-Darstellung ableitet: Einstiegspunkte identifizieren, Projektreferenzen auswerten, Abhängigkeitsrichtungen gegen die Layer-Regeln prüfen, Abweichungen als Verstoß markieren. Ergebnis: Dokumentation wird zur wiederholbaren Ableitung. Interessanter ist oft der Nebeneffekt: Der Abgleich deckt schleichende Verletzungen der Schichtentrennung auf.
Technische Texte. Ausgangslage: Terminologie und Struktur unterscheiden sich je Autor, das Lektorat korrigiert immer dieselben Punkte. Der Skill hält Zielgruppe, Gliederungsraster, verbindliche Übersetzungen und eine Negativliste für Floskeln fest, sowie zwei Referenztexte zur Kalibrierung. Ergebnis: Die erste Fassung trifft den Hausstil; das Lektorat verlagert sich von Formalien zu Argumentation.
Skills lösen ein Spezifikationsproblem, kein Erkenntnisproblem. Wo eine Aufgabe echte Abwägung erfordert, etwa ob ein Modul überhaupt aufgeteilt werden sollte, hilft kein Regelwerk. Drei Risiken sind praktisch relevant: Veraltete Anweisungen wirken aktiv schädlich, weil sie konsistent falsche Ergebnisse produzieren; Skills brauchen deshalb Ownership und regelmäßige Prüfung. Schlecht formulierte Beschreibungen führen zu stummen Skills: Das Ergebnis sieht plausibel aus, entspricht aber nicht dem Standard. Und vierzig überlappende Skills erzeugen Auswahlunsicherheit statt Nutzen.
Für die Einführung bewährt sich: mit zwei oder drei täglichen Abläufen beginnen, bestehende Prompts als Ausgangsmaterial nutzen, Skills im Repository reviewen und Ergebnisse stichprobenartig gegen die Regeln prüfen.
Skills verschieben die Arbeit an KI-Assistenz von der Interaktion zur Spezifikation. Der Gewinn liegt weniger in gesparten Tastenanschlägen als in Reproduzierbarkeit: Ergebnisse werden vergleichbar, Standards überprüfbar, Erfahrungswissen übertragbar. Teams sollten nicht mit einer Skill-Bibliothek starten, sondern mit dem Ablauf, der heute am häufigsten neu erklärt wird: der beste Kandidat und der billigste Test.
Mittelfristig entsteht damit eine neue Kategorie von Repository-Inhalten: neben Code, Tests und Infrastruktur die maschinenlesbare Beschreibung der eigenen Arbeitsweise. Wer sie pflegt, richtet jeden Agenten aus, der künftig auf der Codebasis arbeitet.
