Claude Code Slash Commands: Befehle, die Sie wirklich nutzen

Sie haben dieselbe vierteilige Anweisung so oft in Claude Code getippt, dass Sie sie auswendig können. Schreibe die Release Notes so. Prüfe dieses Diff gegen unsere Konventionen. Ein Slash Command macht aus dieser Wiederholung ein einziges Wort, und Claude Code baut sie aus einfachen Markdown-Dateien. Der Teil, den die meisten Anleitungen auslassen: Der Befehl ist nur der Auslöser. Ob der Output etwas taugt, entscheidet der Kontext, gegen den er läuft.

Die wichtigsten Erkenntnisse

• Ein eigener Slash Command ist eine Markdown-Datei. Legen Sie deploy.md in ein Commands-Verzeichnis, und /deploy existiert. Kein Registrierungsschritt, keine Konfigurationsdatei.
• Persönliche Befehle liegen unter ~/.claude/, Projektbefehle im .claude/ des Repos. Diese Wahl entscheidet, ob Teamkollegen den Befehl beim Klonen mitbekommen.
• Eigene Befehle und Skills sind zusammengewachsen. .claude/commands/deploy.md und .claude/skills/deploy/SKILL.md erzeugen beide /deploy.
• Der Unterschied, der weiterhin zählt, ist, wer abdrückt. Einen Slash Command tippen Sie bewusst. Ein Skill lädt, wenn Claude die Aufgabe erkennt. Ein Subagent arbeitet in seinem eigenen Kontextfenster.
• Argumente kommen über $ARGUMENTS, über Positionsplatzhalter oder über benannte Argumente aus dem Frontmatter herein.
• Ein Befehl, der die Konventionen Ihres Teams nicht kennt, liefert generischen Output, so gut er auch geschrieben ist.

---

Was ein Slash Command wirklich ist

Zwei verschiedene Dinge teilen sich den Namen. Eingebaute Befehle kommen mit dem Claude-Code-Client und steuern die Sitzung selbst: /clear startet eine frische Unterhaltung, /compact fasst zusammen, um Kontext freizuräumen, /context zeigt, was Ihr Kontextfenster auffrisst, /init schreibt eine erste CLAUDE.md, /permissions bearbeitet Allow- und Deny-Regeln, /mcp verwaltet MCP-Server, /plugin installiert und schaltet Plugins. Anthropic liefert außerdem Skills mit, die sich wie Befehle verhalten: /code-review, /security-review, /debug, /doctor.

Eigene Befehle sind die, die Sie schreiben: Prompts, unter einem Namen gespeichert. Statt "prüfe dieses Diff nur auf Korrektheitsfehler, ignoriere Stil, markiere alles, was das Billing-Modul berührt" in das Feld zu kopieren, tippen Sie /review-diff.

Zwei mechanische Details zählen früh. Ein Befehl wird nur ganz am Anfang einer Nachricht erkannt, und alles nach dem Namen wird zu seinen Argumenten. Sie können bis zu sechs Skills in einer Nachricht verketten, /lint /test fix whatever breaks ist also gültig.

---

Wo eigene Befehle liegen

Der Ort ist die gesamte Konfiguration. Wo die Datei liegt, entscheidet, wer sie ausführen kann und welche Kopie bei einer Namenskollision gewinnt.

Der Befehlsname kommt bei einer commands/-Datei aus dem Dateinamen und bei einem Skill aus dem Verzeichnisnamen, sodass .claude/commands/deploy-staging.md und .claude/skills/deploy-staging/SKILL.md beide /deploy-staging ergeben. Existieren beide, gewinnt der Skill. Über die Ebenen hinweg überschreibt persönlich das Projekt: Wenn Ihr Team einen deploy-Befehl ausliefert und Sie einen eigenen haben, läuft Ihrer, still und leise, für immer.

Persönlich versus Projekt ist eine echte Entscheidung. Stellen Sie eine Frage: Kodiert dieser Befehl etwas über das Repo oder etwas über mich? Ein Befehl, der Ihr Test-Harness des Projekts ausführt, Ihrem PR-Template folgt oder weiß, dass das Payments-Modul zusätzliche Sorgfalt braucht, gehört in .claude/commands/ und gehört in Git. Committen Sie ihn, dann wird er reviewt wie jeder andere Code, und das ist der einzige Weg, auf dem ein geteilter Befehl ehrlich bleibt, während die Konventionen sich verschieben. Ein Befehl, der abbildet, wie Sie persönlich arbeiten, gehört in ~/.claude/. Behandeln Sie die repo-spezifischen so, wie Sie CLAUDE.md behandeln: eingecheckt, reviewt, aktuell gehalten.

---

Einen schreiben: ein echter, kopierbarer Befehl

Ein Projektbefehl, der Release Notes aus den Commits seit dem letzten Tag entwirft. Speichern Sie ihn als .claude/skills/release-notes/SKILL.md oder als .claude/commands/release-notes.md für die flache Form. Beide ergeben /release-notes; der Skills-Pfad ist der, für den das vollständige Frontmatter dokumentiert ist.

---
description: Draft release notes from commits since the last tag
argument-hint: [version]
arguments: version
allowed-tools: Bash(git log *) Bash(git tag *) Bash(git diff *)
disable-model-invocation: true
---

## Context

- Last tag: !`git describe --tags --abbrev=0`
- Commits: !`git log $(git describe --tags --abbrev=0)..HEAD --oneline`
- Files changed: !`git diff --name-only $(git describe --tags --abbrev=0)..HEAD`

## Your task

Draft release notes for version $version.

Rules:
- Group under Added, Fixed, Changed. Drop any heading with nothing under it.
- One line per change, written for a user of the product, not a developer.
- Never invent a change that is not in the commit list above.
- Put anything needing a migration step under its own "Action required" heading.
- Output raw Markdown only, no preamble.

Führen Sie ihn mit /release-notes 1.4.0 aus, und drei Dinge passieren, bevor Claude irgendetwas sieht. Die ` !command -Platzhalter werden ausgeführt und ihre Ausgabe wird als reiner Text eingefügt, sodass Claude die echte Commit-Liste bekommt statt einer Anweisung, sie zu holen. $version wird zu 1.4.0. Die allowed-tools`-Einträge geben diese Git-Aufrufe für diesen Zug vorab frei, sodass Sie sich nicht durch Berechtigungsabfragen klicken.

Vier Frontmatter-Felder tragen den größten Teil des Gewichts:

• description: was der Befehl tut. Claude nutzt sie, um zu entscheiden, ob ein Skill relevant ist, und Sie sehen sie im /-Menü.
• argument-hint: der Platzhalter, der bei der Autovervollständigung erscheint, etwa [version].
• allowed-tools: Tools, die für den Zug vorab freigegeben sind, in dem der Befehl aufgerufen wird. Die Freigabe endet mit Ihrer nächsten Nachricht, sie ist also eng, nicht dauerhaft.
• disable-model-invocation: true: Nur Sie können das auslösen. Nutzen Sie es für alles mit Nebenwirkung. Sie wollen nicht, dass Claude entscheidet, der Code sehe deploy-reif aus.

Nutzen Sie einen mit ``` `! `` geöffneten Codeblock für mehrzeiliges Shell-Setup. Und achten Sie auf Befehle, die berechtigterweise mit einem Fehlercode enden: Ein fehlgeschlagener eingefügter Befehl bricht den gesamten Aufruf ab, hängen Sie also || true` an ein Prüfskript, das bei Funden mit 1 endet.

Wie Argumente funktionieren

Drei Wege, Eingaben hineinzubekommen, und der positionsbasierte hat eine Falle.

• $ARGUMENTS expandiert zu allem, was nach dem Befehlsnamen getippt wurde. Erwähnt Ihre Datei es nie, werden die Argumente als ARGUMENTS: <value> angehängt statt verworfen.
• Positionsplatzhalter sind $ARGUMENTS[0], $ARGUMENTS[1], mit $0 und $1 als Kurzform. Die Indizes sind nullbasiert, $0 ist also das erste Argument und $1 das zweite. Wenn Sie Tools gewohnt sind, bei denen $1 das erste Argument meint, wird Sie das genau einmal beißen. Die Quotierung ist shell-typisch: /my-command "hello world" second lässt $0 zu hello world expandieren.
• Benannte Argumente umgehen die Falle. Deklarieren Sie arguments: version im Frontmatter und nutzen Sie $version im Rumpf. Namen werden der Reihe nach auf Positionen abgebildet, was einen Befehl mit mehreren Argumenten später lesbar hält.

---

Slash Command vs Skill vs Subagent

Das ist die Unterscheidung, nach der am häufigsten gefragt wird, und die ehrliche Antwort ist, dass sich die Linie zwischen den ersten beiden verschoben hat. Eigene Befehle wurden in Skills überführt: derselbe /name-Aufruf, dasselbe Verhalten, wobei Skills ein Verzeichnis für Begleitdateien und Frontmatter zur Steuerung, wer aufrufen darf, ergänzen. Was weiterhin unterschiedlich ist, sind der Auslöser und der Kontext.

Praktisch übersetzt. Wenn es Sie stören würde, dass Claude es ungefragt ausführt, ist es ein Befehl: Setzen Sie disable-model-invocation: true. Wenn es Sie stören würde, selbst daran denken zu müssen, ist es ein Skill, und das description-Feld ist das, was ihn im richtigen Moment feuern lässt. Wenn die Aufgabe zehntausend Tokens Dateiinhalt in Ihre Sitzung kippen würde, ist es ein Subagent. Ein Skill lässt sich mit context: fork ebenfalls auf einen Subagent richten. Die Autorenseite deckt unser Leitfaden zu Claude Code Skills ab.

---

Welche Befehle sich wirklich lohnen

Die meisten enden mit einem commands/-Verzeichnis voller Dinge, die sie einmal geschrieben und nie wieder ausgeführt haben. Ein Befehl verdient sich seinen Platz, wenn drei Dinge stimmen: Sie erledigen die Aufgabe mindestens wöchentlich, die Anweisung ist lang genug, dass Tippen nervt, und die Aufgabe hat eine richtige Antwort, die Sie beschreiben können. Alles Vage scheitert am dritten Test.

Die Überlebenden häufen sich an denselben Stellen. Commit- und PR-Texte, weil das Format feststeht und die Eingabe ein Diff ist. Release Notes, aus demselben Grund. Test-Gerüste, wo eine gute Testdatei Hausstil ist. Diff-Reviews gegen Konventionen, die das Modell nicht aus dem Code ableiten kann.

Kuratierte Sammlungen durchzusehen ist der schnellste Weg zu sehen, wie ein ausgereifter Befehl aussieht, und öffentliche Repositories mit Claude-Code-Befehlen sind auf GitHub leicht zu finden. Auf unserer Seite veröffentlichen wir ein Verzeichnis mit 114 Claude Skills, installierbar als Claude Code Plugin Marketplace mit /plugin marketplace add mkhalid1/locul-skills, in dem fünf gemessene Vorher-Nachher-Ergebnisse tragen, sechs weitere getestet und gestrichen wurden und neunzehn zurückgezogen wurden. Die Streichungen sind der nützliche Teil: Sie sagen, welche Prompts gut klangen und den Output nicht verändert haben. Derselbe Test gilt für Ihre eigene Prompt-Bibliothek: Behalten Sie, was die Antwort verändert, und löschen Sie, was nur die Formulierung verändert.

---

Der Teil, den niemand erwähnt: Ein Befehl ist nur so gut wie sein Kontext

Hier ist der Fehlermodus, den Sie etwa in Woche drei treffen. Sie schreiben /review-pr, es ist wirklich ein guter Prompt, und die Reviews sind trotzdem generisch. Technisch korrekt, praktisch nutzlos. Der Review markiert einen fehlenden Null-Check und sagt nichts über die Entscheidung vor sechs Monaten, in diesem Service nie bei 4xx zu wiederholen, oder darüber, dass die Preiskonstante, die er gerade durchgewinkt hat, sich im letzten Quartal geändert hat.

Der Befehl ist eine Prompt-Vorlage. Er trägt die Anweisung, nicht das Wissen. Alles, was ein Review scharf macht, lebt außerhalb der Befehlsdatei: Entscheidungen und ihre Begründung, Konventionen, die niemand aufgeschrieben hat, was sich im letzten Monat geändert hat. Einen Teil davon können Sie in CLAUDE.md schieben, und das sollten Sie auch, aber diese Datei veraltet in dem Moment, in dem sich eine Entscheidung ändert, weil ihre Pflege Handarbeit ist, für die niemand Zeit hat. Jede Prompt-Bibliothek und jedes Commands-Verzeichnis hat dasselbe Problem: statischer Text, der ein bewegliches Ziel beschreibt. Das ist die Wartungsfrage hinter Ihr KI-Setup aktuell halten, und deshalb holen zwei Entwickler, die denselben Befehl ausführen, unterschiedliche Qualität heraus.

Ein Befehl ohne Kontext ist nur ein schnellerer Weg, nach einer generischen Antwort zu fragen.

Genau für diese Lücke wurde Locul gebaut: eine local-first Desktop-App für macOS und Windows, die aus dem, was Sie ohnehin produzieren, ein zweites Gehirn baut, aus Ihren Notizen, PDFs und Diktaten, es aktuell hält, während sich Fakten ändern, und es Claude Code über MCP bereitstellt. Ändert sich ein Fakt, wird die alte Memory als überholt markiert und die neue übernimmt, sodass Befehle gegen das laufen, was jetzt wahr ist. Verwandt: Claude Code Memory.

---

FAQ

Kann Claude Code Slash Commands ausführen?

Ja. Claude Code bringt eingebaute Befehle mit, etwa /help, /clear, /compact, /context, /init, /mcp und /plugin, dazu mitgelieferte Skills wie /code-review und /security-review. Eigene fügen Sie hinzu, indem Sie eine Markdown-Datei in ~/.claude/commands/ für den persönlichen Gebrauch oder in .claude/commands/ innerhalb eines Projekts legen. Der Dateiname wird zum Befehlsnamen, aus notes.md wird also /notes. Befehle werden nur am Anfang einer Nachricht erkannt, und alles nach dem Namen wird als Argument übergeben.

Was ist der Unterschied zwischen Slash Commands und Skills?

Eigene Slash Commands wurden in Skills überführt, .claude/commands/deploy.md und .claude/skills/deploy/SKILL.md erzeugen also beide /deploy und verhalten sich gleich. Bestehende commands/-Dateien funktionieren weiter. Unterschiedlich ist weiterhin, wer aufruft. Einen Slash Command tippen Sie absichtlich. Ein Skill kann zusätzlich von Claude geladen werden, wenn seine description zu Ihrem Tun passt, und er kann Begleitdateien in einem eigenen Verzeichnis tragen. Setzen Sie disable-model-invocation: true für einen Skill, den nur Sie auslösen können, und user-invocable: false für Hintergrundwissen, das für einen Menschen nichts Sinnvolles zum Ausführen ist.

Welche Slash Commands sind in Claude Code am nützlichsten?

Von den eingebauten verändern diese den Verlauf einer Sitzung am stärksten: /context (sehen, was Ihr Kontextfenster füllt, bevor Sie sich wundern, warum die Antworten schlechter wurden), /compact (Kontext zurückgewinnen), /clear (sauber starten statt gegen einen verschmutzten Strang zu kämpfen), /init und /memory (Projektanweisungen) sowie /permissions (nicht vierzigmal denselben Befehl freigeben). Von denen, die Sie selbst schreiben, sind Commit- und PR-Texte, Release Notes, Test-Gerüste und ein konventionsbewusstes Diff-Review am wertvollsten.

Gibt es einen Slash Command für Code Review?

Ja. Claude Code liefert /code-review mit, das das aktuelle Diff prüft oder eine PR-Nummer, einen Branch oder einen Pfad, den Sie ihm geben, mit Flags wie --fix, um Funde anzuwenden, und --comment, um sie inline an einem Pull Request zu posten. Es gibt außerdem /security-review. Schreiben Sie einen eigenen, wenn das Review Regeln braucht, die der mitgelieferte nicht kennen kann, etwa "niemals eine Änderung am Billing-Modul ohne Test freigeben". Wenn Sie lieber von etwas Fertigem ausgehen: Unser Hub mit Code-Review-Skills sammelt die, die wir für diese Aufgabe veröffentlicht haben. So oder so ist der Prüfer nur so gut wie das, was er über Ihre Codebasis weiß, weshalb ein konventionsbewusstes Review-Kommando ein generisches schlägt.

---

Fangen Sie mit einem Befehl an, dann reparieren Sie den Kontext

Nehmen Sie die Anweisung, die Sie diesen Monat am häufigsten neu getippt haben, speichern Sie sie als Datei, führen Sie sie morgen aus. Sobald Sie drei oder vier Befehle haben, die Sie wirklich nutzen, ist nicht mehr der Prompt der Engpass, sondern das, was das Modell über Ihre Arbeit weiß.

Wenn Sie dort gelandet sind: Locul ist kostenlos zum Starten, mit 500 aktiven Memories und lokaler KI, ohne Kreditkarte, für macOS und Windows. Es baut das Gehirn aus den Dateien, PDFs und Diktaten, die Sie ohnehin produzieren, und stellt es Claude Code über MCP bereit, sodass die Befehle, die Sie gerade geschrieben haben, gegen aktuellen Kontext laufen statt gegen eine Momentaufnahme des letzten Quartals.