Die schnellste Beschleunigung, die ich dieses Jahr in Claude Code bekam, war kein Modell-Upgrade. Es war das Erlernen, einen einzelnen Schrägstrich zu tippen, gefolgt von vier Buchstaben.
Ich hatte Claude Code über ein Jahr lang täglich benutzt, bevor ich etwas Peinliches zugab: Ich ließ den größten Teil seines Potenzials ungenutzt. Ich öffnete eine Sitzung, tippte einen ganzen Absatz an Anweisungen, schaute zu, wie es arbeitete, stieß an eine Wand, und startete eine brandneue Sitzung, indem ich das Terminal komplett schloss. Jedes. Einzelne. Mal. Ich bezahlte für Kontext, den ich ständig wegwarf, erklärte dasselbe Projekt immer wieder von null, und verbrannte Verbrauch an Gesprächen, die so weit vom Thema abgedriftet waren, dass Claude im Grunde nur riet.
Dann begann ich, die Slash-Befehle tatsächlich zu nutzen. Nicht so, wie die Dokumentation sie auflistet — alphabetisch, flach, wie ein Glossar, das niemand liest. Ich meine die vier oder fünf, nach denen ich jetzt so reflexartig greife, dass meine Finger sich bewegen, bevor mein Gehirn den Gedanken zu Ende gebracht hat. Die Befehle, die darüber entscheiden, ob eine zweistündige Build-Session sich wie Flow anfühlt oder wie ein Kampf gegen das Werkzeug.
Dies ist die praktische Version davon. Die Claude Code Slash-Befehle, die ich wirklich jeden Tag nutze, gruppiert nach dem tatsächlichen Problem, das jeder einzelne löst — Kontext, der veraltet ist, ein Build, der schiefgelaufen ist, ein Plan, den ich sehen wollte, bevor auch nur eine Zeile Code geschrieben wurde. Für jeden Befehl: was er tut, die genaue Art, wie ich ihn aufrufe, und der spezifische Moment, in dem ich bei echter Arbeit danach greife.
Ein paar der "Befehle", die in Tutorials und Videos kursieren, stellten sich als Community-Jargon heraus oder als Funktionen, die ein wenig anders funktionieren, als die Leute beschreiben. Ich werde die ehrlich kennzeichnen, während wir fortfahren, denn das Kennen des genauen Bildes ist der ganze Punkt — ein Befehl, von dem du denkst, dass er existiert, aber nicht existiert, ist schlimmer als gar kein Befehl.
Fangen wir dort an, wo jede gute Sitzung beginnt und endet: beim Kontext.
Was sind Slash-Befehle in Claude Code?
Slash-Befehle sind Abkürzungen, die du auslöst, indem du / in der Claude Code-Eingabeaufforderung tippst, was ein Autovervollständigungs-Menü mit Aktionen öffnet, die du ausführen kannst, ohne lange Anweisungen zu schreiben. Sie steuern die Sitzung selbst — Kontext löschen, Code zurückspulen, alte Gespräche fortsetzen, die Oberfläche konfigurieren — statt Prompts zu sein, die du an das Modell sendest.
Diese Unterscheidung ist wichtiger, als sie klingt. Eine normale Nachricht bittet Claude, etwas in deiner Codebase zu tun. Ein Slash-Befehl bittet Claude Code, etwas mit der Sitzung zu tun, in der du arbeitest. Das eine bearbeitet Dateien; das andere verwaltet die Umgebung, in der diese Bearbeitungen stattfinden.
Die Autovervollständigung erscheint, sobald du / tippst — im Terminal und in der Desktop-App — du musst also keine genauen Schreibweisen auswendig lernen. Tippe /re und du siehst /rewind und /resume zusammen auftauchen. So entdecke ich auch Befehle, die ich vergessen hatte, was die Hälfte des Grundes ist, warum ich überhaupt den Schrägstrich tippe, anstatt nach einer Tastenkombination zu greifen, an die ich mich nur halb erinnere.
Hier ist, was die meisten Spickzettel falsch machen: Sie behandeln alle vierzig-und-noch-was Befehle als gleich lernwürdig. Sind sie nicht. Ich nutze vielleicht sechs davon täglich und den Rest fast nie. Also werde ich nicht alles auflisten. Ich werde dich durch die Handvoll führen, die ihren Platz im Muskelgedächtnis verdienen — und dir sagen, welche das Internet falsch hat.
Der erste ist der Befehl, den ich am ersten Tag hätte lernen sollen.
Kontextverwaltung: /clear, /resume und /rewind
Der größte Teil des Unbehagens, das ich früher in Claude Code empfand, ließ sich auf eine einzige Grundursache zurückführen: Ich war schlecht im Verwalten von Kontext. Entweder hatte ich zu viel davon (ein aufgeblähtes Gespräch, bei dem Claude ständig über alte, irrelevante Anweisungen stolperte) oder ich hatte den Kontext verloren, den ich eigentlich wollte (eine Sitzung, die ich zu früh geschlossen hatte und nicht zurückbekam). Drei Befehle lösten fast alles.
/clear — der Reset, den ich viel zu lange vermied
/clear löscht den aktuellen Gesprächsverlauf aus dem Kontextfenster und lässt dich frisch beginnen — ohne dein Projektgedächtnis zu löschen.
Diese zweite Hälfte ist der Teil, den ich monatelang falsch verstand, und es lohnt sich, präzise zu sein, weil es verändert, wie aggressiv du den Befehl nutzen solltest. Wenn du /clear ausführst, entfernt es alles aus dem aktiven Kontextfenster: das Hin und Her, die Dateien, die Claude gelesen hat, die Sackgassen. Aber es berührt nicht deine CLAUDE.md-Datei. CLAUDE.md wird zu Beginn jeder Sitzung frisch geladen, also überlebt es ein /clear und wird neu injiziert. Dein Projektbriefing bleibt. Nur der gesprächsbedingte Ballast verschwindet.
Ich dachte früher, Löschen bedeutet "alles verlieren und das ganze Projekt von vorn erklären." Das stimmt nicht — nicht, wenn du die dauerhaften Dinge (Architektur, Konventionen, das Datenbankschema) in CLAUDE.md abgelegt hast, wo sie hingehören. Diese Erkenntnis ist es, die mich schließlich dazu brachte, ständig zu löschen, anstatt es zu fürchten.
Jetzt die Regel, der ich folge: In dem Moment, in dem ich eine logische Aufgabe abschließe und zu einer unverwandten wechsle, lösche ich. Fertig mit dem Einrichten der Authentifizierung, kurz davor, die Abrechnungsseite zu bauen? /clear. Zwei Gründe. Erstens macht ein veraltetes Kontextfenster voller Authentifizierungsdetails Claude schlechter bei der Abrechnungsarbeit — es erkennt Muster bei den falschen Dingen, verweist auf Dateien, die keine Rolle spielen, und bearbeitet gelegentlich "hilfsbereit" etwas, worum ich nie gebeten habe. Zweitens ist jedes Token dieses toten Kontexts ein Token, für das ich bezahle und ein Token, das meine Verbrauchslimits auffrisst. Eine lange, abdriftende Sitzung ist in beiden Hinsichten teuer.
Wenn du nur einen Befehl aus diesem ganzen Beitrag übernimmst, lass es diesen sein. Lösche zwischen Aufgaben. Deine Ausgabequalität steigt und dein Verbrauch sinkt gleichzeitig, was fast nie zusammen vorkommt.
Es gibt einen verwandten Befehl, den es sich zu kennen lohnt: /compact. Wo /clear das Gespräch vollständig wegwirft, fasst /compact es in eine komprimierte Form zusammen, sodass du den Kern behältst, während du Kontext freigibst. Ich greife zu /compact mitten in einer Aufgabe, wenn ein einzelnes Arbeitsstück lang geworden ist, ich aber noch die Geschichte brauche; ich greife zu /clear, wenn ich wirklich fertig bin und den Gang wechsle. Verschiedene Werkzeuge für verschiedene Momente.
/resume — ein Gespräch zurückbekommen, von dem du dachtest, es wäre weg
/resume lässt dich ein früheres Claude Code-Gespräch wieder öffnen, indem du es aus einer Liste auswählst, sodass eine Sitzung, die du geschlossen — oder sogar gelöscht — hast, nicht unbedingt verloren ist.
Dies ist der Befehl, der mir echten Kummer erspart hat. Stell dir das Szenario vor: Ich lösche eine Sitzung, wechsle die Aufgabe, und zwanzig Minuten später merke ich, dass ich etwas aus dem Gespräch brauchte, das ich gerade gelöscht hatte — eine Entscheidung, die wir getroffen haben, ein Code-Snippet, das Claude generiert hat, die Begründung hinter einem Ansatz. Vor /resume war das weg, und ich spürte es.
Mit /resume führe ich den Befehl aus, bekomme eine Liste der letzten Sitzungen und wähle die aus, die ich zurückhaben möchte. Es unterscheidet sich vom Zurückspulen innerhalb eines aktiven Gesprächs — /resume greift über Sitzungen hinweg, um eine frühere vollständig wiederherzustellen. Sieh es als den Unterschied zwischen dem Rückgängigmachen deiner letzten paar Bearbeitungen in einem Dokument und dem Wiederöffnen einer Datei, die du gestern geschlossen hast.
Der Workflow, den ich entwickelt habe: Ich lösche aggressiv, weil ich weiß, dass /resume mir den Rücken deckt. Die Angst, Kontext zu verlieren, war es, die mich horten ließ. Sobald ich darauf vertraute, dass ich eine alte Sitzung zurückholen konnte, wenn ich sie wirklich brauchte, fühlte sich Löschen nicht mehr riskant an, sondern wie Hygiene.
/rewind — Rückgängig machen für Code, nicht nur für Gespräche
/rewind spult deine Sitzung zu einem früheren Kontrollpunkt zurück und kann deinen Code, dein Gespräch oder beides wiederherstellen — unabhängig voneinander.
Dies ist der Befehl, der verändert hat, wie ambitioniert ich Claude arbeiten lasse. Claude Code erstellt automatisch einen Kontrollpunkt, der den Zustand deines Codes vor jeder Bearbeitung erfasst, jedes Mal, wenn du einen Prompt sendest. Wenn also eine Änderung über mehrere Dateien schiefgeht — und bei einem großen Refactoring passiert das manchmal — gerate ich nicht in Panik und beginne nicht, Dateien manuell zurückzusetzen. Ich öffne /rewind.
Du kannst es auf zwei Arten auslösen: Tippe /rewind, oder drücke zweimal Esc, wenn das Prompt-Eingabefeld leer ist. Beides öffnet das Zurückspul-Menü mit deinen letzten Kontrollpunkten. Dann wählst du, was du wiederherstellen möchtest:
- Code und Gespräch wiederherstellen — spule beides zu diesem Punkt zurück, als wären die letzten paar Minuten nie passiert.
- Gespräch wiederherstellen — spule den Chat zu einer früheren Nachricht zurück, behalte aber deinen aktuellen Code. Nützlich, wenn der Code in Ordnung ist, aber das Gespräch einen verwirrenden Weg genommen hat.
- Code wiederherstellen — setze die Dateiänderungen zurück, aber rede weiter. Dies ist der, den ich am häufigsten nutze: "Dieser Ansatz war falsch, mach die Dateien rückgängig, aber lass uns weiter besprechen, warum."
Es gibt auch Optionen "ab hier zusammenfassen" / "bis hier zusammenfassen", die einen Teil des Gesprächs komprimieren, um Kontext zurückzugewinnen — eine schöne Überschneidung mit dem /compact-Konzept.
Eine Einschränkung, die du unbedingt kennen musst, weil sie Leute verbrannt hat: /rewind verfolgt nur Bearbeitungen, die Claude über seine Dateibearbeitungs-Tools vorgenommen hat. Bash-Befehle werden nicht als Kontrollpunkt erfasst. Wenn Claude rm, mv oder cp ausgeführt hat, sind diese Änderungen permanent — Zurückspulen bringt sie nicht zurück. Kontrollpunkte bleiben auch über Sitzungen hinweg bestehen und räumen sich nach 30 Tagen automatisch auf. Zurückspulen ist also ein Sicherheitsnetz für Bearbeitungen, kein Ersatz für Git. Ich committe immer noch häufig. Zurückspulen ist für die Zwischenmomente; Git ist für die Grundwahrheit.
Wenn du tiefer eintauchen möchtest, wie ich Token-Verbrauch rund um all dieses Löschen und Komprimieren strukturiere, habe ich das separat ausgearbeitet in meinem Leitfaden zur Senkung der Claude Code Token-Kosten mit dem Höhlenmenschen-Ansatz — Kontextdisziplin und Kostendisziplin sind dieselbe Fähigkeit mit zwei Hüten.
Das war Kontext. Die nächste Gruppe dreht sich um Qualität — Claude zum Nachdenken bringen, bevor es handelt.
Planung und Qualität: Planmodus und Klären-dann-Planen
Der größte Sprung in meiner Ausgabequalität kam nicht von einem Kontext-Befehl. Er kam davon, dass ich Claude zwang, zu planen, bevor es auch nur eine einzige Zeile schreibt. Es gibt zwei Wege, wie ich das mache — einen eingebauten, einen den ich selbst baue — und der zweite ist das Herzstück dieses ganzen Beitrags.
Planmodus — den Ansatz sehen, bevor Code geschrieben wird
Planmodus ist ein Nur-Lese-Zustand, in dem Claude deine Codebase analysiert und einen vollständigen Implementierungsplan vorschlägt, bevor es Dateien anfasst, sodass du den Ansatz überprüfen und anpassen kannst, bevor die Ausführung beginnt.
Kurze Genauigkeitsanmerkung, weil das Leute verwirrt: Viele Videos und Transkripte nennen dies "den /plan-Befehl", und das ist nur halb richtig. Planmodus ist schon lange in den Berechtigungszyklus von Claude Code eingebaut — du aktivierst ihn, indem du zweimal Shift+Tab drückst, um auf ⏸ Planmodus an am unteren Rand deines Terminals zu landen. Ab Claude Code v2.1.0 gibt es auch einen wörtlichen /plan-Befehl, der denselben Modus einschaltet, plus du kannst mit claude --permission-mode plan starten oder ihn als Projektstandard in .claude/settings.json setzen. Wenn du also "/plan" gehört hast und es in einer älteren Version nichts zu tun schien — das ist der Grund. Der Shift+Tab-Weg funktioniert immer.
Hier ist, was Planmodus tatsächlich tut. Während er aktiv ist, behält Claude vollen Zugang zu seinen Lese-Tools — Read, Glob, Grep, WebSearch, WebFetch — aber jedes Schreib-Tool ist blockiert: kein Edit, kein Write, keine Bash-Ausführung. Es liest deine Codebase, kartiert Abhängigkeiten, durchdenkt den ganzen Ansatz und gibt dir einen nummerierten Plan. Du liest ihn. Du korrigierst ihn, wenn er falsch ist. Dann genehmigst du, und erst dann führt es aus.
Der Moment, in dem ich nach Planmodus greife: jede Aufgabe, die mehr als zwei oder drei Dateien berührt, oder alles, bei dem ich mir nicht 100% sicher bin, dass Claude und ich dasselbe mentale Modell davon teilen, wie die Änderung geschehen soll. Eine Datenbankmigration. Ein Refactoring über Komponenten. Das Verdrahten einer neuen API in einen bestehenden Ablauf. Dafür fängt das Betrachten von Claudes Plan das Missverständnis auf, bevor es zu dreißig Minuten falschem Code wird, den ich dann zurückspulen muss.
Der Fehler, den ich bei Leuten sehe, ist, Planmodus für alles zu verwenden, einschließlich trivialer Ein-Datei-Bearbeitungen, wo er nur Reibung hinzufügt. Planmodus verdient seinen Platz bei Mehrdeutigkeit und Größe. Für "füge hier ein console.log ein" überspring ihn.
Planmodus ist mächtig, aber er ist reaktiv — Claude plant basierend auf dem, was ich ihm gesagt habe. Die nächste Technik löst das tiefere Problem: Was passiert, wenn mein Prompt selbst unvollständig war.
Benutzerdefinierte Slash-Befehle — einen "Klären, dann Planen, dann Ausführen"-Befehl bauen
Dies ist der Abschnitt, von dem ich dir sagen würde, ihn zweimal zu lesen. Benutzerdefinierte Slash-Befehle sind die Funktion mit dem höchsten Hebel in Claude Code, die die meisten Menschen nie berühren, und sie sind aufrichtig einfach zu bauen.
Ein benutzerdefinierter Slash-Befehl ist einfach eine Markdown-Datei. Du erstellst eine Datei in .claude/commands/ (projektgebunden, geteilt mit allen im Repo) oder ~/.claude/commands/ (persönlich, folgt dir über jedes Projekt). Der Dateiname wird zum Befehlsnamen. Der Inhalt der Datei wird zum Prompt, der an Claude gesendet wird, wenn du ihn aufrufst. Das ist der gesamte Mechanismus.
Wenn ich also Folgendes ausführe:
mkdir -p .claude/commands
und eine Datei namens .claude/commands/build.md erstelle, dann injiziert das Tippen von /build in jeder Sitzung innerhalb dieses Projekts das, was ich in diese Datei geschrieben habe, als meinen Prompt. Der Befehl erscheint automatisch im /-Autovervollständigungsmenü.
Nun — warum ist das wichtig? Weil der größte Qualitätskiller beim KI-Codieren nicht das Modell ist. Es ist die Lücke zwischen dem, was ich gefragt habe, und dem, was ich tatsächlich meinte. Ich schreibe einen vagen Prompt, Claude macht vernünftige-aber-falsche Annahmen, um die Lücke zu füllen, und ich bekomme selbstbewussten, sauberen Code, der das falsche Problem löst.
Die Lösung ist ein Befehl, der Claude zwingt, diese Lücke zu schließen, bevor es etwas schreibt. Hier ist der tatsächliche Befehl, den ich in meinen Repos aufbewahre. Nenne ihn .claude/commands/scope.md:
# Kläre die Anfrage, plane dann, baue dann.
Du bist dabei zu implementieren: $ARGUMENTS
Schreibe noch KEINEN Code. Arbeite diese Schritte der Reihe nach durch:
1. KLÄRE. Stelle mir bis zu 5 spezifische Fragen zu allem, was in der
Anfrage mehrdeutig ist — Datenformen, Randfälle, Benennung, wo dies
in die bestehende Architektur passt, wie "fertig" aussieht. Wenn etwas
wirklich eindeutig ist, fülle die Liste nicht auf — frage nur, was du brauchst.
2. PLANE. Sobald ich antworte, formuliere die Aufgabe in einem Satz neu,
dann gib mir einen nummerierten Implementierungsplan: die Dateien, die du
erstellen oder ändern wirst, die Reihenfolge, und jede Entscheidung, die du
triffst, die ich jetzt ablehnen sollte statt nachdem der Code existiert.
3. WARTE. Stoppe und lass mich den Plan genehmigen oder korrigieren, bevor du
eine einzige Datei anfasst.
Beginne erst mit der Implementierung, nachdem ich genehmige.
Der $ARGUMENTS-Platzhalter ist der eigentliche Trick — was auch immer ich nach dem Befehlsnamen tippe, wird dort eingesetzt. Also führe ich /scope füge Team-Einladungen zur Einstellungsseite hinzu aus und Claude nimmt "füge Team-Einladungen zur Einstellungsseite hinzu" als das Ding, das geklärt und geplant werden soll.
Was bringt mir das in der Praxis? Die klärenden Fragen sind der Punkt, an dem die Magie steckt. Die Hälfte der Zeit bringen Claudes Fragen etwas an die Oberfläche, das ich noch nicht entschieden hatte — "Sollen eingeladene Benutzer sofort eine Rolle bekommen oder ausstehend bleiben, bis sie akzeptieren?" — und es laut zu beantworten, bevor Code existiert, bedeutet, dass ich nie die falsche Implementierung bekomme. Der Planschritt lässt mich dann günstig einen Ansatz ablehnen, während er noch Worte auf einem Bildschirm sind statt Dateien auf der Festplatte.
Ich kann dir keine saubere Prozentzahl geben, wie sehr dies die Ausgabe verbessert — und ich möchte ehrlich sein, weil ich die Behauptung kursieren gesehen habe, dass benutzerdefinierte Klären-dann-Plan-Befehle die Qualität "um bis zu 43% verbessern basierend auf internen Berichten," und ich konnte nie eine echte Grundlage für diese Zahl finden. Also werde ich nicht so tun als ob. Was ich dir sagen kann aus täglicher Nutzung ist qualitativ und konsistent: Das Erzwingen der Klären-dann-Planen-dann-Ausführen-Sequenz reduziert die Anzahl der "das ist nicht, was ich meinte"-Überarbeitungen, die ich mache, deutlich. Die Nacharbeit, die ich spare, ist die gesamte Rendite der Investition. Dass die Zahl nicht verifizierbar ist, macht die Technik nicht weniger real — es bedeutet nur, dass ich sie nicht mit einer Statistik aufhübschen werde, hinter der ich nicht stehen kann.
Wenn du tiefer in den Aufbau eintauchen möchtest, habe ich eine vollständige Aufschlüsselung geschrieben vom /advisor benutzerdefinierten Slash-Befehl und der metakognitiven Schicht, die er hinzufügt — dieselben Bausteine, anderer Zweck. Und der Grund, warum dieser ganze Ansatz funktioniert, knüpft direkt an warum Context-Engineering eine zukunftssichere Kernkompetenz wird an: Die Entwickler, die mit diesen Tools gewinnen, sind nicht die, die am schnellsten tippen, sondern die, die Kontext und Absicht am besten strukturieren.
Wenn du lieber jemanden hättest, der ein komplettes Setup aus benutzerdefinierten Befehlen und Agenten baut, das auf deinen Stack abgestimmt ist, anstatt es selbst zusammenzubauen, ist das die Art von Arbeit, die ich direkt übernehme — du kannst sehen, was ich gebaut habe, auf meinem Fiverr-Profil.
Ein kurzes Wort über einen Befehl, nach dem Leute fragen, der aber nicht so existiert, wie sie denken.
Über "/goal" — ein Muster, das du baust, kein Knopf, den du drückst
Ich werde nach einem "/goal"-Befehl gefragt, der dir angeblich erlaubt, eine Aufgabe plus eine Definition von "fertig" festzulegen und Claude weiterarbeiten zu lassen, bis ein zweiter Agent verifiziert, dass es vollständig ist. Ich habe das sorgfältig untersucht, und hier ist das ehrliche Bild: Es gibt keinen eingebauten /goal Slash-Befehl in Claude Code, der das tut. Ich konnte es in der aktuellen Dokumentation nicht bestätigen, und du solltest nicht als Standardfunktion danach suchen.
Was real ist, ist das Muster dahinter — und es ist ein gutes Muster. Du kannst absolut selbst einen verifikationsgetriebenen Workflow bauen: ein benutzerdefinierter Befehl, der Claude eine Aufgabe plus explizite "Definition von fertig"-Kriterien gibt, gepaart mit einem Subagenten, dessen einzige Aufgabe es ist, die Arbeit gegen diese Kriterien zu prüfen, bevor sie als abgeschlossen erklärt wird. Das ist etwas Baubares, nichts Eingebautes. (OpenAIs Codex, separat, liefert einen wörtlichen /goal-Befehl für autonome Läufe — ich habe ihn getestet und aufgeschrieben, wie sich der /goal-Befehl von Codex tatsächlich verhält. Verwechsle die beiden nicht; es sind verschiedene Tools.)
Das Fazit: Wenn dir ein Tutorial eine magische Claude Code /goal-Taste verspricht, sei skeptisch. Die Fähigkeit steht dir zur Verfügung, um sie mit benutzerdefinierten Befehlen und Subagenten zusammenzubauen — was ohnehin flexibler ist.
Jetzt das kleine Zeug, das jede Sitzung leise verbessert.
Umgebung und UX: /statusline und das Werkzeug kennenlernen
Diese verändern nicht, was Claude tut. Sie verändern, wie viel ich sehen kann, während es das tut — und wie schnell ich Funktionen entdecke, von denen ich nicht wusste, dass sie existieren.
/statusline — eine einmalige Einrichtung, die sich in jeder Sitzung auszahlt
/statusline konfiguriert die Statusleiste am unteren Rand deines Terminals, mit der du Dinge wie das aktive Modell, Kontextverbrauch und Kosten anzeigen kannst — sodass du auf einen Blick sehen kannst, was passiert, ohne zu raten.
Noch eine Genauigkeitsanmerkung: Leute schreiben es als "/status line" (zwei Wörter). Der echte Befehl ist /statusline, ein Wort, in der Autovervollständigung. Du führst ihn einmal aus, konfigurierst, was du sehen möchtest, und dann ist er einfach jede Sitzung da.
Warum ich mich die Mühe mache: Sichtbarkeit von Kontextverbrauch und Kosten. Wenn meine Statusleiste mir zeigt, wie voll das Kontextfenster wird, weiß ich, dass es Zeit ist für /clear oder /compact, bevor Claude anfängt zu degradieren — anstatt die Degradierung im Nachhinein zu bemerken. Das aktive Modell zu sehen erinnert mich daran, ob ich auf der richtigen Stufe für die Aufgabe bin. Es ist eine kleine, einmalige Konfiguration, die eine Menge unsichtbaren Status in etwas Ablesbares verwandelt. Für die tiefere Philosophie von "alles sehen und steuern, was Claude tut," bin ich tiefer eingegangen in meiner Aufschlüsselung der agentischen OS visuellen Schicht.
/powerup und /radio — die zwei, die ich erwähne, aber nicht überbewerten werde
Zwei weitere echte Befehle, der Vollständigkeit und Ehrlichkeit halber aufgenommen.
/powerup (eingeführt in Claude Code v2.1.90) ist ein interaktives Tutorial im Terminal — animierte Lektionen, die jeweils eine Sache lehren, die Claude Code kann, die die meisten Leute verpassen. Es ist aufrichtig nützlich zum Entdecken von Funktionen, und ich habe ihm seinen eigenen vollständigen ersten Eindruck gegeben in meinem Stück darüber, was /powerup tatsächlich lehrt, also werde ich das hier nicht wiederholen.
/radio ist auch echt, und es ist genau das, wonach es klingt: Es öffnet Claude FM, einen Lo-Fi-Radiosender, den Anthropic betreibt, in deinem Browser. Ist es ein Produktivitätsbefehl? Nein. Benutze ich es während der langweiligen Teile eines Builds? Manchmal. Ich nehme es auf, weil ich dir gesagt habe, ich würde dir das genaue Bild geben, und das genaue Bild ist, dass es existiert und ein lustiges kleines Nichts ist. Behandle es entsprechend.
Es gibt auch /btw — eine leichtere Art, eine Nebenfrage zu stellen oder Kontext hinzuzufügen, ohne dass es deinen Hauptgesprächsfaden aufbläht, was lange Sitzungen schlanker hält. Es ist ein echter Mechanismus, den es sich zu kennen lohnt, wenn du dich mitten in einer Aufgabe klären möchtest, ohne den Fluss zu entgleisen.
Das ist das ehrliche Verzeichnis. Jetzt lass mich dir zeigen, wie das aussieht, wenn es bei echter Arbeit zusammengehängt wird.
Wie eine echte Sitzung aussieht, wenn diese Befehle zusammengehängt werden
Befehle in einer Liste sind abstrakt. Hier ist, wie sie an einem normalen Build-Tag für mich tatsächlich zusammenwirken.
Ich öffne Claude Code in einem Projekt. CLAUDE.md lädt automatisch, also kennt Claude bereits den Stack und die Konventionen — ich erkläre nichts neu. Ich möchte ein Feature hinzufügen, also tippe ich /scope füge CSV-Export zur Berichtsseite hinzu. Mein benutzerdefinierter Befehl tritt in Aktion: Claude stellt mir vier Fragen (welche Spalten, welches Datumsformat, serverseitige oder clientseitige Generierung, wie der Dateiname lauten soll), ich antworte, es gibt mir einen Fünf-Schritte-Plan, ich passe Schritt drei an, ich genehmige.
Es baut. Auf halbem Weg verwickelt sich die Export-Logik mit der bestehenden Paginierung und die Ausgabe stimmt nicht. Ich zerlege es nicht manuell — ich öffne /rewind, stelle den Code auf den Stand vor der Verwicklung wieder her, behalte das Gespräch, und sage "dieser Ansatz kollidierte mit der Paginierung, lass uns den vollständigen Datensatz separat generieren." Saubere Erholung, vielleicht neunzig Sekunden verloren.
Feature fertig. Ich /clear. Frisches Fenster, Projektgedächtnis intakt, null veralteter Kontext, der in die nächste Aufgabe durchsickert. Meine Statusleiste — einmal vor Wochen mit /statusline konfiguriert — zeigt, dass ich kaum Kontext verwende, was genau so ist, wie eine frische Aufgabe beginnen sollte.
Drei Aufgaben später merke ich, dass ich eine Entscheidung aus einer Sitzung brauche, die ich vorher gelöscht habe. /resume, wähle sie aus der Liste, hole, was ich brauchte, und weiter geht's.
Fünf Befehle. Keiner davon hat Code geschrieben. Alle haben die Bedingungen geformt, unter denen der Code gut geschrieben wurde. Das ist der ganze Punkt — die Slash-Befehle sind nicht die Arbeit, sie sind die Werkstatt.
Der ehrliche Teil: wo ich falsch lag, und was deine Zeit wert ist
Lass mich ehrlich sein über die Korrekturen, denn einem Praktiker dabei zuzusehen, wie er seine eigenen Annahmen zurücknimmt, ist nützlicher als eine saubere Liste, die so tut, als wäre alles bestätigt.
Ich habe zu lange /clear als Verlust behandelt statt als Hygiene — das war eine echte Workflow-Belastung, die ich monatelang bezahlt habe. "/plan" als eigenständiger Befehl ist neuer (v2.1.0) als der Shift+Tab-Planmodus, auf dem er aufbaut, also wenn du auf einer älteren Version bist, greife zum Tastenkürzel. "/statusline" ist ein Wort, nicht zwei. Und der "/goal-Befehl", den Leute als in Claude Code eingebaut beschreiben, ist es nicht — es ist ein Muster, das du zusammenbaust, und es mit dem tatsächlichen /goal-Befehl von Codex zu verwechseln trübt das Wasser. Die "43% Qualitätsverbesserung"-Zahl, die benutzerdefinierten Befehlen zugeschrieben wird, hat keine Grundlage, die ich finden konnte, also habe ich sie fallen gelassen und dir gesagt warum, anstatt eine nicht verifizierbare Zahl in eine selbstbewusste Behauptung zu waschen.
Was wirklich deine Zeit wert ist, in Prioritätsreihenfolge: /clear zwischen Aufgaben (größter, einfachster Gewinn), ein benutzerdefinierter Klären-dann-Plan-Befehl (größter Qualitätsgewinn), /rewind zur Erholung von schlechten Bearbeitungen (größte Stressreduktion), und Planmodus für alles Mehrdeutige oder Mehrdateien-Betreffende (größter Verhinderer von "falschem Code"). Der Rest — /resume, /statusline, /compact, /btw — sind echt, nützlich und wissenswert, aber sie sind die Nebenrollen.
Wenn deine Claude Code-Sitzungen sich derzeit wie lange, abdriftende Gespräche anfühlen, die schlechter werden, je länger sie dauern, ist die Lösung kein besseres Modell. Es ist ein Schrägstrich, vier Buchstaben, und die Disziplin zu löschen, was du nicht brauchst. Baue diese Woche einen benutzerdefinierten Befehl — das /scope-Beispiel oben, direkt kopiert in .claude/commands/scope.md — und nutze ihn bei deiner nächsten echten Aufgabe. Das erste Mal, wenn Claudes klärende Fragen eine falsche Annahme auffangen, bevor sie zu falschem Code wird, wirst du verstehen, warum ich diesen Schrägstrich tippe, bevor mein Gehirn den Gedanken zu Ende gebracht hat.
Häufig gestellte Fragen
Was ist der Unterschied zwischen /clear und /rewind in Claude Code?
/clear löscht deinen aktuellen Gesprächsverlauf, um eine frische Aufgabe zu beginnen, während dein CLAUDE.md-Projektgedächtnis erhalten bleibt, wohingegen /rewind zu einem früheren Kontrollpunkt innerhalb einer aktiven Sitzung zurückspult und deinen Code, dein Gespräch oder beides wiederherstellen kann. Verwende /clear, wenn du zu einer unverwandten Aufgabe wechselst; verwende /rewind, wenn eine Bearbeitung schiefging und du sie rückgängig machen musst. Siehe den Abschnitt zur Kontextverwaltung oben für die vollständige Aufschlüsselung.
Löscht /clear mein CLAUDE.md-Projektgedächtnis?
Nein — /clear entfernt nur das aktive Gespräch aus dem Kontextfenster; deine CLAUDE.md-Datei wird zu Beginn jeder Sitzung frisch geladen, also überlebt sie das Löschen. Das ist genau der Grund, warum du aggressiv zwischen Aufgaben löschen kannst, ohne den dauerhaften Kontext deines Projekts zu verlieren, solange das Wichtige in CLAUDE.md steht.
Wie erstelle ich einen benutzerdefinierten Slash-Befehl in Claude Code?
Erstelle eine Markdown-Datei in .claude/commands/ (projektgebunden) oder ~/.claude/commands/ (persönlich), und der Dateiname wird zum Befehlsnamen, während der Inhalt der Datei zum Prompt wird, der an Claude gesendet wird. Verwende den $ARGUMENTS-Platzhalter, um Eingaben nach dem Befehlsnamen zu übergeben. Das vollständige /scope Klären-dann-Planen-Beispiel befindet sich im Planungsabschnitt oben.
Gibt es einen /plan-Befehl oder ist es Planmodus in Claude Code?
Beides — Planmodus ist seit Langem in den Berechtigungszyklus eingebaut (drücke zweimal Shift+Tab), und ab Claude Code v2.1.0 gibt es auch einen wörtlichen /plan-Befehl, der denselben Nur-Lese-Planungszustand aktiviert. Wenn /plan auf deinem Setup nichts tut, bist du wahrscheinlich auf einer älteren Version; das Shift+Tab-Tastenkürzel funktioniert immer.
Gibt es einen eingebauten /goal-Befehl in Claude Code?
Nein, es gibt keinen Standard-/goal-Befehl in Claude Code, der eine Aufgabe bis zu einer Definition von "fertig" mit automatischer Verifikation ausführt. Diese Fähigkeit ist ein Muster, das du selbst baust, mit einem benutzerdefinierten Befehl plus einem Verifikations-Subagenten. OpenAIs Codex liefert einen separaten /goal-Befehl, aber das ist ein völlig anderes Werkzeug.
Lass uns zusammenarbeiten
Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.
- Fiverr (Maßanfertigungen & Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Enterprise-Lösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
