Claude Code Output Styles in 2026: What I Keep On, What I Deleted

Quick Answer

Output styles change how Claude Code responds, not what it knows. They rewrite the system prompt to set role, tone, and format. As of July 2026 the standalone /output-style command is gone (deprecated in v2.1.73, removed in v2.1.91), so most guides you will find are already stale: you now switch styles from /config or by editing the outputStyle field in a settings file. There are four built-ins (Default, Proactive, Explanatory, Learning), and the one thing that will actually bite you with a custom style is the keep-coding-instructions flag. Here is what I keep on, what I turned off, and the footgun that made Claude forget how to code for an afternoon.

I put off learning output styles because the first three blog posts I read all told me to run a command that no longer exists. That is the real problem with this feature in 2026: it shipped, got popular, then got quietly rewired, and the search results never caught up. So this is the current version, from months of running it, not a rehash of a launch post from last autumn.

The command everyone links to is gone

If you search "claude code output styles" today, the top results, the AI summary, and half of X will tell you to run /output-style to switch, or /output-style:new to scaffold a custom one. Both are dead. The standalone /output-style command was deprecated in v2.1.73 and removed in v2.1.91.

What actually works now:

• To switch: run /config, find Output style, pick from the menu. Your choice is saved to .claude/settings.local.json at the local project level.
• To set it without the menu: edit the outputStyle field directly in a settings file, for example "outputStyle": "Explanatory".

One detail that cost me a confused minute: the output style is read once at session start, because it is part of the system prompt. Changing it mid-session does nothing until you /clear or start a new session. If you flip the style and Claude keeps acting the same, that is why.

What an output style actually changes

An output style is functionally a system prompt swap. It sets Claude's role, its verbosity, and its default response shape for every turn. That is the whole feature, and it is more powerful than it sounds, because "every turn" means you stop re-typing "explain this before you change it" or "keep it terse" fifty times a day.

The mental model I use: if you keep re-prompting for the same voice or format, that belongs in an output style. If you keep re-explaining your project's conventions, that belongs in CLAUDE.md instead. Different files, different jobs.

The built-in styles, ranked by what I keep on

There are four built-ins now. My honest usage:

• Default (roughly 90% of my time). The standard software-engineering system prompt, tuned to write and fix code efficiently. For actual shipping work nothing has beaten it for me.
• Explanatory (the one I reach for on unfamiliar code). It adds educational "Insights" between steps, explaining implementation choices and codebase patterns while still doing the work. When I drop into a repo I did not write, this earns its place for a session or two, then I switch back because the Insights get noisy once I know the terrain.
• Learning (rarely, and deliberately). Collaborative, learn-by-doing: Claude shares Insights and then leaves TODO(human) markers for you to implement small strategic pieces yourself. It is genuinely good for staying sharp on a side project, and genuinely the wrong choice on a deadline. I keep it for evenings, not for work I need finished.
• Proactive (situational, for automation runs). It executes immediately and makes reasonable assumptions instead of pausing on routine decisions. Worth knowing: it is stronger autonomous-execution guidance than auto mode, but it does not change your permission mode, so you still see permission prompts before tools run. I use it for non-coding automation sessions, not for careful refactors.

If you take one thing from this section: try Explanatory for a day on a codebase you do not know. That is the built-in with the best effort-to-payoff ratio.

The custom-style footgun: keep-coding-instructions

Here is the afternoon I lost, so you do not. I wrote a small custom style to make Claude lead every explanation with a diagram. It worked, and then Claude got noticeably worse at the actual coding: sloppier scoping, weaker verification, comments where I did not want them.

The cause is one frontmatter field. A custom output style leaves out Claude Code's built-in software-engineering instructions (how to scope changes, write comments, verify work) unless you explicitly set keep-coding-instructions: true. The default is false. So the moment you write a custom style and are still doing engineering work, you almost always want that flag on. Leave it off only when Claude is not coding at all, like a pure writing assistant or a data explainer.

A custom style is just a Markdown file: frontmatter, then the instructions to append to the system prompt.

---
name: Diagrams first
description: Lead every explanation with a diagram
keep-coding-instructions: true
---

When explaining code, architecture, or data flow, start with a Mermaid
diagram showing the structure, then explain in prose.

The frontmatter fields that exist: name, description, keep-coding-instructions (default false), and force-for-plugin (plugin styles only). That is the whole surface area. The file name becomes the style name unless you set name.

Where the file lives

You can save a custom style at three levels, and precedence goes closest-to-your-work wins:

• User: ~/.claude/output-styles (applies everywhere you work).
• Project: .claude/output-styles (committed with the repo, shared with the team). As of v2.1.178, if nested project directories define the same style name, Claude Code uses the one closest to the working directory.
• Managed policy: .claude/output-styles inside the managed settings directory, for org-wide enforcement.

Same rule as claude-code-statusline-field-log-2026: I keep the personal experiments at the user level and only commit a project style when the whole team actually benefits from it.

When an output style is the wrong tool

Half the "custom output style" ideas I see should be something else. The official comparison is worth internalizing:

• Want Claude to always know your project's conventions and codebase context? That is CLAUDE.md, which adds a user message after the system prompt, not an output style.
• Want a one-off addition for a single invocation? Use --append-system-prompt, which appends without removing anything.
• Want a separately scoped helper with its own prompt, model, and tools? That is a subagent.
• Have a reusable workflow you invoke on demand? That is a skill.

Output styles are specifically for "I want a different role, tone, or default format on every response." Reach for them there, and stop trying to smuggle project facts or one-time instructions into them.

What I actually run

Default, 90% of the time. Explanatory when I open a codebase I do not know. Learning on evenings I want to stay hands-on. One committed project style with keep-coding-instructions: true on a team repo where we wanted diagrams-first reviews. Everything else I tried got deleted, which is the same discipline I apply to three-things-deleted-claude-code-setup-2026: a style you never switch to is just clutter with a menu entry.

If you set up output styles once in 2025 and have not touched them since, the two things worth doing this week: confirm you are switching via /config and not the removed command, and check any custom style you wrote for that keep-coding-instructions line.