Output styles

What they do

Output styles modify the system prompt. They change how Claude communicates, not what it knows. Reach for one when you find yourself re-prompting for the same voice every turn.

If you are correcting what Claude does, you want CLAUDE.md or a rule. If you are correcting how it talks about what it did, you want an output style.

Built-ins

Setting one

/config → Output style. This writes outputStyle into .claude/settings.local.json. Or set it directly:

{
  "outputStyle": "Concise"
}

Because it is part of the system prompt, a change takes effect after /clear or in a new session, not mid-conversation.

Changed recently: the standalone /output-style command was removed in v2.1.91. Use /config.

Custom styles

A markdown file in ~/.claude/output-styles/ (personal) or .claude/output-styles/ (project):

---
name: Tables and tradeoffs
description: Structured comparisons, minimal narration
keep-coding-instructions: true
---

When presenting more than two options, use a markdown table with an explicit
tradeoff column.

Never narrate what you are about to do. Do it, then state what changed.

For design and architecture discussions, describe the approach conceptually.
Do not include code snippets unless they are explicitly requested.

When you are uncertain, say so in one sentence and state what would resolve it.
Do not hedge across a paragraph.

keep-coding-instructions is the field that matters. It defaults to false, meaning your custom style strips out Claude Code’s built-in engineering instructions: how it scopes changes, verifies work, handles edits. Set it to true unless you are deliberately repurposing Claude Code as a non-coding assistant.

Two more that earn their keep

A review posture, for sessions where you want findings rather than fixes:

---
name: Review mode
description: Findings only, no patches, ranked by severity
keep-coding-instructions: true
---

Report findings; do not apply them. If you are certain of a fix, describe it in
one sentence rather than writing the diff.

Every finding carries a `file:line`, a severity of Critical / Warning / Nit, and
a one-line failure scenario: the concrete input or state that makes it go wrong.

Do not report style preferences unless they are in `.claude/rules/`. Do not open
with a summary of what the code does; I wrote it.

If you find nothing, say "no findings" and stop.

A teaching posture, for onboarding someone into an unfamiliar codebase:

---
name: Walkthrough
description: Explains the surrounding system before touching it
keep-coding-instructions: true
---

Before the first edit in a file you have not touched this session, explain in
three sentences what the file is responsible for and what calls it.

After any change, state what would break if the change were wrong, and which
test would catch it.

Prefer naming the pattern the codebase already uses over inventing a new one,
and say which existing file you copied the pattern from.

Limits

• Output styles apply to the main conversation only. A subagent runs its own system prompt, so styles do not change subagent behaviour. Forks are the exception, since they inherit the parent’s prompt.
• Explanatory and Learning increase output tokens by design. Concise reduces them.

Output style vs the alternatives