Claude-Code-Slash-Befehle: Längere, sauberere Sessions fahren

Slash-Befehle vs. CLI-Flags vs. Tastenkürzel

CLI-Flags konfigurieren, wie Claude Code startet, Tastenkürzel greifen bei Echtzeit-Unterbrechungen ein, und Slash-Befehle geben dir die Feinkontrolle innerhalb einer laufenden Session. 

Alle drei Ebenen gibt es, weil im Workflow zu unterschiedlichen Momenten unterschiedliche Bedürfnisse entstehen. Du wirst sie nicht in jeder Session alle brauchen – aber zu wissen, dass es sie gibt, sorgt dafür, dass du im passenden Moment zum richtigen Werkzeug greifst.

Slash-Befehle schreibst du direkt in eine aktive Session. Sie beginnen mit / (z. B. /compact, /plan oder /clear) und laufen sofort. Sie steuern, was jetzt gerade in diesem Gespräch passiert.

CLI-Flags setzt du beim Start von Claude Code im Terminal, etwa claude --model claude-opus-4-6 oder claude --continue. Sie konfigurieren die Session vor dem Start. Mehr zu allen Flags findest du in unserem Claude Code CLI-Tutorial.

Tastenkürzel wirken auf UI-Ebene. Esc unterbricht eine laufende Antwort. Doppeltippen auf Esc öffnet das Rewind-Menü. Shift+Tab wechselt zwischen Plan-Modus, Edits annehmen und Auto-Modus. Das sollten Muskelgedächtnis-Shortcuts für häufige Aktionen sein.

Dieser Artikel konzentriert sich auf Slash-Befehle – also Befehle zwischen Prompts –, mit Verweisen auf Tastenkürzel, wo sie sich mit bestimmten Befehlen überschneiden.

Welche Claude-Code-Befehle sind am wichtigsten?

Die folgende Tabelle deckt die 13 wichtigsten Befehle ab, die alle in diesem Guide erklärt werden.

Beachte: /cost ist in den neuesten Versionen von Claude Code ein Alias für /usage, und /fork ist ein Alias für /branch.

Alle Optionen siehst du, wenn du in deiner Claude-Session / tippst.

So managst du dein Claude-Code-Kontextfenster

Um das Kontextfenster in Claude Code zu steuern – eine Kernkompetenz für Power-User – nutzt du die Befehle /compact, /clear und /context.

Was ist das Kontextfenster in Claude Code?

Das Kontextfenster ist das Arbeitsgedächtnis deiner Session. Es enthält viel Information: 

• Deine Gesprächshistorie
• Dateiinhalte
• Kommandoausgaben
• Deine CLAUDE.md-Anweisungen
• MCP-Kontext
• Claudes Systemprompts

Wenn es sich füllt, verliert Claude Code frühe Teile der Session aus dem Blick – etwa die zu Beginn beschriebene Ordnerstruktur, Randbedingungen und anderes Schlüssewissen. Die Qualität sinkt bereits vor dem harten Limit – nicht erst, wenn es erreicht ist.

/compact

Der Befehl /compact fasst ältere Runden zusammen und ersetzt sie durch eine komprimierte Version. So sparst du Token und Claude bleibt über die bisherigen Schritte im Bilde. Am besten führst du ihn früh aus und sagst gezielt, was erhalten bleiben soll.

Die Grundform ist einfach /compact. Nützlicher ist es, zu sagen, was fokussiert werden soll: Zum Beispiel /compact focus on the auth module oder /compact retain the error handling patterns we discussed.

Wenn du Anweisungen mitgibst, betont die Zusammenfassung genau diese Themen. Für Datenprofis könnte das lauten: /compact focus on the schema decisions and the pipeline DAG, damit die Architektur im Fokus bleibt, während zeilenweise Debug-Details komprimiert werden.

Eine hilfreiche Community-Regel: Komprimiere, bevor die Kontextnutzung 80% übersteigt. Wartest du bis voll ist, leidet die Zusammenfassung, weil Claude dann schon im Degradationsmodus arbeitet. 

Wichtig: Der Inhalt von CLAUDE.md, geladene Skills und Memory-Dateien werden beim Komprimieren automatisch bewahrt. Du musst sie nicht extra anfordern.

/clear

Der Befehl /clear löscht die Gesprächshistorie komplett und startet neu. Nutze /clear an Aufgaben-Grenzen.

Optional kannst du vor dem Leeren einen Namen vergeben: /clear payment-refactor. Das labelt die alte Session im /resume-Picker, damit du später zurückkehren kannst.

Wenn du das Debugging eines Dataloaders beendet hast und nun an einem völlig unabhängigen Visualisierungsmodul arbeitest, ist alter Kontext eher Ballast. Ein sauberer Neustart verhindert Verwechslungen, alte Constraints werden nicht mitgeschleppt und Claude ist voll auf die neue Aufgabe fokussiert.

Nutze /compact, um in derselben Arbeit mit weniger Kontextballast fortzufahren, und /clear, um komplett auf ein anderes Thema zu wechseln.

/context

Bevor du entscheidest, ob du komprimierst oder leerst, hilft ein Blick auf den Status. Der Befehl /context visualisiert die aktuelle Auslastung des Kontextfensters als farbiges Raster und zeigt, wo die Tokens hingehen.

Du siehst eine Aufschlüsselung nach Kategorien: 

• Gesprächshistorie
• Dateiinhalte
• Memory-Dateien
• Geladene Skills

Praktisch: Claude schlägt Optimierungen vor, wenn etwas ungewöhnlich viel Platz verbraucht. Mit /context all bekommst du die komplette Detailansicht pro Item.

Gewöhne dir an, /context vor größeren Tasks zu starten. Ist das Fenster schon zu 60% voll, bevor du eine große Multi-File-Refactor angehst, sind Frust und Qualitätsabfall vorprogrammiert, wenn du nicht vorher komprimierst oder leerst.

So planst und prüfst du Änderungen in Claude Code

Der schnellste Weg ins Chaos beim „AI Vibe Coding“ ist, Dateien ohne klaren Plan editieren zu lassen. Um zu verhindern, dass mehrdeutige Anweisungen zu inkonsistenten Änderungen führen, nutze /plan und diff.

/plan

Mit /plan versetzt du Claude in einen Read-only-Modus: Es analysiert den Code, schlägt einen Plan vor und wartet auf dein Go, bevor es etwas ändert. 

Du kannst eine Beschreibung mitgeben, um vorzuspuren: /plan refactor the feature engineering pipeline to support lazy evaluation. Nichts wird geschrieben oder gelöscht, bis du freigibst. Nach deinem Review führt Claude den gesamten Plan aus.

Der Shortcut für den schnellen Wechsel in den Plan-Modus ist Shift+Tab – praktischer, wenn du mitten in der Session bist.

Besonders wertvoll ist der Plan-Modus in drei Situationen: 

• Wenn du mit einem Codebase nicht vertraut bist
• Wenn eine Änderung viele Dateien betrifft
• Wenn die Anweisungen naturgemäß mehrdeutig sind

Beispiele: Migration eines Feature Stores, Refactoring von ETL-Logik oder das Aktualisieren von Trainingsskripten, die über Jahre mit Ad-hoc-Änderungen gewachsen sind.

Für einen Deep Dive lies unser Tutorial: Claude Code Plan Mode: Design-Review-first Refactoring-Loops.

/diff

Mit /diff öffnest du einen interaktiven Diff-Viewer, der alle Dateiänderungen aus der aktuellen Session zeigt.

Ideal für den schnellen Check, ob nichts Unerwartetes passiert ist – etwa ungewollte Dateiänderungen oder schleichende Scope-Erweiterung. Denk daran als letzte Prüfstufe zwischen „Claude hat etwas gemacht“ und „Ich weiß genau, was in diesen Commit geht“.

Im Viewer navigierst du mit den Pfeiltasten. Links/Rechts wechselt zwischen kumulativem Git-Diff und pro Runde, Hoch/Runter blättert durch die Dateien. So siehst du, was insgesamt und in jeder Runde passiert ist.

So hältst du Claude Code auf Kurs

Damit komplexe Sessions nicht den Faden verlieren und der Kontext nicht mit Abschweifungen verschmutzt, nutze /goal und /btw.

/goal

Mit /goal setzt du ein übergeordnetes Ziel, das über mehrere Runden bestehen bleibt und Claude auf ein klares Ergebnis ausrichtet. 

Ist ein Goal gesetzt, arbeitet Claude automatisch weiter, bis die Bedingung erfüllt ist. Besonders nützlich bei langen Migrationen, großen Test-Fix-Runden oder Aufgaben, bei denen du Claude sonst immer wieder zum Weitermachen auffordern müsstest.

Du nutzt es, indem du das gewünschte Ergebnis angibst. Klare Endzustände helfen, z. B. /goal All tests in the data pipeline are passing with no deprecation warnings.

Ein Live-Overlay in der Statuszeile zeigt währenddessen Zeit, Rundenzahl und Tokenverbrauch. Wenn das Ziel erreicht ist, stoppt Claude und meldet Abschluss. 

Um ein Ziel vorzeitig zu entfernen: /goal clear.

Einen ähnlichen, aber anderen Ansatz findest du im Tutorial zu Spec-Driven Development in Claude Code.

/btw

Mit /btw stellst du eine Nebenfrage, die nie Teil des Haupt-Threads wird.

Claude beantwortet sie in einem Overlay, und die Hauptunterhaltung läuft nahtlos weiter: /btw what was that config option for SQLAlchemy connection pooling called again? 

Passiert mir oft: Claude arbeitet, und ich habe eine Frage zum Prozess. Wenn ich unterbreche, erzeuge ich Rauschen und Claude muss evtl. neu starten. Wenn ich es ignoriere, vergesse ich es. /btw löst das elegant.

Denk daran wie eine Haftnotiz an dich selbst mitten im Task – die Antwort ohne den Kontext- oder Zeitverlust eines Umwegs.

So navigierst du Sessions in Claude Code

Lange Projekte passen nicht in eine einzige Session. Du musst alte Arbeit wieder aufnehmen, sicher experimentieren, ohne Fortschritt zu zerstören, und manchmal Fehlpfade zurückdrehen. /resume, /branch und /rewind helfen dir dabei.

/resume

Mit /resume setzt du eine frühere Session fort. Ohne Argumente öffnet sich ein Picker mit jüngsten Sessions nach Datum sortiert und der letzten Prompt-Zusammenfassung. Mit Name oder ID springst du direkt hin: /resume payment-refactor

Das geht auch über die Kommandozeile vor dem Start. claude --continue (oder claude -c) setzt die letzte Session fort, und claude --resume <id> setzt per ID fort. CLI-Flags und Slash-Befehl tun dasselbe; die Flags nutzt du vor dem Start, den Slash-Befehl mitten in der Session.

Claude Code speichert jede Session lokal in ~/.claude/projects/ als JSONL – inklusive Messages, Tool-Nutzung und Ergebnissen. Das ermöglicht Resume, Rewind und Branching.

/branch

Mit /branch erstellst du eine Kopie der aktuellen Unterhaltung im jetzigen Zustand, wechselst in diesen Branch, und das Original bleibt unverändert. Du kannst Branches benennen: /branch try-polars-instead-of-pandas

Das ist das Gesprächs-Pendant zu einem Git-Branch. Du willst einen anderen Ansatz testen, ohne den bisherigen zu verlieren? Branchen, ausprobieren, und wenn es nicht klappt, mit /resume zurück. Wenn es klappt, hast du einen sauberen Branch für den besseren Weg.

Hilfreich ist das auch, wenn dein Kontextfenster vollläuft und du zwei getrennte Themen hast, die beide vom aktuell gesammelten Kontext profitieren.

/branch ist auch als /fork verfügbar. In älteren Ressourcen siehst du oft /fork. Der kanonische Name in der aktuellen Doku ist /branch – beide funktionieren.

/rewind

Wenn wir zu weit gehen und merken, dass Fehler passiert sind … /rewind spult die Session zu einer früheren Runde zurück – wie eine Undo-Taste. 

Praktisch: Du bekommst ein interaktives Menü. Mit den Pfeiltasten wählst du die Runde, zu der du zurück willst. 

Der Clou ist die Auswahl, was zurückgedreht wird:

• Beides (Standard): Dateien werden auf den Zustand dieser Runde gesetzt und alle späteren Nachrichten gelöscht. Nutze das, wenn eine ganze Änderungskette schief ging und du sauber von einem bekannten guten Stand neu starten willst.
• Nur Unterhaltung entfernt Nachrichten nach dem gewählten Punkt, behält aber Dateianschlüsse. Nutze das, wenn Claudes spätere Antworten nicht halfen, der geschriebene Code aber okay war.
• Nur Code stellt Dateien auf den gewählten Stand zurück, behält aber die Unterhaltung. Nutze das, wenn du Claudes Analyse behalten, aber die Dateiedits rückgängig machen willst.

Das Tastenkürzel Esc Esc öffnet dasselbe Rewind-Menü ohne Tipperei.

Wichtige Einschränkung: Nur Dateioperationen, die Claude über seine offiziellen Tools ausgeführt hat, sind nachverfolgbar und reversibel. Manuelle Änderungen in einem separaten Editor während der Session sind nicht abgedeckt.

So steuerst du Kosten und Performance in Claude Code

Um das Verhältnis aus Kosten und Leistung in Claude Code zu steuern, nutze /cost, /model und /effort.

Auf API-Plänen zählen Tokenkosten. Auf Pro- oder Max-Plänen zählt die Quota. In beiden Fällen ist es Verschwendung, jedes Mal das stärkste Modell mit maximaler Reasoning-Tiefe zu fahren.

/cost

/cost ist ein Alias für /usage und zeigt, was bisher angefallen ist:

• Für API-Nutzer siehst du Tokenzählung, Cache-Nutzung und Dollar-Kosten nach Modell aufgeschlüsselt. 
• Für Pro- und Max-Abos siehst du deine Nutzung gegenüber der Periodenquote.

Checke /cost zu Beginn einer großen Session als Baseline und dann periodisch bei langen Läufen, um zu sehen, wie schnell du Budget verbrauchst. 

Wenn die Kosten schneller steigen als erwartet, sind die nächsten zwei Befehle deine Stellhebel.

/model

Das aktive Modell mit /model mitten in der Session zu wechseln, ohne Kontext zu verlieren, ist mächtig – je nachdem, was du gerade brauchst.

Ohne Argumente öffnet sich ein interaktiver Picker für die Pfeiltasten. Du kannst auch direkt den Namen angeben: /model claude-haiku-4-5.

Eine praxisnahe Strategie: 

1. Starte mit Claude Opus für komplexe Architektur-Überlegungen
2. Wechsle dann zu Claude Sonnet für die Implementierung
3. Und runter auf Claude Haiku für Fleißarbeiten wie Variablen umbenennen, Docstrings generieren oder Boilerplate füllen. 

Die Kostendifferenz zwischen Opus und Haiku liegt skaliert bei etwa dem 10- bis 20-Fachen.

Seit v2.1.153 wird das mit /model gewählte Modell als Standard für neue Sessions gespeichert. Drücke s im Picker, um die Auswahl nur für die aktuelle Session zu übernehmen, ohne deinen Standard zu ändern.

/effort

Mit /effort bestimmst du, wie viel Aufwand dein Modell betreibt – also die Reasoning-Tiefe für das aktuelle Modell. Ohne Argumente bekommst du einen interaktiven Slider, du kannst aber auch direkt setzen, z. B. /effort low.

Verfügbare Stufen: 

• low

• medium

• high

• xhigh (April 2026)

• max (Mai 2026)

• ultracode (Mai 2026)

Die Stufen max und ultracode gelten nur für die aktuelle Session und lassen sich nicht als Standard speichern. Mit /effort auto setzt du auf den Modell-Default zurück.

Die Stufe ultracode kombiniert xhigh-Reasoning mit automatischer Workflow-Orchestrierung für komplexe Multi-Step-Aufgaben. Vorsicht: Das kann viele Tokens verbrauchen, da über 100 Agents entstehen können.

Praxisregel: 

• low oder medium für Boilerplate, einfache Code-Generierung und geradlinige Refactors. 

• high oder xhigh für komplexes Debugging, Architekturentscheidungen und Multi-File-Analysen, bei denen „gleich richtig“ viel Hin und Her spart. 

• ultracode nur für große Refactors, Codebase-Rewrites oder Aufgaben mit vielen beweglichen Teilen. 

Der Effort beeinflusst Qualität und Tokenkosten direkt – es lohnt sich, ihn zur Aufgabe passend zu wählen.

So erstellst du eigene Slash-Befehle in Claude Code

Die eingebauten Befehle decken die operative Basis ab. Eigene Slash-Befehle sind der Punkt, an dem sich das Tool wie dein persönliches Werkzeug anfühlt.

Die Idee ist simpel: Jeder Prompt, den du regelmäßig tippst, lässt sich als Befehlsdatei speichern und per /befehlsname aufrufen. Die Code-Review-Checkliste deines Teams, die Deploy-Checks deines Projekts oder dein persönlicher Stil, Tests anzufordern – alles wird teilbar. 

Slash-Befehle vs. Agent-Skills

Wichtig vorweg: Anthropic hat benutzerdefinierte Befehle mit Skills vereinheitlicht. Das Format .claude/commands/ gilt als Legacy. Es funktioniert weiterhin, und die CLI unterstützt es, aber empfohlen ist künftig .claude/skills/<name>/SKILL.md. 

Skills unterstützen denselben Aufruf per /name, können von Claude bei passender Beschreibung auch autonom genutzt werden und bündeln Zusatzdateien (Skripte, Templates, Referenzen) direkt neben dem Prompt. 

Mehr zu Skills findest du im Tutorial Claude Skills.

Wo eigene Befehle liegen

Eigene Befehle sind Markdown-Dateien an einem von zwei Orten:

• Projektweit: .claude/commands/ im Projekt-Root. Sie sind auf dieses Projekt beschränkt, versionierbar und werden mit allen geteilt, die am selben Repo arbeiten.

• Persönlich (global): ~/.claude/commands/ im Home-Verzeichnis. Sie sind auf deiner Maschine projektübergreifend verfügbar und privat.

Der Dateiname ohne .md wird zum Befehlsnamen. Eine Datei .claude/commands/fix-issue.md erzeugt /fix-issue. Eine Datei .claude/commands/frontend/component.md erzeugt /component mit einem Namespace-Hinweis, dass sie aus dem frontend-Unterordner stammt.

Wenn du das Skills-Format bevorzugst, sind die äquivalenten Pfade .claude/skills/<command-name>/SKILL.md auf Projektebene und ~/.claude/skills/<command-name>/SKILL.md für persönliche Skills. Frontmatter und Prompt-Body funktionieren wie unten beschrieben.

Das Dateiformat

Der Body der Markdown-Datei ist die Promptvorlage. Beim Aufruf liest Claude die Datei, verarbeitet Ersetzungen und führt sie aus, als hättest du den Prompt selbst geschrieben.

Ein minimales Beispiel für .claude/commands/summarize-pr.md:

Review the current git diff and write a concise pull request description.
Include: what changed, why it changed, and any important implementation notes.
Format as plain prose, not bullet points.

Mit /summarize-pr führt Claude diesen Prompt gegen die aktuelle Session aus.

YAML-Frontmatter hinzufügen

Für mehr Steuerung fügst du am Anfang YAML-Frontmatter ein:

description: Generate a PR description from the current diff
allowed-tools: Bash(git diff *), Read
model: claude-sonnet-4-6

Das Frontmatter ist aus mehreren Gründen wichtig:

• description erscheint in der /help-Liste, damit du weißt, was der Befehl tut – und damit Claude ihn automatisch matchen kann, wenn du einen Use Case beschreibst, ohne den Befehl/Skill direkt zu nennen.

• allowed-tools begrenzt, welche Tools Claude beim Ausführen nutzen darf – gut, um Umfang und Kontext zu kontrollieren. 

• model pinnt den Befehl auf ein bestimmtes Modell, unabhängig vom aktuell aktiven.

$ARGUMENTS verwenden

Der Platzhalter $ARGUMENTS macht benutzerdefinierte Befehle flexibel. Alles, was du nach dem Befehlsnamen tippst, wird an jeder Stelle ersetzt, an der $ARGUMENTS steht.

Ein vollständiges Beispiel: Wir erstellen einen Befehl zum Beheben von Repo-Issues namens .claude/commands/fix-issue.md:

---
description: Find and fix a GitHub issue by number
allowed-tools: Read, Edit, Bash(git diff *)
argument-hint: [issue-number]
---

Find and fix issue #$ARGUMENTS in this repository.

Steps:
1. Read the relevant source files to understand the current behavior
2. Identify the root cause
3. Implement the fix with minimal scope — do not change unrelated code
4. Verify the fix does not break anything obvious
5. Write a brief explanation of what changed and why

Du rufst ihn mit /fix-issue 847 auf, und Claude erhält den vollen Prompt – $ARGUMENTS wird durch 847 ersetzt. Für mehrere Eingaben kannst du auch Positionsargumente $0, $1 usw. verwenden.

Live-Shell-Ausgaben injizieren

Befehle können mit dem Präfix ! Live-Shell-Ausgaben injizieren. Das ist nützlich für Befehle, die immer auf dem aktuellen Zustand arbeiten sollen:

allowed-tools: Read, Bash(git *)
description: Review staged changes before committing

Current staged diff:
!git diff --cached

Review these changes and suggest a clear, conventional commit message.
Flag any obvious bugs, missing tests, or incomplete logic before I commit.

Beim Laden führt Claude git diff --cached aus, fängt die Ausgabe ab und injiziert sie in den Prompt. Claude sieht also den echten Diff, nicht nur einen Platzhalter.

Diese Kombination aus $ARGUMENTS, Shell-Injektion und Frontmatter macht Custom Commands in Claude Code zu einem starken Beschleuniger fürs Prompting. 

Weitere Patterns und Beispiele aus der Praxis zeigen DataCamps Tutorials zu Claude Code Best Practices und Claude Code Hooks – dort siehst du, wie diese Tools in produktiven Workflows zusammenspielen.

Zum Schluss

Slash-Befehle sind keine Profi-Spielerei. Sie sind die operative Basisschicht von Claude Code – wer sie früh lernt, geht KI-unterstützte Entwicklung grundlegend anders an.

Wenn du neu einsteigst, fang klein an: /compact, /plan und /cost sind kleine, aber wirkungsvolle Hebel, um Sessions zu optimieren. Sobald das sitzt, nutze /diff vor Commits und /goal für alles, was länger als ein paar Runden läuft. Der Rest kommt, wenn die Situationen auftreten.

Für mehr Inspiration zu eigenen Befehlen empfehle ich unser Claude Code Terminal-Tutorial. Wenn du eine strukturierte Grundlage dafür willst, wie Claude-Modelle denken und wofür sie gebaut sind, sind unsere Kurse Introduction to Claude Models und Claude Code 101 der richtige Startpunkt.