Output Style Generator

What an output style is

An output style is a saved set of instructions that changes how Claude Code responds without changing what it can do. It is a markdown file with a little frontmatter - a name and a description - followed by the rules you want applied to every response. Once saved, you switch to it and every answer follows those rules: the tone, the length, the formatting, the habits. Think of it as a persistent system layer that rides on top of the model, so you are not re-typing 'be terse and skip the preamble' into every session. The generator above turns your choices into that file for you.

Output styles are about voice and shape, not capability. They do not give Claude Code new tools or restrict what it is allowed to do - that is what permissions and allowed-tools are for. They shape the delivery: how much it says, how it says it, and what habits it keeps.

The building blocks the generator controls

• Tone - the register of the voice, from terse and direct to warm and encouraging to a strict senior reviewer who names risks instead of rubber-stamping.
• Verbosity - how much Claude says. Minimal answers the question and stops; thorough includes the context and the reasoning; balanced sits in between.
• Format - whether responses lean on prose, bulleted lists, or headings and sections. The right choice depends on whether you scan or read.
• Habits - small persistent behaviors: skip the preamble, explain the why on non-obvious decisions, ask before risky actions, comment code only where the intent is not obvious.

Where the file lives and how you switch to it

Personal output styles live in ~/.claude/output-styles/ as individual markdown files, one per style. A style saved there is available across all your projects. Once the file exists, you activate it inside Claude Code and it stays active for the session. Because it is just a file, you can keep several - one for quick terse work, one for teaching mode, one for strict reviews - and switch between them as the task changes. Editing a style is editing its markdown; the new rules apply the next time you use it.

Why the frontmatter name and description matter

The name in the frontmatter is how the style is identified when you pick it, so keep it short, lowercase, and descriptive of the behavior - concise-reviewer, teaching-mode, terse. The description is a one-line reminder of what the style does, which is genuinely useful once you have a handful of them and cannot remember which is which. The generator slugifies your name automatically so you never end up with an invalid identifier, and it writes a description from your tone choice.

Writing rules that actually stick

1. Be concrete. 'Be terse' is weaker than 'answer the question and stop; do not add background the user did not ask for'. The generator writes the concrete version for you.
2. Prefer positive instructions to vague vibes. 'Explain the why on non-obvious decisions' beats 'be thoughtful'.
3. Keep the list short. A style with five sharp rules is followed more reliably than one with twenty overlapping ones.
4. Match the style to the work. A terse minimal style is great for fast iteration and terrible for onboarding someone new to a codebase.
5. Do not smuggle capability limits into a style. If you want to forbid a tool, do it in permissions, not in prose the model can reinterpret.
6. Test it on a real task and tune. Read a couple of real responses, notice what still annoys you, and add one rule at a time.

Output styles vs CLAUDE.md vs a slash command

These three are easy to confuse. CLAUDE.md carries project facts and conventions - the stack, the rules, the things Claude needs to know to work in this repo. A slash command is a reusable prompt you invoke on demand for a specific task. An output style is a persistent way of responding that stays on across every task until you switch it. Use CLAUDE.md for what the project is, slash commands for repeated jobs, and output styles for how you want Claude to talk while it does all of it. They compose - a strict output style and a good CLAUDE.md and a /review command all work together.

Styles worth keeping around

Most people end up with a small set. A terse minimal style for when they know what they want and just need the answer. A teaching style that explains reasoning for when they are learning an unfamiliar area. A strict-reviewer style for pull request work, where naming risks and tradeoffs matters more than agreeableness. Build the one that fixes your most common annoyance first - usually that is either too much preamble or not enough of the reasoning behind a change - and add others as the need shows up.