Wer nach „Claude Code commands“ sucht, bekommt jedes Mal die gleiche Liste: /clear, /compact, /model und ein paar Dutzend weitere, direkt aus der Dokumentation kopiert. Das ist zwar nützlich, beantwortet aber die falsche Frage. Diese Befehle steuern das Tool. Am Verhalten des Agenten ändern sie nichts, sobald du ihn bittest, etwas zu bauen. Dies ist eine Übersicht über beide Arten: die integrierten Befehle, die das Tool steuern, und die eigenen Befehle, die die Arbeit steuern. Und es ist ein Plädoyer dafür, warum in der zweiten Art fast die gesamte Hebelwirkung liegt.
Was sind Claude Code-Befehle?
Claude Code-Befehle sind getippte Tastenkürzel, die mit einem Slash beginnen. Es gibt zwei Arten, und dieser Unterschied ist wichtiger als jeder einzelne Befehl. Integrierte Slash-Befehle werden mit Claude Code geliefert und steuern die Sitzung selbst: Kontext löschen, Modelle wechseln, das Gedächtnis bearbeiten. Eigene Befehle schreibst du selbst: eine kleine Markdown-Datei, die zu einem wiederverwendbaren Workflow wird, den du über den Namen aufrufst. Integrierte Befehle steuern das Tool. Eigene Befehle steuern die Arbeit.
Die integrierten Claude Code-Befehle, die man kennen sollte
Die meisten Leute installieren Claude Code und nutzen vielleicht zehn Prozent davon. Hier sind die integrierten Befehle, die sich wirklich bezahlt machen, sortiert nach ihrer Aufgabe. Claude Code entwickelt sich schnell weiter. Betrachte dies also als Orientierung und führe /help aus, um die genaue Syntax für deine Version zu sehen.
/clear löscht die Konversation, /compact fasst zusammen und macht weiter, /context zeigt, was das Fenster füllt/memory durchsucht, was Claude gelernt hat; CLAUDE.md enthält deine Projektregeln, die bei jeder Sitzung geladen werden/model wechselt das Modell für die Aufgabe, /config passt die Einstellungen an, /output-style ändert, wie Claude antwortet/hooks zeigt die Skripte, die bei Bearbeitungen und anderen Ereignissen automatisch ausgeführt werden. Siehe den Hooks-Leitfaden/help aus, um die aktuelle, vollständige Liste zu sehen.Noch einer, der kein Slash-Befehl ist, aber hierher gehört: Drücke Shift+Tab, bis im Eingabefeld plan steht. Claude liest und schlägt die gesamte Änderung vor, ohne eine Datei zu bearbeiten, und du gibst sie erst frei. Das sind zwei Minuten, die Stunden an Arbeit am falschen Code ersparen: die beste Gewohnheit, die man sich als Anfänger aneignen kann.
Wie du deinen eigenen Befehl schreibst
Das ist der Teil, den die typischen Listen-Artikel auslassen, und genau darum geht es. Lege eine Markdown-Datei unter .claude/skills/<name>/SKILL.md ab, die die gewünschten Schritte beschreibt, und sie wird zu /<name>. Claude kann sie auch selbstständig aufrufen, wenn es gerade passt. Persönliche Befehle liegen in ~/.claude/skills/. Checke die projektbezogenen Befehle in Git ein, und dein ganzes Team nutzt denselben Workflow: kein Copy-Paste, kein erneutes Erklären. Ein Befehl ist einfach eine gute Gewohnheit, einmal aufgeschrieben, wo der Agent sie auch wirklich liest.
Die Befehle, die den Agenten steuern, nicht das Tool
Und hier ist das Argument: Die integrierten Befehle sind nur die Grundausstattung. Der Grund, warum dein Agent immer noch zu viel baut, immer noch rät und immer noch „das sollte funktionieren“ über Code sagt, den er nie ausgeführt hat, ist, dass kein einziger der integrierten Befehle sein Verhalten beeinflusst. Das Verhalten wird durch die eigenen Befehle bestimmt, die du ihm gibst, oder durch die, die du nie geschrieben hast.
Genau das ist kitstarter: eine Reihe eigener Befehle, die den Agenten dazu bringen, wie ein sorgfältiger statt wie ein schneller Entwickler zu handeln. Jeder davon ist ein echter Workflow, kein Prompt zum Kopieren und Einfügen. Hier ist, was das Set tut.
| Befehl | Was er tut | Wann du ihn nutzt |
|---|---|---|
/start | Befragt dich mit klärenden Fragen, bis das Ziel wirklich klar ist, schreibt dann einen kurzen Plan sowie eine CLAUDE.md und wartet auf dein Ja. | Ganz am Anfang, bevor auch nur eine einzige Datei geschrieben wird. Erst fragen, dann bauen. |
/step | Setzt den Plan Schritt für Schritt um, mit einem Checkpoint, sobald ein Schritt tatsächlich funktioniert. | Sobald der Plan steht und du Fortschritte willst, die klein, sicher und umkehrbar bleiben. |
/check | Beweist, dass eine Änderung funktioniert, indem er sie tatsächlich ausführt oder öffnet, und berichtet, was er gesehen hat. | Immer dann, wenn du kurz davor bist, „das sollte funktionieren“ als Antwort zu akzeptieren. |
/fix | Findet die wahre Ursache, bevor er etwas ändert, anstatt Patch auf Patch zu häufen. | Wenn etwas kaputt ist und auch der zweite Patch nicht geholfen hat. |
/review | Liest den tatsächlichen Diff mit frischem Blick gegen das ursprüngliche Ziel und markiert, was riskant, unvollständig oder außerhalb des Scopes ist. | Vor dem Commit und bevor du die Arbeit jemandem zeigst. |
/secrets | Findet geleakte API-Schlüssel, offengelegte .env-Dateien und Secrets im Frontend-Code, bevor irgendetwas öffentlich wird. | Vor dem ersten Deployment und vor jedem weiteren danach. |
/ship | Bringt es live: deployt, setzt Produktions-Umgebungsvariablen und liefert eine funktionierende URL zurück. | Wenn die Arbeit überprüft wurde und du eine URL brauchst, die du jemandem schicken kannst. |
/recover | Bringt dich zurück in einen funktionierenden Zustand, wenn etwas völlig schiefgelaufen ist oder Git beängstigend aussieht, ohne es noch schlimmer zu machen. | In dem Moment, in dem du versucht bist, den Ordner zu löschen und von vorn anzufangen. |
/polish | Behebt die Dinge, die einen Screen wie von einer KI erstellt aussehen lassen, an der Wurzel, nicht nur kosmetisch. | Wenn es funktioniert, aber immer noch generiert aussieht. |
Achte darauf, was sie gemeinsam haben. Jeder einzelne davon ist eine Regel für wann man aufhört und was man nicht tun sollte, also genau der Teil, zu dem der Standard-Agent keine Meinung hat. Das ist derselbe Gedanke wie hinter die fünf Archetypen des AI Engineering: Die Kunst liegt nicht darin, mehr Output zu erzeugen, sondern den Agenten auf die Wertfunktion zu verpflichten, die der Moment gerade erfordert.
Integrierte Befehle steuern das Tool. Eigene Befehle steuern den Agenten.
Lerne die integrierten Befehle einmal. Diese Befehle machen dich schneller im Umgang mit Claude Code, und allein /clear, /compact und der Plan-Modus werden deinen Alltag verändern. Aber die Liste der integrierten Befehle ist nicht das, was Leute, die saubere, produktionsreife Arbeit abliefern, von denen unterscheidet, die selbstbewussten Pfusch produzieren. Dieser Unterschied liegt im Verhalten, und Verhalten ist eine Frage eigener Befehle. Du kannst sie selbst schreiben, eine gute Gewohnheit nach der anderen, oder du installierst ein Set, das sie bereits enthält. So oder so: Die Befehle, auf die es ankommt, sind die, die deinen Agenten erst fragen lassen, bevor er baut, und ihn stoppen, wenn er fertig ist.
Häufige Fragen
Was sind die integrierten Claude Code-Befehle? Getippte Tastenkürzel, die mit einem Slash beginnen und die Sitzung steuern: Kontext (/clear, /compact, /context), Gedächtnis (/memory), Modelle und Konfiguration (/model, /config, /output-style) sowie Automatisierung (/hooks). Führe /help aus, um die genaue Liste für deine Version zu sehen.
Wie erstelle ich einen eigenen Slash-Befehl? Erstelle eine Datei unter .claude/skills/<name>/SKILL.md mit den gewünschten Schritten. Sie wird zu /<name>. Persönliche Befehle gehören in ~/.claude/skills/. Checke die projektbezogenen Befehle ein, damit dein Team sie teilen kann.
Was ist der Unterschied zwischen einem Befehl und einem Skill? Zwei Ansichten derselben Sache. Der Skill ist die SKILL.md-Datei mit den Anweisungen. Der Befehl ist die Art, wie du ihn aufrufst, indem du /name eingibst.
Mit welchen Befehlen fängt man am besten an? /clear und /compact für einen sauberen Kontext, der Plan-Modus vor großen Änderungen, und dann eigene Verhaltensbefehle: einer, der vor dem Bauen fragt, einer, der die Ausführung einer Änderung beweist, und einer, der den Diff mit dem Ziel abgleicht.
Installiere die Befehle, die ihn im Zaum halten
kitstarter ist das Set: /start, /step, /check, /fix, /review, /ship und mehr sorgen dafür, dass Claude Code, Codex und Antigravity erst fragen, bevor sie bauen, schlank bleiben und nicht nach KI aussehen.