Claude Code Skills Vorlagen für Entwicklung und Tests

Symptom: Ihre Claude-Code-Skills liefern wechselnde Ergebnisse, ändern zu viele Dateien oder melden „erfolgreich“, obwohl Tests fehlen.
Schnellste Lösung: Erstellen Sie keine große Universal-Skill, sondern fünf kleine, prüfbare Vorlagen mit Trigger, Eingaben, Arbeitsschritten, Stop-Regeln und Abnahmekriterium.

Diese Anleitung ist für Sie geeignet, wenn Sie als Entwickler schnell eine persönliche Skills-Bibliothek aufbauen, als Entwicklungsleitung einheitliche Abläufe vorgeben oder als Plattformteam wiederkehrende Test-, Dokumentations- und Release-Aufgaben an einen entfernten Agenten übergeben möchten.

Zuletzt aktualisiert am 12.08.2026; die technischen Angaben wurden anhand der aktuellen offiziellen Dokumentation und der Agent-Skills-Spezifikation geprüft.

Die richtige Grundstruktur zuerst festlegen

Eine Skill ist keine Sammlung möglichst kluger Anweisungen, sondern ein begrenzter Arbeitsablauf. Claude Code lädt eine Skill entweder automatisch anhand ihrer Beschreibung oder auf direkte Anforderung über /skill-name. Der Einstiegspunkt ist eine Datei namens SKILL.md; zusätzliche Referenzen, Beispiele und Skripte können in derselben Skill-Verzeichnisstruktur liegen. (code.claude.com)

Die technische Mindeststruktur sieht so aus:

code-review/
├── SKILL.md
├── references/
│   └── review-rules.md
└── scripts/
    └── collect-diff.sh

Die Spezifikation verlangt für das Frontmatter mindestens name und description. Der Name darf höchstens 64 Zeichen lang sein, die Beschreibung höchstens 1.024 Zeichen. Für die eigentlichen Anweisungen empfiehlt die Spezifikation, den Hauptteil unter 500 Zeilen und ungefähr unter 5.000 Tokens zu halten; ausführliche Informationen gehören in Referenzdateien. (agentskills.io)

Der wichtigste Unterschied zwischen einer brauchbaren und einer riskanten Vorlage liegt in der Beschreibung. „Hilft bei Codequalität“ ist zu allgemein. „Verwenden, wenn ein Pull-Request-Diff auf Fehler, Sicherheitsrisiken oder fehlende Tests geprüft werden soll; keine Dateien ändern“ grenzt den Auslöser und die erlaubte Tätigkeit deutlich besser ein.

Erste Entscheidung: Welche Vorlage sollte zuerst in Ihre Bibliothek?

Wählen Sie die erste Skill nicht nach ihrer technischen Wirkung, sondern nach der Häufigkeit und dem Risiko des Ablaufs. Ein automatisch ausgelöstes Refactoring ist gefährlicher als eine manuell gestartete Dokumentationszusammenfassung. Eine Release-Skill darf wiederum niemals stillschweigend veröffentlichen, nur weil der Build erfolgreich war.

Wenn Ihr Team noch keine einheitlichen Testbefehle oder Abnahmekriterien besitzt, beginnen Sie mit einer lesenden Code-Review-Skill. Sie zeigt Lücken im Prozess, ohne direkt Produktionscode zu verändern. Erst danach lohnt sich eine Testreparatur-Skill, weil diese bereits Schreibrechte und ein zuverlässiges Testsystem voraussetzt.

Zweite Entscheidung: Eine Code-Review-Skill mit beweisbaren Befunden bauen

Eine gute Code-Review-Skill muss drei Dinge trennen: Was sieht der Agent statisch im Code, was wurde mit einem Werkzeug geprüft und was bleibt eine begründete Vermutung.

Beginnen Sie mit einem eingeschränkten Eingang:

---
name: code-review
description: Verwenden Sie diese Skill für die Prüfung eines vorhandenen Diffs auf Fehler, Sicherheitsrisiken, fehlende Tests und mögliche Regressionsquellen. Die Skill liest Dateien und Tests, verändert aber keinen Code.
disable-model-invocation: false
---

Danach sollte der Ablauf diese Reihenfolge einhalten:

1. Lesen Sie den Diff sowie die Projektregeln aus CLAUDE.md.
2. Erfassen Sie betroffene Dateien, öffentliche Schnittstellen und geänderte Tests.
3. Führen Sie nur die bereits dokumentierten Prüfungen aus.
4. Ordnen Sie Befunde mindestens nach Blocker, hoch, mittel und Hinweis.
5. Geben Sie für jeden Befund Datei, Codebereich, Ursache, Auswirkung und Beleg an.
6. Trennen Sie „durch Werkzeug bestätigt“ von „statisch vermutet“.
7. Melden Sie ausdrücklich, wenn keine belastbaren Befunde gefunden wurden.

Die Skill darf keine pauschalen Empfehlungen wie „mehr Tests schreiben“ als fertige Fehler ausgeben. Ein belastbarer Befund lautet stattdessen: „Die Funktion akzeptiert einen leeren Wert, obwohl der aufgerufene Parser diesen Fall nicht behandelt; die relevante Stelle befindet sich in Datei X, und der bestehende Test deckt nur den erfolgreichen Eingabepfad ab.“

Vorteile

• Der Review-Bericht bleibt auf den tatsächlichen Diff begrenzt.
• Das Team kann geprüfte und ungeprüfte Aussagen unterscheiden.
• Sicherheits- und Regressionsrisiken erhalten eine nachvollziehbare Priorität.

Grenzen

• Eine lesende Skill ersetzt keine Laufzeitanalyse oder manuelle Sicherheitsprüfung.
• Fehlende Testdaten können einen Befund nur wahrscheinlich, nicht beweisbar machen.
• Zu breite Beschreibungen führen zu häufigen, unpassenden automatischen Auslösungen.

Die offiziellen Anleitungen unterscheiden zwischen Wissen, wiederverwendbaren Arbeitsabläufen und Werkzeugerweiterungen. Eine Code-Review-Skill sollte deshalb nicht dauerhaft sämtliche Projektregeln enthalten, sondern auf Referenzdateien verweisen, die nur bei Bedarf geladen werden. (code.claude.com)

Dritte Entscheidung: Testreparatur strikt von Testkosmetik trennen

Eine Testreparatur-Skill wird gefährlich, sobald „grüne Tests“ zum einzigen Ziel werden. Der Agent darf daher weder Tests löschen noch Assertions abschwächen, Prüfungen auskommentieren oder die Testkonfiguration so verändern, dass ein Fehler nicht mehr sichtbar ist.

Verwenden Sie für die Vorlage mindestens diese fünf Phasen:

1. Reproduktion: Führen Sie den fehlgeschlagenen Test mit demselben Befehl erneut aus.
2. Eingrenzung: Bestimmen Sie, ob die Ursache im Produktcode, im Test, in Testdaten oder in der Umgebung liegt.
3. Kleinste Korrektur: Ändern Sie nur die Dateien, die für die Ursache erforderlich sind.
4. Gezielte Prüfung: Starten Sie den betroffenen Test und dokumentieren Sie die Ausgabe.
5. Regression: Führen Sie die angrenzende Testsuite oder den vom Projekt festgelegten Prüfbereich aus.

Fehlt eine reproduzierbare Fehlermeldung, muss die Skill anhalten. Sie darf nicht anhand eines vermuteten Fehlers Code umschreiben. Ebenso muss sie stoppen, wenn der vorgeschlagene Fix eine öffentliche Schnittstelle verändert, neue Abhängigkeiten einführt oder die erlaubte Dateiliste überschreitet.

Ein guter Abnahmesatz lautet: „Der Fehler war vor der Änderung reproduzierbar, die Änderung betrifft zwei Dateien, der ursprüngliche Test läuft erfolgreich, und die angrenzende Testsuite zeigt keine neue Abweichung.“ Ohne diesen Vorher-nachher-Nachweis ist „Test bestanden“ zu wenig Information.

Vierte Entscheidung: Refactoring mit Baseline und Stop-Regeln begrenzen

Ein Refactoring Skill sollte niemals mit „Verbessern Sie die Architektur“ beginnen. Das ist kein Arbeitsauftrag, sondern eine Einladung zur Ausweitung des Umfangs. Formulieren Sie stattdessen einen konkreten Zielzustand, etwa die Umbenennung einer internen Funktion, die Entfernung einer Duplizierung in einem Modul oder die Aufteilung einer zu großen Datei.

Vor dem ersten Edit braucht die Skill eine Baseline:

• aktueller Teststatus,
• betroffene Dateien,
• unveränderte öffentliche Schnittstellen,
• erwartete Verhaltenserhaltung,
• erlaubte und verbotene Änderungen.

Teilen Sie das Refactoring in kleine Durchläufe. Nach jedem Durchlauf werden Formatierung, Typprüfung und relevante Tests ausgeführt. Erst wenn diese Prüfungen erfolgreich sind, darf der nächste Teil beginnen. Die Skill sollte außerdem festlegen, dass ein neuer Architekturvorschlag nur als separater Vorschlag im Bericht erscheint und nicht automatisch umgesetzt wird.

Stoppen Sie den Ablauf sofort, wenn:

• eine nicht genannte Datei geändert werden müsste,
• ein Testfehler nicht aus dem aktuellen Schritt erklärbar ist,
• eine öffentliche API oder ein Datenformat betroffen ist,
• eine neue Bibliothek erforderlich wird,
• der Agent einen Test anpassen müsste, um den Code grün zu bekommen.

Diese Begrenzung ist besonders wichtig in Monorepositories. Projekt-Skills können aus .claude/skills/ im Projekt und aus übergeordneten Verzeichnissen erkannt werden; dadurch kann eine lokale Paketregel zusätzlich zu einer zentralen Teamregel greifen. Prüfen Sie vor der Freigabe, welche Skill tatsächlich geladen wurde und ob gleichnamige Ebenen einander überschreiben. (code.claude.com)

Fünfte Entscheidung: Dokumentation nur aus bestätigten Änderungen erzeugen

Eine Dokumentations-Skill sollte aus Diff, Schnittstellen, Testausgaben und bestätigten Akzeptanzkriterien arbeiten. Sie darf keine Funktion beschreiben, nur weil sie im Auftrag erwähnt wurde. Besonders bei API-Dokumentation, Konfigurationshinweisen und Release Notes entstehen sonst Aussagen, die im Code nicht existieren.

Der Ablauf kann so aussehen:

1. Diff und betroffene Schnittstellen lesen.
2. Neue, entfernte und geänderte Verhaltensweisen trennen.
3. Tests als Beleg für tatsächlich bestätigte Abläufe heranziehen.
4. Unbestätigte Punkte als offene Fragen markieren.
5. Nur die vereinbarten Dokumentationsdateien ändern.
6. Die erzeugte Dokumentation gegen den finalen Diff prüfen.

Eine nützliche Vorlage enthält außerdem ein Feld „Nicht dokumentieren“. Dort gehören angenommene Zukunftsfunktionen, nicht ausgeführte Integrationen und unbestätigte Leistungsversprechen hinein. Das verhindert, dass aus einer höflich formulierten Modellannahme eine scheinbar verbindliche Produktbeschreibung wird.

Für die gemeinsame Nutzung sollten Sie projektweite Skills mit dem Repository versionieren. Persönliche Skills eignen sich für eigene Arbeitsweisen, projektweite Skills für den gemeinsamen Prozess und verwaltete Ebenen für verbindliche Unternehmensregeln. Die offizielle Dokumentation beschreibt diese Speicherorte und ihre Prioritätslogik ausdrücklich. (code.claude.com)

Sechste Entscheidung: Release- und Übergabe-Skills manuell auslösen

Eine Release-Skill vereint mehrere Prüfungen, darf aber keine Freigabeentscheidung vortäuschen. Sie kann Build, Testlauf, Versionsabgleich und Änderungszusammenfassung automatisieren; die endgültige Veröffentlichung sollte bei produktionsrelevanten Systemen eine menschliche Bestätigung verlangen.

Eine sinnvolle Reihenfolge ist:

1. Arbeitsbaum und Branchstatus prüfen.
2. Versionsdateien miteinander vergleichen.
3. Build mit dem dokumentierten Befehl ausführen.
4. Schnelltests und anschließend die festgelegte vollständige Testsuite starten.
5. Änderungszusammenfassung aus dem bestätigten Diff erzeugen.
6. Artefakte, Konfiguration und offene Risiken auflisten.
7. Vor der Veröffentlichung auf manuelle Bestätigung warten.

Setzen Sie für diese Skill disable-model-invocation: true, wenn sie niemals automatisch durch eine beiläufige Formulierung ausgelöst werden darf. Die Funktion steuert, ob Claude die Skill selbstständig aufruft; die direkte manuelle Verwendung bleibt davon getrennt. (code.claude.com)

Für die Übergabe an ein Team oder an eine entfernte Arbeitsumgebung muss zusätzlich festgehalten werden, welche Werkzeuge verfügbar sind, ob Netzwerkzugriff nötig ist und welche Zugangsdaten niemals in Logs oder Skill-Dateien erscheinen dürfen. Das ist kein kosmetischer Zusatz: Eine automatisch laufende Release-Skill kann bei falsch gesetzten Berechtigungen mehr verändern als eine reine Review-Skill.

Siebte Entscheidung: Jede Vorlage in einem Minimalprojekt abnehmen

Bevor Sie eine Skill in ein produktives Repository übernehmen, legen Sie ein kleines Prüfprojekt an. Es braucht mindestens einen erfolgreichen Test, einen absichtlich fehlschlagenden Test, eine Datei außerhalb des erlaubten Bereichs und einen Fall mit fehlenden Eingaben.

Prüfen Sie anschließend in dieser Reihenfolge:

1. Wird die Skill bei der vorgesehenen Formulierung ausgelöst?
2. Bleibt sie bei einem fachfremden Auftrag inaktiv?
3. Erkennt sie fehlende Akzeptanzkriterien und hält an?
4. Hält sie die erlaubte Dateiliste ein?
5. Meldet sie ausgeführte und nicht ausgeführte Werkzeuge getrennt?
6. Verhindert sie das Löschen oder Abschwächen von Tests?
7. Ist das Ergebnis anhand des Diff und der Testausgabe nachvollziehbar?

Die Referenzspezifikation stellt für die formale Prüfung ein Validierungswerkzeug bereit. Das ersetzt jedoch nicht die projektspezifische Abnahme, denn ein korrektes Frontmatter garantiert weder passende Trigger noch sichere Änderungen im Zielprojekt. (agentskills.io)

Wenn Ihr Team Claude Code erst konfiguriert, sollten Sie außerdem die Bestellung und Konfiguration der Arbeitsumgebung von der Skill-Prüfung trennen. So bleibt nachvollziehbar, ob ein Fehler aus der Vorlage, dem Projekt oder der Laufzeitumgebung stammt. Bei Berechtigungs- oder Sitzungsproblemen hilft das Hilfezentrum für die Arbeitsumgebung.

Die passende Vorlage nach klaren Bedingungen auswählen

• Wenn die Aufgabe nur Befunde liefern soll, wählen Sie eine Code-Review-Skill mit ausschließlich lesenden Werkzeugen.
• Wenn ein Fehler reproduzierbar ist und die Änderung lokal bleibt, wählen Sie eine Testreparatur-Skill.
• Wenn Verhalten erhalten bleiben muss und mehrere Dateien betroffen sind, wählen Sie eine Refactoring-Skill mit Baseline und Zwischentests.
• Wenn der Diff bereits bestätigt ist und keine neue Funktion erfunden werden darf, wählen Sie eine Dokumentations-Skill.
• Wenn Build, Tests und Versionsprüfung zusammenlaufen, wählen Sie eine manuell gestartete Release-Skill.
• Wenn Akzeptanzkriterien, Testbefehl oder Änderungsbereich fehlen, brechen Sie ab und fordern Sie diese Angaben an, statt eine allgemeine Universal-Skill zu verwenden.

Die beste Claude Code Skills Vorlage ist damit nicht die längste und auch nicht die mit den meisten Werkzeugen. Sie ist die kleinste Vorlage, deren Trigger, Eingaben, Grenzen und Ergebnis in einem Minimalprojekt überprüfbar bleiben. Bauen Sie zuerst Code Review, Testreparatur, kontrolliertes Refactoring, Änderungsdokumentation und Release-Prüfung auf; erweitern Sie die Bibliothek erst, wenn eine konkrete Wiederholung im Team nachweislich bleibt.

Wenn Sie diese Skills dauerhaft für Tests, Builds oder Releases ausführen möchten, prüfen Sie zusätzlich eine isolierte Remote-Entwicklungsumgebung. Ein lokaler Rechner kann durch fehlende Laufzeitabhängigkeiten, wechselnde Berechtigungen und belegte Ressourcen ausbremsen; eine gemeinsam genutzte Umgebung erschwert dagegen reproduzierbare Zustände und Datenschutzkontrollen. Für kurzfristige Projekte, parallele Agent-Aufgaben oder eine getrennte Abnahme kann das Mieten einer Mac-Umgebung über Macstripe deshalb die sauberere Lösung sein: Sie vermeiden den Kauf zusätzlicher Hardware, trennen Testläufe vom Arbeitsplatz und können die Skill zuerst unter realen Bedingungen validieren, bevor Sie den Ablauf in Ihre langfristige Infrastruktur übernehmen.

Häufig gestellte Fragen

Welche Claude Skills Vorlagen eignen sich für den täglichen Entwicklungsbetrieb?

Für den täglichen Betrieb sind fünf Vorlagentypen besonders sinnvoll: Code Review, Testreparatur, kontrolliertes Refactoring, Änderungsdokumentation und Release-Prüfung. Beginnen Sie mit den beiden Vorlagen, bei denen heute die meisten manuellen Wiederholungen entstehen. Jede Vorlage sollte einen klaren Auslöser, definierte Eingaben, einen begrenzten Arbeitsbereich und ein überprüfbares Ergebnis besitzen.

Wie schreibt man eine Code-Review-Skill, ohne nur allgemeine Hinweise zu erhalten?

Eine belastbare Code-Review-Skill verlangt zunächst Diff, betroffene Dateien, relevante Tests und Projektregeln. Danach muss sie Befunde nach Schweregrad ordnen und jede Aussage mit einer konkreten Codeposition oder einem Testergebnis verbinden. Ungeprüfte Vermutungen gehören in einen getrennten Abschnitt. So unterscheiden Sie statische Hinweise von tatsächlich reproduzierten Fehlern.

Welche Schritte muss eine Skill zur Testreparatur abdecken?

Die Reihenfolge sollte Reproduktion, Eingrenzung, kleinste Korrektur, gezielten Testlauf und Regressionstest enthalten. Scheitert die Reproduktion, muss die Skill anhalten und die fehlenden Bedingungen melden. Tests zu löschen, Assertions abzuschwächen oder Prüfungen zu überspringen, darf ausdrücklich nicht erlaubt sein. Die Abnahme besteht aus einem nachvollziehbaren Vorher-nachher-Bericht.

Wie bleibt ein Refactoring mit Claude Code innerhalb eines kontrollierten Rahmens?

Definieren Sie vor dem ersten Edit eine Liste erlaubter Dateien, ein unverändertes Verhalten und eine Test-Baseline. Nach jeder kleinen Änderung laufen die relevanten Prüfungen erneut. Stop-Regeln greifen bei neuen Abhängigkeiten, API-Änderungen, unerwarteten Testfehlern oder Überschreitungen des Dateibereichs. Architekturänderungen werden nicht automatisch aus einem lokalen Refactoring abgeleitet.

Wie lassen sich Claude Skills Vorlagen im Entwicklungsteam wiederverwenden?

Legen Sie gemeinsam genutzte Skills im Projektverzeichnis ab und versionieren Sie sie mit dem Quellcode. Ergänzen Sie jede Vorlage um Zuständigkeit, unterstützte Werkzeuge, erwartete Eingaben und ein Beispiel für eine erfolgreiche Abnahme. Änderungen an einer Skill sollten wie Codeänderungen geprüft werden. Für persönliche Experimente bleibt ein separater Benutzerbereich sinnvoll.