Claude Code Skills: Slash-Befehle für den Teamalltag

Ein brauchbarer Teambefehl legt fest, welche Eingaben nötig sind, welche Belege geprüft werden und wie die Antwort aussehen soll. Er funktioniert wie ein Arbeitsauftrag, der direkt neben dem Code liegt. Ein Aufruf mit seinem Namen füllt diesen Auftrag für die aktuelle Aufgabe aus.

Den Anfang machen /plan, /diff, /context und /compact. Danach kommt /team-pr-check aus den Vorlagen weiter unten hinzu. Reviews eignen sich besonders gut als erster Anwendungsfall: Fragen zu Berechtigungen, Daten und Tests stellen sich bei jeder Änderung erneut.

Welche integrierten Claude-Code-Befehle sind wichtig?

Diese Befehle stehen am Anfang einer Nachricht in Claude Code. Eckige Klammern kennzeichnen optionale Argumente, spitze Klammern erforderliche. Die Auswahl übernimmt die Syntax aus Anthropics aktueller Befehlsreferenz, geprüft am 13. Oktober 2026. Welche Befehle verfügbar sind, hängt von Plattform, Tarif und Umgebung ab.

/compact passt, wenn dieselbe Aufgabe weitergeht; /clear, wenn eine neue beginnt. Für ein laufendes Feature eignet sich etwa die Anweisung /compact keep the acceptance criteria, unresolved risks, and exact test commands.

/release-notes öffnet das Changelog von Claude Code. Der Befehl verfasst keine Release Notes für die eigene Anwendung. Die Vorlage weiter unten trägt deshalb bewusst einen anderen Namen.

Wie sich diese Befehle sinnvoll in den Arbeitsalltag einfügen, zeigt der Leitfaden Claude Code: Best Practices.

Auch mitgelieferte Skills stehen im Befehlsmenü

Manche Slash-Einträge geben Claude einen Arbeitsablauf vor. Das sind mitgelieferte Skills, die sich von den fest eingebauten Steuerbefehlen der CLI unterscheiden:

• /code-review prüft einen Diff oder ein anderes unterstütztes Prüfziel. /review ist der zugehörige Alias. Mit --fix werden Änderungen angefordert, mit --comment die Veröffentlichung von Review-Kommentaren.
• /simplify prüft geänderten Code auf Bereinigungsmöglichkeiten und setzt Korrekturen um.
• /verify baut die Anwendung und führt sie aus, um ihr Verhalten zu prüfen.
• /doctor untersucht Einrichtungsprobleme und schlägt Lösungen vor.

Wer zunächst Befunde sehen möchte, bevor etwas geändert wird, wählt ein reines Review. Die vollständige Syntax, Voraussetzungen und Verfügbarkeit stehen bei den mitgelieferten Einträgen in der Befehlsreferenz.

Claude Code Skills: So werden eigene Befehle angelegt

Für neue Abläufe gehört die Markdown-Anleitung unter .claude/skills/<name>/SKILL.md ins Repository. Ein Commit stellt sicher, dass alle im Team denselben Ablauf erhalten. Persönliche Abläufe liegen unter ~/.claude/skills/<name>/SKILL.md.

Das ältere Format .claude/commands/<name>.md funktioniert weiterhin. Beide Varianten erzeugen Befehle nach dem Muster /<name>. Ein Skill-Verzeichnis bietet außerdem Platz für Vorlagen, Referenzdokumente und Skripte. Je umfangreicher der Ablauf wird, desto sinnvoller ist dieses Format. Anthropics Skill-Leitfaden

Woher kommen Befehle aus Plugins und MCP?

Plugins bündeln Funktionen zur Wiederverwendung. Ihre Ordner skills/<name>/SKILL.md erzeugen Befehle mit Namensraum, etwa /plugin-name:skill-name. Ältere Plugin-Befehle liegen in commands/. Diese Ordner gehören ins Stammverzeichnis des Plugins, neben das Verzeichnis .claude-plugin/ mit dem Manifest, nicht hinein. /plugin verwaltet Plugins; nach Änderungen übernimmt /reload-plugins den neuen Stand. Plugin-Komponenten

Solange ein Ablauf zu einer einzelnen Codebasis gehört, reichen zunächst Projekt-Skills. Ein Plugin wird interessant, sobald derselbe Ablauf über mehrere Repositorys hinweg gepflegt und verteilt werden soll. Der Leitfaden zu den besten Claude Code Plugins stellt bestehende Pakete vor, deren Prüfung sich vor einer Eigenentwicklung lohnt.

MCP-Prompts stammen von verbundenen Servern. MCP, das Model Context Protocol, verbindet Claude Code mit externen Tools und Daten. Ein Server kann darüber hinaus wiederverwendbare Prompts bereitstellen. Im Menü erscheinen sie als /servername:promptname (MCP); auch /mcp__servername__promptname ruft sie auf. Sie sind nur sichtbar, wenn der verbundene Server diese Prompts anbietet. Eine Integration mit Tools liefert nicht automatisch jeden gewünschten Prompt mit. Dokumentation zu MCP-Prompts

Die Argumente eines MCP-Prompts werden an Leerraumzeichen getrennt und richten sich nach den vom Server deklarierten Parametern. Das Ergebnis des Prompts fließt in das Gespräch ein. Die Argumentverarbeitung eines Server-Prompts ist also nicht ohne Weiteres mit der eines lokalen Skills gleichzusetzen.

Die Datei anlegen und Eingaben für die Aufgabe übergeben

Als Frontmatter bezeichnet man den kleinen YAML-Konfigurationsblock vor den Markdown-Anweisungen. Sein einleitendes --- muss in der ersten Zeile der Datei stehen. Für die folgenden Vorlagen sind diese Felder relevant:

allowed-tools erteilt Berechtigungen; es beschränkt die Nutzung nicht auf die dort genannten Tools. Alle Frontmatter-Felder sind optional, description wird empfohlen. Ältere Befehlsdateien akzeptieren dieselben Felder mit Ausnahme von name und paths. Frontmatter-Referenz

Argumente: $ARGUMENTS setzt die gesamte Eingabezeichenfolge ein. $0 oder $ARGUMENTS[0] steht für das erste Argument, $1 für das zweite. Benannte Argumente werden der Reihe nach den Positionen zugeordnet. Ein Positionsargument aus mehreren Wörtern gehört in Anführungszeichen. argument-hint dokumentiert die Eingaben; prüfen muss sie weiterhin der Ablauf selbst. Argumentersetzung

Die Vorlagen verzichten auf name, sodass der Ordner den Namen vorgibt. Ihr Frontmatter funktioniert auch im älteren Befehlsdateiformat. Dauerhafte Fakten zum Repository gehören ins Teamgedächtnis CLAUDE.md, die Schritte für eine bestimmte Aufgabe in den jeweiligen Skill.

Fünf eigene Befehle als Vorlagen fürs Team

Für jede Vorlage wird der angegebene Ordner angelegt und der zugehörige Block in SKILL.md eingefügt. /reload-skills liest die neuen Dateien ein. Die Vorlagen wurden für diesen Artikel erstellt und lassen sich anpassen. Sie sind weder mitgelieferte Anthropic-Befehle noch als Testergebnisse zu verstehen.

Die Reihenfolge beginnt mit wiederholbaren technischen Prüfungen und geht anschließend zur Kommunikation über. Wo möglich, arbeiten die Vorlagen mit Belegen aus dem lokalen Repository. Ein angebundener Issue-Tracker oder PR-Dienst ist für ein nützliches Ergebnis nicht erforderlich.

PR-Checkliste für Änderungen im Umfeld von Kundendaten

Ein kleines SaaS-Team könnte diese Vorlage vor dem menschlichen Review einsetzen. Sie stellt auch unter Zeitdruck dieselben Fragen zu Mandantentrennung, Autorisierung und Testabdeckung. Ihr Nutzen liegt in einer verlässlicheren Übergabe: Jeder Befund wird mit einer Fundstelle und einem konkreten Fehlerszenario verknüpft.

Unter .claude/skills/team-pr-check/SKILL.md speichern. Der Aufruf /team-pr-check main prüft den aktuellen Branch gegenüber seiner gemeinsamen Ausgangsbasis mit main.

---
description: Review a branch against the team's business-risk checklist
argument-hint: "[base-ref]"
disable-model-invocation: true
---

Review the current branch against this base ref: $ARGUMENTS
If no base is supplied, ask for it. Confirm it exists locally.
Read CLAUDE.md and any repository review guidance first.
Inspect the diff from the merge base to HEAD. Report uncommitted
changes separately; do not silently mix them into the branch review.

Check:
- Authorization and tenant boundaries on every changed data path.
- Validation, failure handling, retries and duplicate side effects.
- Schema compatibility, rollout assumptions and rollback options.
- Regression coverage for the changed behavior.
- Secrets, sensitive logs and changes to public contracts.

For each finding: severity, file and line, triggering scenario,
user impact and a concrete repair or test. Separate verified findings
from questions. Mark checks you could not assess as unknown.
Return findings first, then the checklist with pass/fail/unknown
and supporting evidence. If none are found, say so and name gaps.
Review only. Do not edit files, post comments, approve or merge.

Eine Checkliste lohnt sich, wenn sie die tatsächlichen Fehlermuster des eigenen Produkts abbildet. Allgemeine Punkte sollten den relevanten Grenzen weichen, etwa der Zuordnung zu einem Konto, dem Abrechnungsstatus oder Berechtigungen, die über Teams vererbt werden.

Reproduzierbare Fehler zuerst mit einem Test absichern

Wer als Gründer ein laufendes Produkt betreut, könnte diese Vorlage bei einer Fehlermeldung mit konkreten Reproduktionsschritten nutzen. Sie macht das fehlerhafte Verhalten und den Regressionstest zum festen Teil des Arbeitsauftrags. So bleibt es nicht bei einem Patch, der lediglich plausibel aussieht.

Unter .claude/skills/team-test-first-fix/SKILL.md speichern. Der Aufruf lautet /team-test-first-fix duplicate webhook events create duplicate invoices.

---
description: Reproduce a bug with a failing test before fixing it
argument-hint: "[bug description or local issue file]"
disable-model-invocation: true
---

Bug: $ARGUMENTS
If the expected behavior is unclear, ask before changing code.
Read CLAUDE.md, inspect the working tree and preserve unrelated edits.
Find the relevant code and the repository's existing test runner.
Use local fixtures or mocks; do not call production services.

Add the smallest regression test that demonstrates the reported bug.
Run it before changing implementation. Confirm that it fails for
this bug, not because the environment or test setup is broken.
If you cannot demonstrate that failure, explain the blocker and stop.

Make the smallest implementation change that fixes the behavior.
Rerun the regression test and relevant nearby tests. Do not weaken
assertions to obtain a pass or expand into unrelated refactoring.

Report the cause, changed files, failing-before evidence,
passing-after evidence and any tests you could not run.
Do not commit, push or deploy.

Das passt zu reproduzierbaren Fehlern. Bei einem sporadischen Produktionsvorfall mit lückenhafter Beweislage steht zuerst die Untersuchung an. Der Befehl sollte keinen fehlschlagenden Test erfinden müssen.

Eine Migration planen, bevor das gemeinsame System geändert wird

Ein Team, das ein Datenbankschema ändert oder eine API ersetzt, könnte damit vor der Umsetzung Fragen zur Reihenfolge und Kompatibilität aufdecken. Das Ergebnis soll ein Plan sein, der sich kritisch prüfen lässt — besonders für Phasen, in denen alte und neue Versionen gleichzeitig laufen.

Unter .claude/skills/team-migration-plan/SKILL.md speichern. Der Aufruf lautet /team-migration-plan "billing storage" "new invoice schema".

---
description: Plan a migration with compatibility checks and rollback gates
argument-hint: "[scope] [target-state]"
arguments: [scope, target]
disable-model-invocation: true
---

Plan a migration of $scope to $target.
If either input is missing or ambiguous, ask for clarification.
Read CLAUDE.md and inspect the current implementation and consumers.
Do not edit files, execute migrations or connect to production.

Describe the current state with file references. List affected data,
APIs, background jobs, integrations and deployment dependencies.
Separate verified facts from assumptions that need an owner.

Propose small phases with dependencies, acceptance checks and a
stop/go decision for each. Include compatibility between old and new
versions, backfill validation, retries and observability.
For each phase, describe rollback or recovery. Flag irreversible
steps and data that a code rollback cannot restore.

Return a reviewable plan, open questions and the smallest safe pilot.
Do not invent a duration, data volume or owner.

Die Anweisung, einen Plan zu erstellen, ändert den Berechtigungsmodus von Claude Code nicht. Soll auch die Sitzung im Plan Mode laufen, wird vor dem Skill /plan aufgerufen. Die schriftliche Arbeitsanweisung und die Tool-Berechtigungen der Sitzung sind getrennte Steuerungsmöglichkeiten. Plan Mode

Release Notes für das eigene Produkt

Wer Releases betreut, könnte damit aus einem klar abgegrenzten Änderungsumfang einen Entwurf für Kunden erstellen. Die Vorlage erleichtert es, Commits in konkrete Auswirkungen für Nutzer zu übersetzen, und verlangt für jede Aussage einen Beleg.

Unter .claude/skills/team-release-notes/SKILL.md speichern. Der Aufruf lautet /team-release-notes previous-release HEAD; dabei wird previous-release durch einen vorhandenen Tag oder Commit ersetzt.

---
description: Draft product release notes from a verified Git range
argument-hint: "[base-ref] [head-ref]"
arguments: [base, head]
disable-model-invocation: true
---

Draft release notes for $base..$head.
If either ref is missing, ask. Confirm both resolve locally.
Read CLAUDE.md and the project's existing release-note format.
Inspect commits in the range and compare the endpoint trees.
Use the changed code and tests to verify what each change does.

Group the draft into Added, Changed, Fixed and Breaking Changes.
Omit empty sections. Describe user impact without exposing internal
secrets or vulnerability details that need coordinated disclosure.
Attach a commit or file reference to each item for the reviewer.
Do not claim a change is deployed, enabled for every customer or
faster by a measured amount without evidence of that fact.

Finish with upgrade actions, unresolved questions and any changes
excluded because their impact could not be established.
Return a draft in chat. Do not edit the changelog, tag a release,
publish, send messages or deploy.

Ein Codebereich belegt, was sich im Repository geändert hat. Er belegt nicht, welche Kunden die Änderung bereits erhalten haben. Vor der Veröffentlichung des Entwurfs muss deshalb der Rollout-Status feststehen.

Ein wöchentliches Changelog fürs Team

Eine technische Teamleitung könnte diese Vorlage für das wöchentliche Update an Produktteam und Support verwenden. Sie trennt zusammengeführte Änderungen von bestätigten Releases. So kündigt das Update nicht versehentlich etwas an, das noch hinter einem Feature-Flag liegt.

Unter .claude/skills/team-weekly-changelog/SKILL.md speichern. Der Aufruf lautet /team-weekly-changelog START_DATE END_DATE main. Die Datumsangaben werden durch ISO-Zeitstempel einschließlich Zeitzone ersetzt. Der Zeitraum schließt den Startzeitpunkt ein und den Endzeitpunkt aus.

---
description: Draft a weekly engineering changelog from branch history
argument-hint: "[since] [until] [branch]"
arguments: [since, until, branch]
disable-model-invocation: true
---

Prepare a weekly changelog for $branch from $since inclusive to
$until exclusive. If an input is missing, ask. Confirm the timezone
and that the branch exists locally. State whether its checkout may
be stale; do not fetch or assume it matches the remote.

Read CLAUDE.md and the team's update format. Inspect commits reachable
from the branch, filtering by committer timestamp in this window.
Explain that commit timestamps do not prove merge or release dates.
Read diffs for claimed outcomes. Group related changes into themes
and avoid counting a merge and its constituent commits as separate
outcomes. Separate product changes, fixes and maintenance.

For each item, give its impact and a commit or file reference.
Label release status unknown unless deployment evidence is available.
Do not infer blockers, revenue, adoption or completion percentages
from commit messages. List evidence gaps at the end.
Return a concise draft in chat. Do not write files or send the update.

Release Notes und Wochenberichte sollten getrennt bleiben. Ein Release hat eine klar definierte Codegrenze und richtet sich an Kunden. Ein Wochenbericht umfasst einen Berichtszeitraum und kann auch nützliche Arbeit enthalten, die noch nicht ausgeliefert wurde.

Wann lohnt es sich, einen Befehl dauerhaft zu pflegen?

Entscheidend ist die wiederkehrende Arbeit rund um das Modell, nicht der Eindruck, den seine erste Antwort macht.

Der wöchentliche Nutzen berechnet sich so: Anzahl der Aufrufe × (bisherige Vorbereitungs- und Korrekturzeit − neue Vorbereitungs- und Korrekturzeit) × Stundensatz des Teams − zusätzliche Modellkosten − Pflegeaufwand, bewertet mit demselben Stundensatz. Dafür zählen die eigenen Messwerte. Ein längerer Prompt, dessen Ergebnis mehr Nacharbeit beim Review erfordert, kann Geld kosten, auch wenn sich der Ablauf stärker automatisiert anfühlt.

Am ehesten verändert sich der Zeitaufwand erfahrener Entwickler: Wie oft müssen sie denselben Prozess erklären und unvollständige Übergaben nachbessern? Wenn sich Architektur oder Release-Prozess ändern, muss auch der hinterlegte Ablauf gepflegt werden.

Auch die Ausführung eines gespeicherten Befehls zählt zur Modellnutzung. /usage zeigt Schätzungen der Tokenkosten und Angaben zur Tarifnutzung an. Eine angezeigte API-Kostenschätzung ist keine Aborechnung. Anthropics Kostendokumentation

Zwei Geschäftsideen rund um diese Befehle

Als interne Werkzeuge sind die Vorlagen nützlich. Für ein Produkt braucht es jedoch einen Vorteil, der über das Speichern eines Prompts hinausgeht.

Die stärkste Option: Reviews mit Prüfregeln für das konkrete Repository

Ein kleines Softwareteam könnte für ein gepflegtes Review-Paket bezahlen, das die eigenen kritischen Grenzen kennt: Welche Tabellen gehören zu einem Konto? Welche Aktionen wirken sich auf die Abrechnung aus? Welche Tests müssen eine Änderung begleiten?

Die Keyword-Übersicht von DataForSEO für Google in den USA auf Englisch lieferte am 13. Oktober 2026 schätzungsweise 1,300 monatliche Suchanfragen nach „ai code review“. Das deutet auf Interesse an der Aufgabe hin, nicht auf Nachfrage nach einem bestimmten Claude-Code-Plugin. DataForSEO Keyword Overview

Eine erste verkaufbare Version könnte eine Projektcheckliste, ergänzende Architekturnotizen und einen Prüfsatz aus früheren Fehlern kombinieren. Bevor das Paket als Plugin verteilt wird, sollte es anhand dieser Beispiele belegbare Befunde liefern.

Die Schwierigkeit ist die starke Konkurrenz: Claude Code bringt bereits Review-Funktionen mit, und CodeRabbit verkauft Code-Review-Tools. Ein allgemeiner Review-Prompt bietet wenig Unterscheidungskraft. Ich würde diese Idee nur verfolgen, wenn die Fehlerhistorie eines konkreten Teams zugänglich ist und jemand die Verantwortung dafür übernimmt, die Prüfregeln aktuell und korrekt zu halten.

Die kleinere Option: Release-Kommunikation mit Belegen

Ein Produktteam könnte einen gepflegten Workflow nutzen, der Repository-Änderungen in Release Notes für Kunden und eine interne Support-Information überführt — mit Quellenverweisen und einer ausdrücklichen Prüfung des Rollout-Status.

Dieselbe Keyword-Übersicht lieferte schätzungsweise 70 monatliche Suchanfragen nach „release notes generator“. Das ist ein überschaubares Nachfragesignal. Ich würde deshalb mit einer Dienstleistung oder einem internen Workflow beginnen, bevor daraus eine eigenständige Software wird. DataForSEO Keyword Overview

Eine erste Version könnte aus einem gewählten Git-Bereich Entwürfe im etablierten Format des Teams erzeugen. Schwierig ist die Verknüpfung der Änderungen mit Flags, Deployments und der tatsächlichen Verfügbarkeit für Kunden. Der Befehl kann Belege ordnen. Was das Team nicht dokumentiert, kann er nicht belegen.

Welche Grenzen sind bei geschäftskritischem Code wichtig?

Ein Befehl vereinheitlicht Anweisungen. Ob das Ergebnis akzeptabel ist, entscheiden weiterhin Tests, Reviews und Freigabeprozesse. Die fünf Vorlagen sind Ausgangspunkte. Änderungen daran sollten ebenso geprüft werden wie Änderungen am Anwendungscode.

Der vollständige Inhalt eines Skills wird bei seiner Verwendung geladen. Deshalb bleibt der eigentliche Ablauf am besten knapp; ausführliche Referenzen gehören in ergänzende Dateien. Persönliche Skills können Vorrang vor gleichnamigen Projekt-Skills haben. In lokalen Terminalsitzungen können Skills auch integrierte Befehle überlagern. Eindeutige Namen helfen. Wenn Teammitglieder unterschiedliches Verhalten sehen, sollte die Quelle des Skills geprüft werden. Laden von Skills und Vorrangregeln

Die tatsächlichen Berechtigungsregeln für Tools werden separat konfiguriert. Ein Satz wie „nur prüfen“ teilt Claude die Absicht mit; er setzt keine Beschränkung auf Betriebssystemebene durch. Berechtigungen in Claude Code

Der erste Schritt für Montag

Zuerst kommt /team-pr-check ins Repository. An die Stelle der allgemeinen Prüfpunkte treten die Kontrollen, die bei der letzten problematischen Änderung hätten greifen müssen. Dann wird der Befehl auf eine abgeschlossene Änderung mit bekanntem Ausgang angewendet. Die Befunde werden mit dem tatsächlichen Problem verglichen und der Ablauf überarbeitet, bevor er im Team zur Routine wird. Die Befehle für Releases und Wochenberichte folgen, sobald ihre Ausgabeformate abgestimmt sind.

Damit diese Workflows mit den eigenen Geschäftssystemen zusammenspielen, entwickle ich KI-Automatisierungen, die sich an den tatsächlich benötigten Prüfungen des Teams orientieren.