Claude Code Masterkurs – KI-gestuetztes Programmieren lernen mit Anthropics Coding-Agent

Custom Slash Commands

Level 3 | 30 Minuten

Erstelle wiederverwendbare Befehle für deine Workflows

Lernziele

Was sind Custom Slash Commands?

Custom Slash Commands sind wiederverwendbare Prompt-Templates, die als Markdown-Dateien gespeichert werden. Statt jedes Mal den gleichen detaillierten Prompt zu tippen, rufst du ihn mit einem einzigen Befehl auf — wie ein Makro für deine häufigsten Workflows. Stell dir vor, du machst jeden Tag Code-Reviews und jedes Mal tippst du: 'Prüfe den Code auf Bugs, Security-Probleme, Performance-Issues, Code-Style-Verstöße und fehlende Tests. Strukturiere das Review nach Schweregrad.' Das sind 30 Sekunden Tippen die du dir sparen kannst. Als Slash Command tippst du nur /project:review und der gesamte Prompt wird automatisch ausgeführt. Der Unterschied zu Skills: Slash Commands sind MANUELLE Auslöser — du entscheidest wann sie laufen. Skills werden von Claude AUTOMATISCH erkannt und geladen. Slash Commands sind wie Buttons die du drückst, Skills sind wie Wissen das Claude selbst abruft. Die Erstellung ist denkbar einfach: Du legst eine Markdown-Datei in einem bestimmten Verzeichnis ab, und schon ist der Command verfügbar. Der Inhalt der Datei ist der Prompt den Claude ausführen soll. Du kannst Variablen, Frontmatter und komplexe Anweisungen nutzen. Es gibt zwei Scopes für Commands: Projekt-Commands in .claude/commands/ werden ins Repository committed und stehen dem gesamten Team zur Verfügung. Persönliche Commands in ~/.claude/commands/ sind nur für dich sichtbar. Die meisten Teams nutzen Projekt-Commands für standardisierte Workflows und persönliche Commands für individuelle Shortcuts. Slash Commands sind die Einstiegsdroge in die Claude Code Automatisierung. Sie sind einfacher als Skills, mächtiger als einzelne Prompts, und der perfekte Weg um wiederkehrende Aufgaben zu standardisieren. Die meisten erfahrenen Nutzer haben 5-10 Commands die sie täglich nutzen.

Command-Struktur

Die Struktur von Custom Slash Commands folgt einem einfachen Prinzip: Eine Markdown-Datei pro Command, gespeichert in einem speziellen Verzeichnis. Der Dateiname bestimmt den Command-Namen, der Inhalt bestimmt was Claude tun soll. Einfacher geht es nicht. Es gibt zwei Orte für Commands: Das Projektverzeichnis .claude/commands/ für Team-weite Commands die ins Git-Repository committed werden, und das persönliche Verzeichnis ~/.claude/commands/ für deine privaten Commands. Beide Orte werden von Claude Code automatisch erkannt. Der Dateiname wird zum Command-Namen. Eine Datei namens review.md wird zum Command /project:review (für Projekt-Commands) oder /user:review (für persönliche Commands). Du rufst den Command einfach in der Claude Code Session auf. Die Verzeichnisstruktur unterstützt auch Unterordner für Organisation: .claude/commands/testing/unit.md wird zu /project:testing/unit. Das hilft bei vielen Commands die logisch gruppiert werden sollen: testing/, deployment/, docs/, review/ — jeder Ordner ist eine Kategorie. Der Inhalt der Markdown-Datei ist freier Text mit optionalem YAML-Frontmatter am Anfang. Der Text ist der Prompt den Claude bekommt wenn du den Command aufrufst. Du schreibst also einfach auf, was Claude tun soll — als ob du es direkt in die Konversation tippen würdest. Wichtig: Commands werden beim Aufruf als USER-Nachricht in die Konversation eingefügt. Das bedeutet, Claude behandelt den Command-Inhalt genauso wie eine manuelle Eingabe von dir. Du kannst alle Claude Code Features im Command-Text nutzen: Dateireferenzen, @-Mentions, Anweisungen für Tools. Ein praktischer Tipp: Beginne jede Command-Datei mit einem kurzen Kommentar der erklärt wofür der Command gedacht ist. Das hilft dir in 3 Monaten noch zu verstehen was jeder Command tut, und es hilft Teammitgliedern die deine Commands zum ersten Mal sehen.

COMMAND LOCATIONS
━━━━━━━━━━━━━━━━

📁 Projekt-Commands (Team-weit):
.claude/commands/
├── review.md          → /project:review
├── test.md            → /project:test
├── deploy.md          → /project:deploy
└── frontend/
    └── component.md   → /project:frontend:component

📁 Persönliche Commands (nur du):
~/.claude/commands/
├── daily.md           → /user:daily
├── standup.md         → /user:standup
└── journal.md         → /user:journal

NAMESPACING:
/project:command    → Aus .claude/commands/
/user:command       → Aus ~/.claude/commands/
Unterordner werden zu Namespaces:
/project:frontend:component

Dein erster Command

Lass uns gemeinsam deinen ersten Slash Command erstellen — Schritt für Schritt, von der Idee bis zum fertigen, funktionierenden Command. Wir bauen einen Code-Review Command der deine Team-Standards kennt und sie konsistent anwendet. Schritt 1: Erstelle das Verzeichnis falls es noch nicht existiert. In deinem Projektordner: mkdir -p .claude/commands. Das ist der Ort wo alle Projekt-weiten Commands gespeichert werden. Schritt 2: Erstelle die Command-Datei. Lege eine Datei namens review.md in .claude/commands/ an. Der Dateiname ohne .md-Endung wird zum Command-Namen — in diesem Fall /project:review. Schritt 3: Schreibe den Command-Inhalt. Das ist der Prompt den Claude bekommt wenn du den Command aufrufst. Für ein Code-Review könnte das so aussehen: 'Führe ein gründliches Code Review der aktuellen Änderungen durch. Prüfe auf: 1) Korrektheit und Logikfehler, 2) Security-Schwachstellen, 3) Performance-Probleme, 4) Einhaltung unserer Coding Standards, 5) Fehlende Fehlerbehandlung, 6) Fehlende oder unzureichende Tests. Strukturiere dein Review nach Schweregrad (Critical → High → Medium → Low). Für jeden Fund: Beschreibe das Problem, zeige den betroffenen Code, und schlage eine konkrete Verbesserung vor.' Schritt 4: Teste den Command. Starte Claude Code in deinem Projekt und tippe /project:review. Claude führt den Review nach deinen Spezifikationen durch. Prüfe ob die Ergebnisse deinen Erwartungen entsprechen. Schritt 5: Verfeinere iterativ. Wenn der Review zu oberflächlich ist, füge spezifischere Anweisungen hinzu. Wenn er zu lang ist, begrenze die Ausgabe. Wenn er bestimmte Patterns übersieht, ergänze explizite Prüfpunkte. Schritt 6: Committe den Command ins Repository. Damit steht er automatisch allen Teammitgliedern zur Verfügung. Jeder kann /project:review tippen und bekommt ein konsistentes Review nach den gleichen Standards. Gratulation — du hast deinen ersten Slash Command erstellt! Von hier aus kannst du weitere Commands für deine häufigsten Workflows bauen.

# .claude/commands/review.md

Review die letzten Code-Änderungen:

1. Führe git diff aus um die Änderungen zu sehen
2. Fokussiere auf modifizierte Dateien

Review-Checkliste:
- Code ist lesbar und gut benannt
- Keine duplizierte Logik
- Fehlerbehandlung vorhanden
- Keine exponierten Secrets oder Credentials
- Performance-Aspekte berücksichtigt

Gib Feedback nach Priorität:
Kritisch → Warnungen → Vorschläge

Jetzt kannst du einfach /project:review tippen und Claude führt das komplette Code-Review durch!

Commands mit Argumenten

Slash Commands werden richtig mächtig wenn sie Argumente akzeptieren. Statt einen starren Prompt auszuführen, kannst du dynamische Werte übergeben — ähnlich wie bei Shell-Skripten. Das macht Commands flexibel und wiederverwendbar für verschiedene Situationen. Claude Code unterstützt drei Arten von Variablen in Command-Templates: $1 für das erste Argument, $2 für das zweite, und $ARGUMENTS für alle Argumente als zusammenhängenden Text. Du platzierst diese Variablen im Markdown-Text, und beim Aufruf werden sie durch die tatsächlichen Werte ersetzt. Ein Beispiel: Der Command /project:explain soll eine beliebige Datei erklären. Die explain.md enthält: 'Erkläre die Datei $1 im Detail. Gehe auf die Architektur, die wichtigsten Funktionen und mögliche Verbesserungen ein. Nutze einfache Sprache die auch Junior-Entwickler verstehen.' Beim Aufruf /project:explain src/auth/login.ts wird $1 durch den Dateipfad ersetzt. Für komplexere Szenarien nutze $ARGUMENTS: Der Command /project:feature nimmt eine beliebig lange Feature-Beschreibung entgegen. Die feature.md enthält: 'Implementiere folgendes Feature: $ARGUMENTS. Erstelle einen Plan, implementiere den Code, schreibe Tests und aktualisiere die Dokumentation.' Beim Aufruf /project:feature User soll E-Mail-Benachrichtigungen erhalten wenn sein Passwort geändert wird wird der gesamte Text nach dem Command-Namen als Feature-Beschreibung eingefügt. Mehrere Argumente kannst du kombinieren: /project:test $1 $2 könnte Framework und Datei annehmen: /project:test jest src/utils.ts — der Command weiß dann welches Test-Framework und welche Datei gemeint ist. Ein Praxis-Tipp: Dokumentiere die erwarteten Argumente im Frontmatter oder als Kommentar am Anfang der Command-Datei. Das hilft dir und deinen Teamkollegen die richtige Syntax zu kennen. Zum Beispiel: '# Usage: /project:explain <file-path>'. Ohne Argumente: Commands für standardisierte Tasks mit immer gleichen Parametern. Mit Argumenten: Commands für flexible Tasks wo sich der Input ändert.

# .claude/commands/fix-issue.md
# Nutzung: /project:fix-issue 123 high

Fix Issue #$1 mit Priorität $2.

Schritte:
1. Lies die Issue-Beschreibung
2. Analysiere den betroffenen Code
3. Implementiere den Fix
4. Schreibe Tests für den Fix
5. Erstelle einen Commit mit "fix: resolve #$1"

# $1 = Erstes Argument (Issue-Nummer)
# $2 = Zweites Argument (Priorität)
# $ARGUMENTS = Alle Argumente als String

Frontmatter-Konfiguration

Das YAML-Frontmatter am Anfang einer Command-Datei gibt dir erweiterte Kontrolle über das Verhalten des Commands. Ohne Frontmatter funktioniert ein Command trotzdem — aber mit Frontmatter kannst du das Modell, die Tools, die Beschreibung und weitere Aspekte steuern. Das Frontmatter steht zwischen zwei Dreifach-Strichen (---) am Anfang der Datei, vor dem eigentlichen Prompt-Text. Es verwendet YAML-Syntax und unterstützt verschiedene Optionen die das Verhalten des Commands beeinflussen. Die wichtigste Option ist die Beschreibung (description). Sie erscheint wenn du /help tippst oder wenn Claude die verfügbaren Commands auflistet. Eine gute Beschreibung erklärt in einem Satz was der Command tut und wann man ihn nutzen sollte. Zum Beispiel: 'Führt ein umfassendes Code Review nach Team-Standards durch.' Mit der model Option kannst du ein spezifisches Modell für diesen Command erzwingen. Ein einfacher Dokumentations-Command kann Haiku nutzen (günstig und schnell), während ein komplexer Architektur-Review Opus braucht. So optimierst du Kosten pro Command. Die allowed_tools Option beschränkt welche Tools Claude beim Ausführen des Commands nutzen darf. Ein reiner Analyse-Command braucht vielleicht nur Read und Grep. Ein Implementierungs-Command braucht Write, Edit und Bash. Weniger erlaubte Tools bedeuten mehr Sicherheit und fokussierteren Output. Fortgeschrittene Optionen: agent_mode lässt den Command als Subagent in isoliertem Kontext laufen — perfekt für ressourcenintensive Commands die den Hauptkontext nicht belasten sollen. max_tokens begrenzt die Ausgabelänge. files definiert Dateien die automatisch geladen werden sollen. Mein Empfehlung: Starte ohne Frontmatter. Füge die Beschreibung hinzu sobald du mehr als 5 Commands hast (damit du den Überblick behältst). Füge model und allowed_tools hinzu wenn du Kosten optimierst oder Sicherheit erhöhst. Die anderen Optionen brauchst du erst bei fortgeschrittenen Szenarien.

# .claude/commands/deploy.md

---
allowed-tools: Bash(git:*), Bash(npm:*), Edit
description: Deploy-Workflow mit Tests und Checks
argument-hint: [environment] [version]
model: claude-sonnet-4-5-20250929
---

# Deploy zu $1

## Pre-Deploy Checks
1. Alle Tests ausführen: npm test
2. TypeScript prüfen: npx tsc --noEmit
3. Lint-Check: npm run lint

## Build & Deploy
4. Build erstellen: npm run build
5. Deploy zu $1: npm run deploy:$1

## Post-Deploy
6. Health-Check der Anwendung
7. Smoke-Tests ausführen
8. Team im Slack benachrichtigen
FRONTMATTER OPTIONEN
━━━━━━━━━━━━━━━━━━━

allowed-tools     → Welche Tools der Command nutzen darf
description       → Beschreibung (erscheint in /help)
argument-hint     → Hinweis für Argumente
model             → Spezifisches Modell für diesen Command

Praxis-Commands für den Alltag

Hier sind die Commands die sich in der täglichen Entwicklungsarbeit am meisten bewährt haben. Jeder einzelne spart dir regelmäßig 5-15 Minuten und sorgt für konsistente, qualitativ hochwertige Ergebnisse. Kopiere sie als Ausgangspunkt und passe sie an dein Projekt an. Der Review-Command (/project:review) ist der Klassiker: Er führt ein strukturiertes Code Review durch, prüft auf Bugs, Security, Performance und Style-Verstöße, und liefert einen Report nach Schweregrad sortiert. Das Template sollte deine spezifischen Coding-Standards, Architektur-Patterns und bekannten Schwachstellen enthalten. Der Test-Command (/project:test) generiert Tests für eine angegebene Datei oder Funktion. Er kennt dein Test-Framework, deine Konventionen und die zu prüfenden Edge Cases. Der Prompt enthält Beispiele guter Tests aus eurem Projekt damit Claude den Stil übernimmt. Der Explain-Command (/project:explain $1) erklärt eine Datei oder Funktion verständlich. Besonders nützlich für Onboarding neuer Teammitglieder oder wenn du selbst in einen unbekannten Teil der Codebase eintauchst. Der Refactor-Command (/project:refactor $1) analysiert eine Datei auf Verbesserungspotential und schlägt ein strukturiertes Refactoring vor. Er berücksichtigt eure Architektur-Entscheidungen und vermeidet bekannte Anti-Patterns. Der Commit-Command (/project:commit) analysiert die aktuellen Änderungen und erstellt atomare Commits mit aussagekräftigen Messages nach euren Konventionen (Conventional Commits, Ticket-Referenzen, etc.). Der Docs-Command (/project:docs $1) generiert oder aktualisiert die Dokumentation für eine Datei, Funktion oder ein Modul — im Stil und Format eurer bestehenden Dokumentation. Ein Profi-Tipp: Erstelle einen /project:daily Command der deinen täglichen Workflow zusammenfasst: Git-Status, offene TODOs im Code, fehlgeschlagene Tests und die nächsten Schritte. Starte jeden Morgen damit — in 10 Sekunden hast du den perfekten Überblick.

# .claude/commands/test.md
---
allowed-tools: Bash(npm:*), Read, Grep, Glob
description: Erstelle Tests für eine Datei
argument-hint: [file-path]
---

Erstelle umfassende Tests für: $ARGUMENTS

Test-Anforderungen:
- Nutze das bestehende Test-Framework des Projekts
- Platziere Tests im __tests__/ Verzeichnis
- Mocke externe Abhängigkeiten
- Teste alle Hauptfunktionalitäten
- Inkludiere Edge Cases und Fehler-Szenarien
- Strebe hohe Code Coverage an
# .claude/commands/commit.md
---
allowed-tools: Bash(git:*)
description: Intelligenter Commit mit Conventional Commits
---

Erstelle einen Git-Commit:

1. Analysiere die aktuellen Änderungen mit git diff
2. Erstelle eine Commit-Message im Conventional Commits Format:
   - feat: Neues Feature
   - fix: Bug Fix
   - docs: Dokumentation
   - refactor: Code-Umstrukturierung
   - test: Tests
   - chore: Wartung
3. Committe mit der generierten Message
4. Zeige den erstellten Commit
# .claude/commands/security-audit.md
---
allowed-tools: Read, Grep, Glob, Bash(npm:audit)
description: Sicherheits-Audit der Codebasis
---

Du bist ein Security-Experte. Scanne diese Codebasis:

Prüfe auf:
- SQL Injection Schwachstellen
- XSS Attack Vectors
- Authentication Bypass Möglichkeiten
- Exponierte API Keys oder Secrets
- OWASP Top 10 Verletzungen

Für jeden Fund, liefere:
1. Beschreibung der Schwachstelle
2. Risiko-Level (Kritisch/Hoch/Mittel/Niedrig)
3. Betroffene Datei und Zeile
4. Empfohlener Fix mit Code-Beispiel

Team-Commands teilen

Der größte Vorteil von Projekt-Commands gegenüber persönlichen Commands: Sie werden ins Git-Repository committed und stehen damit automatisch dem gesamten Team zur Verfügung. Kein manuelles Setup, keine Installations-Anleitung, keine Versionskonflikte — jeder hat sofort die gleichen Commands. Der Prozess ist denkbar einfach: Du erstellst Commands im .claude/commands/ Verzeichnis, committst sie, pushst sie zum Remote-Repository. Jedes Teammitglied das den Branch pullt, hat sofort Zugriff auf alle Commands. Neue Teammitglieder bekommen die Commands beim ersten Clone automatisch. Für Teams ist Konsistenz der Hauptvorteil: Wenn alle das gleiche /project:review nutzen, folgen alle Reviews den gleichen Standards. Wenn alle das gleiche /project:commit nutzen, haben alle Commits das gleiche Format. Das eliminiert Stilunterschiede und reduziert Review-Aufwand. Eine bewährte Team-Strategie: Definiere Core-Commands die jeder nutzen soll (review, test, commit, docs) und optionale Commands für spezialisierte Workflows (deploy, migration, performance-audit). Dokumentiere alle Commands in einer README im .claude/commands/ Verzeichnis. Verschiedene Teammitglieder können persönliche Commands in ~/.claude/commands/ für ihre individuellen Workflows erstellen. Diese überschreiben bei Namenskollisionen die Projekt-Commands — so kann jeder Entwickler Commands an seine Präferenzen anpassen ohne die Team-Version zu ändern. Für die Qualitätssicherung empfehle ich: Behandle Command-Änderungen wie Code-Änderungen — sie sollten durch Code Review gehen bevor sie gemergt werden. Ein fehlerhafter Command der von 10 Entwicklern genutzt wird, kann erheblichen Schaden anrichten. Ein Praxis-Tipp für große Teams: Erstelle einen /project:help Command der alle verfügbaren Commands mit Beschreibung und Verwendungsbeispielen auflistet. Das ist die beste Onboarding-Hilfe für neue Teammitglieder.

# Commands ins Repository committen
git add .claude/commands/
git commit -m "feat: add team Claude Code commands"
git push

# Team-Mitglieder bekommen Commands automatisch!
# Nach git pull sind alle Commands verfügbar.

# Projektstruktur:
# .claude/
# ├── commands/        → Team-Commands (committed)
# ├── settings.json    → Team-Settings (committed)
# └── settings.local.json → Persönliche Settings (gitignored)
💡 Pro-Tipps • Nutze /help um alle verfügbaren Commands zu sehen • Commands mit häufigen Workflows starten (Review, Test, Deploy) • Persönliche Commands für individuelle Workflows (~/.claude/commands/) • Unterordner für Namespacing: frontend/, backend/, devops/ • Commands können andere Commands referenzieren • Kombiniere Commands mit Hooks für vollautomatische Workflows

Zusammenfassung