Eigene Slash-Commands für Claude Code, in 30 Minuten produktiv

Wenn Du Claude Code länger als zwei Wochen nutzt, wirst Du dieselben Prompts mehrfach am Tag eintippen. "Review diesen File", "Schreib mir nen Test für", "Deploy auf staging". Genau dafuer gibt es Custom Slash Commands. Eine Markdown-Datei pro Befehl, kein Plugin-System, kein Build-Step. Ich zeig Dir wie das geht und wo die Stolperfallen sind.

1. Verstehen worum es eigentlich geht

Ein Slash-Command in Claude Code ist nichts anderes als eine Markdown-Datei mit YAML-Frontmatter und einem Prompt. Wenn Du /review eingibst, sucht Claude Code im Projekt unter .claude/commands/review.md und in Deinem Home-Dir unter ~/.claude/commands/review.md. Findet er die Datei, liest er sie, ersetzt Platzhalter wie $ARGUMENTS durch das was Du nach dem Command getippt hast, und feuert das als Prompt ab.

Das heisst: ein Command ist genau so gut wie der Prompt den Du reinschreibst. Keine Magie. Aber genau das macht es so brauchbar, weil Du Deine besten Prompts versionierst statt sie immer wieder neu zu erfinden.

2. Den ersten Command anlegen

Geh in Dein Projekt und mach das Verzeichnis:

mkdir -p .claude/commands

Jetzt eine Datei review.md rein. Inhalt minimal:

---
description: Code-Review für den aktuellen File
---

Schau dir den letzten geaenderten File im Working Directory an.
Pruef auf:
- Logik-Fehler oder Edge-Cases die fehlen
- Schlechte Variablen-Namen
- Tests die fehlen sollten

Gib mir maximal 5 konkrete Punkte zurueck. Keine Lobhudelei.

Speichern. Claude Code neu starten oder einfach /help tippen, dann sollte /review (project) in der Liste auftauchen. Das (project) heisst es kommt aus Deinem Repo, nicht aus Deinem User-Verzeichnis. Tippst Du jetzt /review, geht der Prompt los.

3. Argumente reinschleifen

Statisch ist langweilig. Du willst sagen "review FILE X". Dafuer gibt es zwei Platzhalter: $ARGUMENTS schluckt alles was Du hinter dem Command tippst als ein String. $1, $2, $3 schlucken einzelne Tokens.

Beispiel fix-issue.md:

---
description: Fix GitHub Issue per Nummer
argument-hint: [issue-number]
---

Fix Issue #$ARGUMENTS nach unseren Coding-Standards.
Schreib Tests dafuer, dann commit auf einem feature-Branch.

Aufruf: /fix-issue 247 und $ARGUMENTS wird 247.

Das argument-hint Feld ist nicht kosmetisch, das zeigt Claude Code Dir an wenn Du nur /fix-issue eingibst und Tab drueckst. Lohnt sich immer.

4. Files reinziehen mit @-Syntax

Wenn Dein Command einen File analysieren soll, kannst Du den File-Inhalt direkt in den Prompt einbetten. Syntax: @pfad/zur/datei. Wenn Du das mit $1 kombinierst, wird das richtig nützlich.

security-check.md:

---
description: Security-Audit für einen File
argument-hint: [file-path]
allowed-tools: Read
---

Lies @$1 und pruef auf:
- Hard-coded Secrets oder API-Keys
- SQL-Injection-Patterns
- Unsanitized User-Input

Wenn du was findest, gib genaue Zeilen-Nummern aus.

Aufruf: /security-check src/auth.ts. Claude liest die Datei und feuert den Prompt mit dem File-Inhalt als Context.

5. Bash-Befehle inline laufen lassen

Das ist der unterschaetzte Trick. Mit !`command` kannst Du in Deinem Command einen Shell-Befehl ausführen und den Output in den Prompt einbetten. Heisst: dynamischer Context ohne dass Claude erst tools rufen muss.

commit-message.md:

---
description: Commit-Message basierend auf staged changes
allowed-tools: Bash(git:*)
---

Hier sind die staged changes:

!`git diff --cached`

Hier ist der current branch:

!`git branch --show-current`

Schreib mir eine Commit-Message im Conventional-Commits-Format.
Eine Zeile Subject, max 72 Zeichen, dann Leerzeile, dann Body.

Wichtig: Das allowed-tools: Bash(git:*) Feld erlaubt explizit nur git-Befehle. Ohne dieses Whitelisting fragt Claude bei jedem Bash-Call nach. Wenn Du Bash(*) schreibst geht alles, aber das ist gefaehrlich, also lieber granular bleiben.

6. Persoenliche vs Projekt-Commands

Project-Commands liegen in .claude/commands/ im Repo. Die committest Du mit. Vorteil: Dein Team nutzt dieselben Befehle. Nachteil: Dein /dailylog Command der eigentlich nur für Dich interessant ist, schwappt in jedes Projekt.

Loesung: Personal-Commands. Die liegen in ~/.claude/commands/ und sind in jedem Projekt verfuegbar. In /help werden sie als (user) markiert.

Mein Setup: Workflow-Commands wie /review, /test, /deploy als Project-Commands (Team-Sharing). Persoenliche wie /note, /commit-msg, /explain-this als User-Commands.

7. Namespacing wenn es mehr werden

Ab 15 Commands wird die flache Liste unuebersichtlich. Loesung: Subverzeichnisse. Du legst in .claude/commands/git/review.md einen Command an, der wird in /help als /review (project:git) angezeigt. Bei /git/review greifst Du explizit drauf zu.

.claude/commands/
├── git/
│   ├── review.md
│   └── commit.md
├── ci/
│   └── deploy.md
└── docs/
    └── api.md

Frueh damit anfangen wenn Du planst mehr als 5-10 Commands zu haben. Spaeter umbenennen ist Aufwand und Du brichst Muscle-Memory.

8. Commands wirklich nützlich machen

Der Unterschied zwischen Spielerei und Daily-Driver ist ob der Command etwas macht was Du sonst manuell machen wuerdest. Drei Patterns die bei mir hart durchschlagen:

Status-Snapshot. /status packt git-status, npm test output, und die letzten 5 Commits in einen Prompt und fragt Claude was als naechstes ansteht. Spart mir morgens 10 Minuten Orientierung.

Code-zu-Doku. /document $1 liest einen File, generiert JSDoc-Kommentare und schreibt sie zurück. Boring, aber wenn Du den Command einmal hast, machst Du es nie wieder von Hand.

Pre-Commit-Sanity. /prepush läuft git diff origin/main...HEAD, fragt Claude ob das alles sinnvoll zusammen gehoert oder ob da accidentally drei Features im selben PR sind.

Die Logik ist immer: was nervt Dich täglich, dauert 30 Sekunden bis 3 Minuten, und ist gleichformig genug für einen Prompt. Genau das wird ein Command.

9. Die zwei Stolperfallen

Fallback-Chaos. Wenn Dein Command-Name kollidiert mit einem Built-in (z.B. /help), gewinnt der Built-in. Wenn ein Project-Command und ein User-Command denselben Namen haben, gewinnt der Project-Command. Heisst: bevor Du /test in ~/.claude/commands/ ablegst, check ob das Repo nicht schon ein /test definiert.

Prompt-Engineering vergessen. Dein Command ist ein Prompt. Wenn der Prompt schwammig ist, wird die Antwort schwammig. Schreib Akzeptanz-Kriterien rein ("max 5 Punkte", "keine Lobhudelei", "konkrete Zeilen-Nummern"). Sonst kriegst Du den uebliche Claude-Wall-of-Text.

10. Was als naechstes

Wenn Du die ersten drei bis fuenf Commands geschrieben hast, faellt Dir auf dass manche eigentlich Hooks waeren. Hooks laufen automatisch bei Events (PostToolUse, PreCompact), Slash-Commands feuerst Du manuell. Beides hat seinen Platz.

Wenn Du mehr ueber Hooks lernen willst, schau ins Playbook Hooks gegen Halluzinationen. Wenn Du Slash-Commands für Sub-Agents bauen willst, Erster Sub-Agent in 30 min ist der Folge-Schritt. Und wenn Du Dein Setup teilen willst, uberleg ein Plugin draus zu machen, das ist im Grunde nur ein Verzeichnis mit Commands plus ein bisschen Manifest-File.

Mein Tipp: leg heute einen einzigen Command an, /review.md, mit einem Prompt der schon zwei Mal in Deinem Chat-Verlauf war. Das ist kleiner Aufwand, sofortiger Payoff, und Du verstehst danach das ganze System.

Source

Specs verifiziert gegen /anthropics/claude-code Repo, Stand 2026-04-28:

• plugins/plugin-dev/skills/command-development/SKILL.md (Locations, Frontmatter, Argumente)
• plugins/plugin-dev/skills/command-development/README.md (File-Format, $ARGUMENTS, @-Syntax, !-Bash)
• plugins/plugin-dev/skills/command-development/references/plugin-features-reference.md (Namespacing)

Offizielle Doku: https://docs.claude.com/en/docs/claude-code/slash-commands