Eigene Slash-Befehle in Claude Code erstellen — Workflow anpassen

Was sind eigene Slash-Befehle?

Claude Code bringt integrierte Slash-Befehle wie /help und /clear mit, aber wusstest du, dass du einfach deine eigenen Befehle hinzufügen kannst? Eigene Slash-Befehle lassen dich häufig verwendete Prompts oder Routineaufgaben mit einem kurzen Schlüsselwort aufrufen, und sie zu beherrschen kann deine tägliche Entwicklung dramatisch beschleunigen.

Statt jedes Mal einen langen Prompt wie „Überprüfe den Code im aktuellen Branch” einzutippen, kannst du einfach /review eingeben, um das gleiche Verhalten auszulösen. Wenn du Befehle im Team teilst, kannst du Review-Kriterien oder Release-Prozeduren standardisieren.

Dateispeicherort und -format

Eigene Slash-Befehle sind einfache Markdown-Dateien. Es gibt zwei Speicherorte:

• Projektspezifisch: .claude/commands/<befehlsname>.md
• Benutzerweit: ~/.claude/commands/<befehlsname>.md

Projektspezifische Befehle können in dein Repository eingecheckt und mit Teamkollegen geteilt werden, während benutzerweite Befehle in all deinen Projekten verfügbar sind. Der Dateiname wird zum Befehlsnamen, daher wird review.md zu /review.

Deinen ersten Befehl erstellen

Starten wir mit dem einfachsten möglichen Befehl. Führe dies vom Projektstamm aus:

mkdir -p .claude/commands
cat > .claude/commands/review.md <<'EOF'
Lies alle Änderungen, die sich aktuell im Git-Staging-Bereich befinden,
und überprüfe sie unter folgenden Gesichtspunkten:

- Mögliche Bugs
- Einheitlichkeit der Benennung
- Fehlende Testabdeckung
- Sicherheitsbedenken

Wenn du Probleme findest, melde sie mit Dateinamen und Zeilennummern.
EOF

Das war’s. Wenn du /review in Claude Code eingibst, wird der Dateiinhalt als Prompt gesendet.

Argumente entgegennehmen

Um Befehle nützlicher zu machen, lass sie Argumente annehmen. Verwende den $ARGUMENTS-Platzhalter innerhalb deines Markdown, und der übergebene String wird dort eingefügt.

# .claude/commands/explain.md

Bitte erkläre die folgende Datei oder das folgende Symbol sorgfältig,
sodass Anfänger folgen können.

Ziel: $ARGUMENTS

Deine Erklärung sollte enthalten:
1. Eine Ein- bis Zwei-Satz-Zusammenfassung, was der Code tut
2. Eine schrittweise Durchsicht der wichtigen Zeilen
3. Ein realistisches Anwendungsbeispiel
4. Häufige Stolperfallen, die zu vermeiden sind

Rufe ihn mit /explain src/utils/parser.ts auf. Das $ARGUMENTS-Token wird vor der Ausführung durch src/utils/parser.ts ersetzt.

Befehle, die mehrere Dateien referenzieren

Neben dem Übergeben von Dateipfaden als Argumente kannst du die @-Syntax innerhalb eines Befehls verwenden, um bestimmte Dateien explizit zu laden.

# .claude/commands/check-types.md

Nachdem du @tsconfig.json und @package.json gelesen hast, finde alle
Typfehler im gesamten Projekt.

Schritte:
1. Führe `npx tsc --noEmit` aus
2. Gruppiere Fehler nach Datei
3. Schlage eine Reihenfolge zur Fehlerbehebung vor
4. Sortiere zuerst nach der Größe des betroffenen Bereichs

Bitte gib das Ergebnis als Tabelle aus.

Claude liest automatisch tsconfig.json und package.json, bevor mit dem Befehl begonnen wird.

In der Praxis: Ein Release-Vorbereitungsbefehl

Hier ist ein Beispiel, das einen typischen Release-Workflow in einem einzigen Befehl zusammenfasst.

# .claude/commands/release.md

Bereite das Release für Version $ARGUMENTS vor.

Schritte:
1. Aktualisiere das Feld `version` in package.json auf $ARGUMENTS
2. Füge einen neuen Abschnitt am Anfang der CHANGELOG.md hinzu
   - Referenziere das git log seit dem vorherigen Tag
   - Kategorisiere in feat / fix / docs / chore
3. Führe `npm run test` aus und bestätige, dass alle Tests bestehen
4. Führe `npm run build` aus und bestätige, dass keine Build-Fehler auftreten
5. Fasse die Änderungen zusammen und schlage eine Commit-Nachricht vor

Wichtig: Führe nicht selbst `git push` oder `npm publish` aus.
Überlasse die endgültige Bestätigung dem Benutzer.

Die Eingabe von /release 1.4.0 übernimmt alles von Versionserhöhungen bis zum Ausführen von Tests. Vermeide aus Sicherheitsgründen destruktive Operationen und lass einen Menschen den letzten Schritt bestätigen.

Flags und Optionen simulieren

Du kannst Verzweigungslogik in Markdown beschreiben, um Flags zu simulieren.

# .claude/commands/test.md

Argumente: $ARGUMENTS

Befolge diese Regeln:

- Wenn die Argumente leer sind: Führe alle Tests aus
- Wenn Argumente `--unit` enthalten: Führe nur Unit-Tests aus
- Wenn Argumente `--e2e` enthalten: Führe nur E2E-Tests aus
- Wenn ein Dateipfad enthalten ist: Führe nur Tests aus, die mit dieser Datei zusammenhängen

Analysiere nach der Ausführung die Ursache fehlgeschlagener Tests.

Aufrufe wie /test --unit oder /test src/auth.ts werden möglich.

Best Practices für Team-Sharing

Lege projektspezifische Befehle unter .claude/commands/ ab und verwalte sie mit Git, damit jedes Teammitglied dieselben Befehle verwendet. Beachte dabei Folgendes:

• Verwende eine einheitliche Namenskonvention: Verb zuerst, kurze Namen (review, fix, explain)
• Dokumentiere sie in der README: Mache Befehle leicht auffindbar
• Vermeide destruktive Operationen: Verbiete explizit Dinge wie git push --force oder rm -rf
• Gib das Ausgabeformat an: Halte Review-Ergebnisse konsistent mit Tabellen oder Checklisten

Fazit

Eigene Slash-Befehle sind der kürzeste Weg, Claude Code in „deinen persönlichen KI-Assistenten” zu verwandeln. Beginne mit ein oder zwei einfachen Befehlen und füge weitere hinzu, wann immer du eine wiederkehrende Aufgabe entdeckst. Schon bald werden sie ein unverzichtbarer Teil deines Workflows sein.

Für die Claude-Code-Grundlagen siehe den Einstiegsleitfaden. Für fortgeschrittene Automatisierung siehe Erste Schritte mit dem Agent SDK, und für Tipps zum Kontext schau dir Kontextverwaltung an.

Für die offizielle Dokumentation siehe die Anthropic-Dokumentation.