Definiere wiederverwendbare Slash Commands als Markdown-Dateien, teile sie per git im Team und decke häufige Aufgaben wie Code-Reviews, Testgenerierung und PR-Beschreibungen ab.
Claude Code bringt einige eingebaute Slash Commands mit — /help, /clear, /compact. Aber die, die deinen Workflow wirklich beschleunigen, sind die, die du selbst schreibst.
Dieser Artikel zeigt, wie man ein wiederverwendbares Slash-Command-System entwirft — damit das gesamte Team dieselbe Prompt-Bibliothek nutzen kann, anstatt Aufgabenbeschreibungen jedes Mal neu zu formulieren.
In Claude Code ist ein benutzerdefinierter Slash Command einfach eine Markdown-Datei. Lege sie im richtigen Verzeichnis ab, Claude Code erkennt sie beim Start automatisch, und die Eingabe von /dateiname löst sie aus.
Der Dateiinhalt ist der Prompt, der an Claude gesendet wird. Mehr nicht.
Keine spezielle Syntax, kein Konfigurationsformat — eine .md-Datei ist ein Command.
Zwei Orte, zwei Zwecke:
| Ort | Pfad | Geltungsbereich |
|---|---|---|
| Projekt | .claude/commands/ |
Nur aktuelles Projekt, kann in git committet werden |
| Benutzer | ~/.claude/commands/ |
Alle Projekte, persönlich |
Die Projektebene ist das Herzstück des Team-Sharings. Committe .claude/commands/ in git, und jeder, der das Repository klont, hat das vollständige Command-Set automatisch.
Die Benutzerebene eignet sich für persönliche Gewohnheiten — bevorzugte Code-Style-Prüfungen oder Tool-Integrationen, die nur du verwendest.
Im Projektstammverzeichnis:
mkdir -p .claude/commands
Erstelle .claude/commands/review.md:
Überprüfe die Codequalität der aktuellen Änderungen. Schwerpunkte:
1. Logikfehler und Randfälle
2. Ob die Benennung klar ist
3. Duplizierten Code, der es wert wäre, extrahiert zu werden
4. Sicherheitsprobleme (SQL-Injection, XSS, exponierte Secrets)
Gib konkrete, umsetzbare Vorschläge — keine generischen Ratschläge.
Claude Code neu starten und /review eingeben, um es auszulösen.
Commands mit festem Inhalt sind in ihrem Nutzen begrenzt. $ARGUMENTS macht sie flexibel — was der Benutzer nach /command eingibt, wird in den Prompt eingesetzt.
Beispiel .claude/commands/test.md:
Schreibe Tests für Folgendes: $ARGUMENTS
Anforderungen:
- Decke den Happy Path und Randfälle ab
- Testnamen sollen selbsterklärend sein
- Verwende echte Daten statt Mocks, wo möglich
Verwendung:
/test die login-Methode der UserAuthentication-Klasse
Claude erhält:
Schreibe Tests für Folgendes: die login-Methode der UserAuthentication-Klasse
Anforderungen:
...
$ARGUMENTS kann überall im Prompt erscheinen und mehrfach verwendet werden.
Ein Command, eine Verantwortung
Schreibe keinen "Alles-in-einem"-Command. /review ist für Code-Reviews, /test für Tests schreiben, /pr für PR-Beschreibungen. Fokussierte Commands sind leichter zu merken und wiederzuverwenden.
Konkrete Prompts schreiben, keine abstrakten
Schlecht:
Hilf mir, diesen Code zu optimieren
Gut:
```
Optimiere diesen Code für Performance. Prioritäten:
1. Unnötige Datenbankabfragen reduzieren (N+1-Probleme)
2. Wiederholte Berechnungen in Schleifen vermeiden
3. Lineare Suchen durch effizientere Datenstrukturen ersetzen
Die Schnittstelle bleibt unverändert — nur die Implementierung ändern.
```
Konkrete Einschränkungen führen zu gezielten Ergebnissen.
Frontmatter zu Commands hinzufügen
Das description-Feld erscheint in der Command-Liste von Claude Code, damit Teammitglieder schnell verstehen, wofür jeder Command gedacht ist:
---
description: Überprüft aktuelle Änderungen für Code-Qualitätsfeedback
---
Überprüfe die Codequalität der aktuellen Änderungen...
Für ein Rails-Projekt decken diese Commands die häufigsten täglichen Entwicklungsaufgaben ab:
.claude/commands/review.md — Code-Review
Überprüfe die Änderungen in git diff. Achte auf:
- Logikfehler und Behandlung von Randfällen
- Sicherheitsprobleme: SQL-Injection, Autorisierungsprüfungen
- Lesbarkeit der Benennung
- Duplizierte Logik, die extrahiert werden könnte
Gib für jedes Problem den genauen Ort und einen konkreten Vorschlag an.
```
.claude/commands/test.md — Tests generieren
Schreibe Tests für diesen Code: $ARGUMENTS
Verwende RSpec. Abdeckung: Happy Path, Randfälle, Fehlerbedingungen.
Benennungsformat: describe ... context ... it ...
Standardmäßig echte Objekte verwenden; externe Abhängigkeiten nur bei Bedarf mocken.
```
.claude/commands/pr.md — PR-Beschreibung
Erstelle basierend auf git diff und Commit-Log eine PR-Beschreibung.
Format:
(2-3 Sätze, die zusammenfassen, was gemacht wurde)
(Hintergrund und Motivation)
(Wie diese Änderung zu verifizieren ist)
Halte es knapp, geschrieben für einen Code-Reviewer.
```
.claude/commands/explain.md — Code erklären
Erkläre, was $ARGUMENTS macht:
- Was ist die Gesamtverantwortung?
- Wie funktioniert die Kernlogik?
- Welche Randfälle sind erwähnenswert?
Schreibe für einen Entwickler, der neu in diesem Teil des Codes ist. Fokussiere auf das Warum, nicht nur das Was.
```
Manche Gewohnheiten sind persönlich und sollten dem gesamten Team nicht aufgezwungen werden. Diese kommen in ~/.claude/commands/:
~/.claude/commands/standup.md — Tägliche Standup-Vorbereitung
```markdown
Erstelle basierend auf dem heutigen git log und offenen TODOs eine Standup-Zusammenfassung:
- Was ich gestern abgeschlossen habe
- Was ich heute plane
- Etwaige Blocker
Maximal 5 Sätze.
```
~/.claude/commands/refactor.md — Refactoring-Vorschläge
```markdown
Analysiere $ARGUMENTS und schlage Refactoring-Verbesserungen vor.
Nenne nur wirklich lohnenswerte Änderungen — nicht um des Refactorings willen refactoren.
Erkläre für jeden Vorschlag: welches Problem er löst, wie viel Arbeit er bedeutet und welches Risiko besteht.
```
Der wahre Wert benutzerdefinierter Commands liegt nicht in der persönlichen Produktivität — sondern darin, dem Team eine gemeinsame Sprache zu geben.
Committe .claude/commands/ ins Repository und dokumentiere die verfügbaren Commands in deiner README oder CLAUDE.md. Neue Teammitglieder haben die vom Team aufgebaute Prompt-Bibliothek in dem Moment, in dem sie das Repo klonen, ohne selbst danach suchen zu müssen.
Wenn das Projekt sich weiterentwickelt, tun es die Commands auch. Wenn ein Prompt nicht gut funktioniert, eine Zeile korrigieren und pushen — das gesamte Team erhält das Update. Das ist der kostengünstigste Weg, Prompt Engineering auf Team-Ebene zu verankern.
.claude/
├── commands/
│ ├── review.md # Code-Review
│ ├── test.md # Tests generieren
│ ├── pr.md # PR-Beschreibung
│ └── explain.md # Code erklären
└── settings.json