Output Styles für Claude Code, in 20 Minuten ein eigener Ton
Wie Du Claude Code mit eigenen Output Styles die Antwort-Persoenlichkeit gibst die Du brauchst. Eine Markdown-Datei pro Style, Frontmatter mit name und description, im Projekt oder global. Inklusive Stolperfallen die ich beim ersten Versuch eingesammelt habe.
Du kennst das Problem. Claude Code antwortet super hilfreich, aber manchmal zu ausfuehrlich, manchmal zu beilaeufig, manchmal mit Pseudo-Optimismus den Du gerade nicht brauchst. Du sitzt im Code-Review-Modus und willst harte Kritik, nicht "this looks great overall". Genau dafür gibt es Output Styles. Eine Markdown-Datei, ein Prompt-Snippet, und Claude Code adoptiert eine andere Persoenlichkeit für die Session oder die ganze Codebase.
1. Verstehen was Output Styles eigentlich sind
Ein Output Style ist eine Markdown-Datei mit YAML-Frontmatter, die Claude Code als zusaetzliches System-Prompt-Fragment lädt. Anders als Skills oder Sub-Agents verändert ein Output Style nicht die Tools die Claude verwendet, sondern nur wie er kommuniziert. Ton, Strenge, Detaillevel, Sprache, Format.
Das heißt, ein Output Style ist gut für "ich will dass Claude knapp antwortet" oder "ich brauch nuechterne Code-Review-Sprache". Schlecht ist er, wenn Du eigentlich Tools veraendern willst, dann brauchst Du einen Skill oder Sub-Agent.
2. Das Verzeichnis anlegen
Es gibt zwei Orte: User-Level in ~/.claude/output-styles/ und Projekt-Level in .claude/output-styles/. User-Level gilt für alle Projekte, Projekt-Level ueberschreibt User-Level wenn ein Name doppelt vorkommt. Plugins können auch Output Styles mitliefern, aber das ist ein anderes Thema.
Für den ersten Test reicht das User-Verzeichnis:
mkdir -p ~/.claude/output-styles
3. Den ersten Style schreiben
Leg eine Datei direct.md an. Frontmatter mit name und description, Body ist der Prompt der ans System-Prompt drangehaengt wird.
---
name: Direct Reviewer
description: Knappe ehrliche Code-Reviews ohne Diplomatie
---
Du antwortest knapp und nuechtern. Keine Floskeln wie "great work" oder
"looks good overall". Wenn Code Probleme hat, sag es direkt im ersten Satz.
Bei Code-Reviews:
- Zuerst die kritischsten Probleme, dann die kleineren
- Konkrete Vorschläge mit Zeilennummer
- Keine zusammenfassenden Lobeshymnen am Ende
- Wenn der Code OK ist, ein Satz reicht
Speichern, fertig. Beim nächsten Start von Claude Code ist der Style verfügbar.
4. Den Style aktivieren
Innerhalb von Claude Code tippst Du /output-style und kriegst die Liste aller verfuegbaren Styles. Default ist immer dabei, dazu was Du selbst angelegt hast. Auswaehlen, fertig. Die Auswahl gilt für die aktive Session.
Wenn Du den Style projektweit als Default haben willst, kannst Du ihn in der settings.json im Projekt fest setzen. Ich nutz das für Codebases wo das ganze Team den gleichen Ton sehen soll.
5. Konkrete Use-Cases die was bringen
Ich hab vier Styles im Dauerbetrieb. Erstens "direct" für Code-Reviews und Debugging, da will ich keine Diplomatie. Zweitens "tutor" wenn ich mir was erklären lass, der Style sagt Claude er soll Annahmen erfragen statt zu raten. Drittens "german-only" der erzwingt Deutsch in der Antwort weil Claude sonst gerne nach 5 Sätzen ins Englische rutscht. Viertens "diff-only" der bei Code-Änderungen nur den Unified-Diff zurueckgibt, keinen Fliesstext drumherum.
Bei "diff-only" hab ich gemerkt: Claude hält sich nicht zu 100 Prozent dran, manchmal kommt doch ein Erklaer-Satz mit. Das ist Prompt-Adherence-Problem, kein Bug von Output Styles. Bei wichtigen Constraints lieber doppelt formulieren ("nur Diff, keine zusätzliche Erklärung, kein Text vor oder nach dem Diff-Block").
6. Style vs. CLAUDE.md vs. Skill, was unterscheidet sich
Das war meine erste Verwirrung. Drei Mechanismen die alle Claudes Verhalten beeinflussen. Hier die kurze Abgrenzung wie ich sie nutze.
CLAUDE.md legst Du für Projekt-spezifisches Wissen ab, "die DB heißt X, die ENV-Var ist Y, das Deploy-Skript heißt Z". Output Style ist für Persoenlichkeit und Format. Skill ist für einen wiederkehrenden Workflow mit Tools, zum Beispiel "Cookie-Banner prüfen mit drei spezifischen Schritten".
Wenn Du nicht sicher bist was Du brauchst: Tonalitaet ändern ist Style, Wissen vermitteln ist CLAUDE.md, Schritt-Folge mit Tools ist Skill.
7. Die Stolperfalle mit Reihenfolge
Output Style wird ans System-Prompt drangehaengt, nach CLAUDE.md. Das heißt, was im Style steht hat tendenziell hoeheres Gewicht als was in der CLAUDE.md steht. Wenn die beiden sich widersprechen, gewinnt oft der Style.
Bei mir war der Fall: CLAUDE.md sagte "antworte immer mit Code-Beispielen wenn möglich", der Style "direct" sagte "halt es so kurz wie möglich". Resultat: keine Code-Beispiele mehr. Ich musste den Style anpassen, weil die Projekt-Regel wichtiger war.
Lehre: bei Konflikten lieber den Style abschwaechen statt die CLAUDE.md aufzubohren. Style ist Session-Layer, CLAUDE.md ist Projekt-Layer.
8. Team-Setup mit Projekt-Styles
Wenn Du im Team arbeitest, gehören wichtige Styles ins Repo unter .claude/output-styles/. Das committest Du, alle haben sie. Beispiel: ein "release-notes" Style der den Ton für Changelog-Einträge festlegt, ein "incident-postmortem" Style für Outage-Reports.
Wichtig dabei: keine Geheimnisse in Output Styles. Die landen im Git, die sieht jeder. Keine API-Keys, keine internen Pfade, keine Kunden-Namen die nicht oeffentlich sein dürfen. Output Styles sind Doku-Artefakte mit System-Prompt-Wirkung, behandel sie wie README-Dateien.
9. Debuggen wenn der Style nicht greift
Drei Sachen die mir passiert sind. Erstens, Style angelegt, Claude Code lief schon, neuer Style wurde nicht angezeigt. Lösung: Claude Code neu starten oder einmal /output-style aufrufen, manchmal triggert das ein Reload. Zweitens, Style ist angezeigt aber nicht aktiv, ich hatte einfach nicht ausgewählt. /output-style zeigt den aktuell aktiven Style mit Markierung. Drittens, Style ist aktiv aber Claude folgt ihm nicht. Da hilft nur, den Prompt im Style klarer und imperativer zu formulieren. "Antworte knapp" funktioniert schlechter als "Maximal drei Sätze pro Antwort, keine einleitenden Floskeln".
10. Was als nächstes
Wenn Output Styles für Dich klick gemacht haben, schau Dir Skills für Claude Code an, weil Du dann den nächsten Layer drauf hast: Workflows die nicht nur Ton sondern auch Tool-Sequenzen festlegen. Oder lies Eigene Slash-Commands für Claude Code wenn Du den Style auf Aufruf-Basis kombinieren willst mit konkreten Befehlen.
Für den Lesson-Layer passt Hooks und Skills als Konzept-Refresher, das schaerft die Abgrenzung wann was zu nutzen ist.
Source
Output Styles offiziell: https://code.claude.com/docs/en/output-styles