Tippst du denselben Prompt zum fünften Mal? Bau dir einen Slash-Command

Du arbeitest mit Claude Code seit ein paar Wochen, und dir fällt etwas auf: bestimmte Prompts tippst du immer wieder. „Bau mir eine neue Komponente mit dem üblichen Setup — TypeScript, Tailwind, Test-Datei daneben." Drei Mal. Fünf Mal. „Triage mir kurz die offenen Issues auf dem aktuellen Branch." Wieder und wieder.

Sobald du das beim dritten Mal tippst, ist es Zeit für einen eigenen Slash-Command — einen Befehl wie /komponente-neu oder /triage, den du im Claude-Code-Prompt einmal eintippst und der den kompletten Workflow auslöst, ohne dass du den Prompt jedes Mal frei formulieren musst.

Im letzten Teil dieser Series ging's um Hooks — Verhalten erzwingen, wo Memory nur dokumentiert. Heute geht's um den nächsten Schritt: ganze Workflows in einer einzigen Datei kapseln, sodass aus einer Wiederholungs-Sequenz ein einziger Befehl wird.

Was ein Skill eigentlich ist

Ein Skill ist nichts weiter als eine Markdown-Datei mit ein paar Zeilen Frontmatter und den eigentlichen Anweisungen darunter. Beispiel — der einfachste sinnvolle Skill, den du dir vorstellen kannst:

---
description: Erstellt eine neue React-Komponente mit Test-Datei nach Projekt-Konvention
---

Wenn der User "/komponente-neu <name>" tippt:

1. Erstelle `app/components/<name>.tsx` mit TypeScript-Komponenten-Skeleton (default export, Props-Interface)
2. Erstelle `app/components/__tests__/<name>.test.tsx` mit einer leeren Vitest-Test-Datei
3. Sag dem User die zwei erstellten Pfade

Das ist der ganze Skill. Speicher ihn als ~/.claude/skills/komponente-neu/SKILL.md (oder im Repo unter .claude/skills/komponente-neu/SKILL.md). Beim nächsten Claude-Code-Start ist /komponente-neu als Befehl verfügbar. Du tippst /komponente-neu Avatar, Claude erstellt die zwei Dateien, fertig.

Acht Zeilen Markdown, keine Plugin-API, kein Build-Step — nur eine Datei, die im richtigen Ordner liegt.

Skill, Hook oder Memory — wann was?

Drei Mechanismen für drei verschiedene Probleme:

Memory ist Wissen — was du Claude beibringst, damit er nicht jedes Mal von Null anfängt. Hat keine konkreten Schritte, ist eher passiv: „in diesem Projekt nutzen wir Drizzle". Memory wirkt, wenn der Context geladen wird.

Hook ist Erzwingung — etwas, das passieren muss, bevor eine Aktion durchgeht. Aktiv und verhandlungsfeindlich: „kein Commit ohne Type-Check". Hooks wirken auf Tool-Calls.

Skill ist Workflow — eine Abfolge von Schritten, die du als Einheit aufrufen willst. „Komponente erstellen heißt: TSX-Datei plus Test-Datei plus Story-Datei." Skills wirken, wenn du den Slash-Command tippst.

Faustregel: wenn du dich dabei ertappst, dieselbe Sequenz von Schritten zu erklären, ist's ein Skill. Wenn du dieselbe Anweisung wiederholst, ist's Memory. Wenn du verhindern willst, dass etwas passiert, ist's ein Hook.

Wann Skills wirklich Zeit sparen

Skills lohnen sich besonders bei drei Sorten Workflows:

1. Strukturierte Erstellungen. Neue Komponente, neue Migration, neuer Blogpost — Sachen, wo das Setup immer gleich ist und nur der Inhalt variiert. Der Skill nimmt dir den Setup-Aufwand ab, du machst nur den kreativen Teil.

2. Komplexe Wiederhol-Triage. „Schau mir die offenen GitHub-Issues an, gruppiere sie nach Severity, und schlag die drei wichtigsten vor." Der Prompt ist lang, das Ergebnis ähnlich strukturiert. Im Skill kapselst du die Anweisungen einmal, der Befehl bleibt kurz.

3. Pre-Release-Checklists. „Vor dem Release: lint, typecheck, build, prüf den Changelog, schau ob die Migration-Files konsistent sind." Sieben Schritte. Dauert manuell jedes Mal lang. Skill /release-check macht's in einem Aufruf.

In allen drei Fällen ist der Schritt-Charakter starr — keine wirkliche Verzweigung, keine Iteration. Genau da, wo Wiederholung Drift produziert (man vergisst Schritt 4 oder macht ihn anders), greift der Skill.

Wann ein Skill die falsche Wahl ist

Drei Anti-Patterns, die wir bei uns selbst und in fremden Projekten immer wieder gesehen haben:

1. Skill, der nur einen Memory-Eintrag verkleidet. „Mein Skill /lade-richtlinien lädt das Pixzl-Brand-Guideline-Memory in den Context." Nein — pack die Brand-Guidelines in CLAUDE.md oder in einen Memory-Eintrag, dann ist es immer da, ohne Slash-Command. Skills sind für Aktionen, nicht für Wissen.

2. Skill, der bei jedem Aufruf signifikant anders ist. „Mach was, das das Projekt jetzt braucht" ist kein Skill — das ist normales Coding. Skills funktionieren, wenn die Schrittfolge deterministisch ist. Wenn jeder Aufruf eine andere Schrittfolge hat, hast du keinen Skill, du hast einfach einen Job.

3. Skill, der ungereviewt automatisch zu weit geht. Wir haben gesehen, dass Skills mit git commit oder git push enden — was den Review-Schritt überspringt. Ein Skill sollte dort enden, wo der Output reviewbar wird. Alles, was danach passiert, ist menschliche Verantwortung. Ein guter /komponente-neu-Skill erstellt die Dateien — committed werden sie aber von dir, nicht vom Skill.

Ein paar nützliche Frontmatter-Felder

Im Frontmatter eines Skills gibt es ein paar Felder, die du am Anfang nicht brauchst, später aber wahrscheinlich willst:

• description — der Satz, an dem Claude den Skill auswählt, wenn du /<name> nicht explizit tippst, sondern eine ähnliche Frage stellst. Schreib hier präzise, wann der Skill greift („wenn der User eine neue React-Komponente erstellen will, mit Test-Datei"). Vage Beschreibungen führen dazu, dass der Skill nie aufgerufen wird.

• allowed-tools — eine Liste der Tools, die der Skill nutzen darf. Nützlich, um den Skill auf einen engeren Permission-Scope zu beschränken (z.B. nur Read, Edit, Write, kein Bash).

• model — wenn du den Skill auf einem bestimmten Modell laufen lassen willst. Standard ist das aktuelle Session-Modell. Sinnvoll vor allem für mechanische Workflows, die ohne tiefes Reasoning auskommen — dann reicht Haiku, der Skill läuft schneller und günstiger als auf Opus.

Alle drei optional. Der Skill funktioniert auch mit nur einem description-Feld plus Markdown-Body.

Wo Skills liegen — und was committed wird

Persönliche Skills liegen unter ~/.claude/skills/<name>/SKILL.md. Die siehst nur du, niemand im Team. Gut für deine eigenen Routinen.

Projekt-Skills liegen im Repo unter .claude/skills/<name>/SKILL.md. Werden committed. Jeder, der das Repo cloned, hat sie automatisch verfügbar. Gut für Team-Workflows.

Heuristik für die Entscheidung:

• Ist der Workflow projekt-spezifisch (kennt Projekt-Pfade, -Konventionen)? → Repo
• Ist der Workflow generisch (würde in jedem React-Projekt funktionieren)? → persönlich, im Home-Verzeichnis
• Sind mehrere Devs an dem Skill-Output interessiert? → Repo
• Ist es nur eine persönliche Routine? → persönlich

Wenn dein Repo am Ende mehr als fünf Skills hat, von denen vier nur einer Person etwas bedeuten, lagere die paar in den persönlichen Bereich aus. Sonst wird die Slash-Command-Liste unübersichtlich, und das Team scrollt jedes Mal an den eigenen Skills vorbei, die es wirklich braucht.

Was du diese Woche probieren kannst

Wenn du noch nie einen Skill gebaut hast, such dir den Workflow raus, den du am häufigsten tippst, und versuch ihn als Skill zu fassen. Aus unserer eigenen Erfahrung lässt sich das bei den meisten Devs auf eine von drei Sachen runterbrechen — ein neuer Blogpost oder eine neue Doku-Seite, eine neue Komponente oder ein neues Modul, oder die immer gleiche Release-Vorbereitung. Eines davon hast auch du.

Schreib dafür eine Skill-Datei mit drei bis fünf Schritten, speicher sie und probier sie noch in derselben Session aus. Wenn der erste Aufruf nicht das macht, was du willst, justier den Markdown-Body und ruf ihn nochmal auf. Nach zwei, drei Iterationen hast du etwas, das stabil läuft — und ab da ersetzt der Slash-Command das ständige Wiedertippen.

Anders als bei vielen Tooling-Investments amortisiert sich ein Skill nicht erst nach drei Monaten. Schon der erste echte Aufruf spart dir die Zeit, die du gerade in die fünfzehn Minuten Skill-Schreiben gesteckt hast.

Im nächsten Teil

Skills kapseln Workflows in deinem Hauptkontext. Manchmal willst du einen Workflow aber außerhalb deines Kontexts — eine längere Recherche, ein riskanter Refactor, eine Multi-Datei-Suche, deren Output dich nicht interessiert, nur das Ergebnis. Da kommen Sub-Agents ins Spiel: ein separater Agent mit eigenem Kontext, der parallel oder im Hintergrund arbeitet und nur das Ergebnis zurückgibt. Im nächsten Teil zeige ich, wann das wirklich Zeit spart und wann der Spawn-Overhead nicht zur Aufgabe passt.

Falls du gerade neu in die Series einsteigst — der erste Teil zum Account-Setup liegt unter „So nutzt du mehrere Claude Code Accounts gleichzeitig", Teil 2 zum Memory-Setup unter „Claude Code merkt sich nichts? Doch — du musst ihm nur sagen wo", und Teil 3 zu Hooks unter „Claude Code soll keinen Müll committen? Bau ihm einen Hook".