For operators who read AI output all day and want less of it.
Claude Output Styles:
Make Claude Answer Like You Think
Most people fix waffle by asking for less waffle, every single time. An output style fixes it once, at the system prompt, for every session on the machine. This guide covers what they are, the layer they belong in, the six mistakes that make them useless, and a ten-minute build.
One file
Markdown with frontmatter
Every session
Loads into the system prompt
Every surface
CLI, desktop, Cowork
Foundation 01
Asking for Shorter Answers Does Not Work
You have told it to be concise. It was, for three exchanges. The instruction lived in the conversation and the conversation moved on.
Ask a model to be concise and it will be concise for about three exchanges. Then it drifts back. Not because it ignored you, but because the instruction lived in the conversation, and the conversation moved on. Meanwhile the default shape of the answer is baked into the system prompt, where it wins every time.
The four tells of unshaped output
The preamble
Two sentences restating what you just asked before the answer starts. You already know what you asked.
The ceremony
The same four headings on a two-line fix as on a week of work. Structure that does not scale to the job is noise.
The buried specific
The file path, the number, the command you actually need, sitting under three paragraphs of context you did not ask for.
The closing pep talk
A summary of the summary, then an offer to help further. Nothing in it changes what you do next.
The useful reframe. If you have already written the rule down somewhere and the output still ignores it, you do not have a missing rule. You have a compliance problem. Writing the rule a fourth time in a fourth file will not fix it. Moving it to a layer that loads before the conversation starts will.
Foundation 02
What an Output Style Actually Is
A markdown file with frontmatter that gets folded into the system prompt when a session opens. No plugin, no build step, no service.
An output style is a markdown file with frontmatter. Claude Code reads it when a session opens and folds it into the system prompt. That is the whole mechanism. No plugin, no build step, no service.
Where it lives
~/.claude/output-styles/<name>.md
User level, so every project on the machine picks it up. A project-level copy scopes it to one repo.
When it loads
Session start
It goes into the system prompt. Edits do not apply mid-session. Clear the session or open a new one.
What it replaces
The default response instructions
A custom style drops the built-in engineering guidance unless you keep it explicitly.
The line that matters most. keep-coding-instructions: true keeps the built-in engineering behaviour and changes only how Claude communicates. Leave it out and you have quietly swapped a capable coding assistant for a chattier general one. Check that key exists in your version before you rely on it.
--- name: Brief description: Decision-first answers. Short by default. keep-coding-instructions: true --- Answer first. The opening line resolves the question. Bullets and tables over paragraphs. Keep file paths, commands and numbers in the answer. No preamble. No closing encouragement.
Foundation 03
Style, Rules, Skills: Who Owns What
Three layers can change what comes back. Stack the same instruction into all three and none of it holds. Give each one job.
Three layers can all change what comes back, which is exactly why people stack the same instruction into all three and then wonder why none of it holds. Give each layer one job and never let the jobs overlap.
Output style
How an answer is built. Order, length, what leads, what gets cut. One file, loaded at session start.
CLAUDE.md and rules
What is true about this project and how it should sound. Stack, commands, conventions, banned words, spelling.
Skills
A tested method that fires on a trigger. Not how the answer looks, but what steps run before there is an answer.
Would this rule still be true on a completely different project?
Yes, and it is about shape. Output style. "Lead with the answer" is true everywhere.
Yes, and it is about words. Voice rules. "Australian spelling, no em dashes" is true everywhere too, but it belongs with the rest of the brand voice, not mixed into structure.
No, it is specific to this repo. CLAUDE.md. "Dev port 8081" helps nobody on another project.
The drift trap. Copies of the same rule in three files do not reinforce each other. They rot at different speeds. Someone tightens one, misses the others, and now the model is reading three slightly different versions of your standard. One rule, one home, every time.
Enjoying the guide?
Enter your details to unlock the remaining insights. We'll also send you the complete guide as a reference.
The Build
The Anatomy of One That Works
Forty lines is plenty. Five rules carry almost all of the result, and the first one is the reason most styles fail.
The best output styles are short. Forty lines is plenty. The failure mode is not too little instruction, it is a wall of instruction that competes with itself. Five rules carry almost all of the result.
Describe purpose, not the person
Write why they are reading, not what they know. "They are reading this to decide what happens next" ages well. "They are a non-technical founder" is a guess, and when it is wrong it strips out the file paths they needed.
Scale the closing message to the job
One or two lines for a small fix. Sections only when the work earns them. A fixed block on every response is the ceremony you were trying to remove.
Say that a missing section is correct
Without this line, headings get padded to look complete. State plainly that no open decision means no decision section.
Cap every response, not just the closing one
A number is enforceable in a way that "be concise" is not. Scope it to the whole response. A cap that only covers the sign-off leaves every explanation unbounded, and explanations are most of what you read. Exclude code and tool output, name the escapes, and send the overflow to a linked file.
Keep the specifics in the answer
Paths, commands, numbers and dates are the actionable part. Sending them to a technical appendix at the bottom is how a style makes output shorter and less useful at the same time.
--- name: Brief description: Decision-first answers. Short by default, detail on request. keep-coding-instructions: true --- They read answers to decide what happens next, not to learn how something works. Give the decision, then the evidence, then stop. This applies to every kind of conversation. The shape never changes by topic. Only the content does. Length Hard cap: 150 words per response. The cap does not count code blocks, command blocks, file paths or tool output. Those are the useful part, never the padding. Three reasons to go over, and only three: - They asked for depth. "Explain properly", "walk me through it". - The honest answer genuinely branches, and giving one would be wrong. - The length IS the deliverable: a draft, a doc, copy they asked for. Otherwise the detail goes in a file and you link it. Every response - Answer first. The opening line resolves the question. - Bullets and tables over paragraphs. - Keep file paths, commands and numbers in the answer. Never - Preamble. Restating the question, or announcing what you will do. - Metadata tables. Line numbers, file sizes, unless asked. - Numbered plans with sub-explanations. One line per step. - Self-restating bullets. A bullet whose child repeats it. - Closing encouragement. "Hope that helps", a summary of the summary. - Hedging filler. "It's worth noting", "importantly". - Options you are not recommending. Recommend, do not survey. While working Stay quiet. Speak up mid-task only when something material changed: a blocker, a decision needed, a surprise cost. Closing message Small job: one or two lines. No headings. Substantial job: only the sections that apply. - Done: up to 4 bullets. Outcome, not mechanics. - Decide: one sentence per open decision, with a recommendation. - Next: one action, or "Nothing, it's ready." - Watch: only if there is a real risk, cost or limit. A missing section is correct output. Never pad to fill a heading.
The Build
Six Mistakes That Make It Useless
Every one of these produces a file that looks right, installs cleanly, and changes nothing.
01. Adding ceremony to remove waffle
Five named sections and a mandatory summary block on every single response.
One rule that scales the closing message to the size of the job, and permission to skip sections entirely.
02. Capping only the closing message
A word limit that sits under a "closing message" heading, leaving the body of every answer unbounded.
Cap the whole response. Sign-offs are a small share of what you read. Explanations are the rest, and a closing-only cap never touches them. Measured on the same three prompts, a closing-only cap cut length by 37 percent. Moving the cap to every response took it to 50.
03. Writing a persona instead of a structure
"You are working with a non-technical founder who does not want implementation detail."
"They read this to decide what happens next." Purpose is stable. Assumed skill level is a guess that goes stale.
04. Hard-coding a voice violation into the template
A worked example containing an em dash, US spelling, or a banned word. It gets echoed into every answer from then on.
Run the template through your own voice rules before you install it. A style file is content, and it ships on every answer.
05. Duplicating rules you already wrote
Copying the whole comms standard out of CLAUDE.md into the style, so both drift apart over the next month.
Style owns shape. Rules own voice and facts. If a line already has a home, link the two in your head and leave it there.
06. Installing it and never measuring
Assuming it worked because the file exists in the right folder, then deciding by feel that it made no difference.
Run the same prompt twice, once with the style and once with it switched off, and count the words. Feel is a bad instrument here, because the change is real but gradual and you have no memory of the counterfactual.
Walkthrough
Build Yours in Ten Minutes
Four steps. Three of them are quick. The fourth is the one everybody skips and it is the one that decides whether any of this worked.
Four steps. The first three take about five minutes. The fourth is the one that separates a style that works from a file sitting in a folder doing nothing.
Write the file
Create the folder if it does not exist, then save your style beside it. The filename is yours. The name in the frontmatter is what you will select later.
Check the frontmatter key is real
Versions move. Before you depend on keep-coding-instructions, confirm your build parses it rather than trusting a docs page that may describe a different release.
Switch it on
Set outputStyle in settings.json, or pick it from the in-session style picker. On recent builds the old config subcommand is gone, so editing settings directly is the reliable path.
Prove it loaded, then measure it
This is the step everyone skips. First ask a fresh session to repeat a rule only your style contains. Then run the same prompt with the style on and off and count the words. Judging by feel does not work: you have no memory of the answer you would otherwise have got.
mkdir -p ~/.claude/output-styles $EDITOR ~/.claude/output-styles/brief.md
strings -a "$(readlink -f "$(which claude)")" \ | grep -c "keep-coding-instructions"
{ "outputStyle": "Brief" }
claude -p "Which output style is active, and what is \ its word cap? One line."
P="Check whether COS.yaml exists here and tell me what to do next." # style on claude -p "$P" | wc -w # same prompt, style off claude --settings '{"outputStyle":"default"}' -p "$P" | wc -w
Word counts, same prompts, same directory. A cap scoped to the closing message alone gave about a third back. Moving the same cap to every response roughly halved the output and pulled all three prompts to within fifteen words of each other, which is the cap actually binding rather than the model being agreeable.
Expect nothing to change immediately. The style loads at session start, so the session you were in when you installed it keeps the old behaviour. Clear it or open a new one. Judging the change from the session that predates it will always show you the old behaviour.
Coverage
Where It Applies, and Where It Does Not
One user-level file covers more than people expect. The split that matters is local against cloud.
One user-level file covers more ground than people expect, because the surfaces you think of as separate products are mostly the same program reading the same folder. The split that matters is local against cloud.
Scope it down when you need to
A style in the project's own config folder applies to that repo only. Useful when one client wants a different reporting shape and the rest of your work should not inherit it.
Decide the blast radius on purpose
User level reaches every project you touch, including any internal agents you run. That is usually the point, but it should be a decision rather than something you discover a week later.
YouYouwillwillreadreadtenstensofofthousandsthousandsofofAIAIanswersanswersthisthisyear.year.SpendingSpendingtwentytwentyminutesminutesononthetheshapeshapeofofeveryeveryoneoneofofthemthemisisthethehighest-returnhighest-returnediteditavailableavailabletotoyou.you.WriteWritethethefile.file.ProveProveititloaded.loaded.ThenThenstopstopaskingaskingforforshortershorteranswers.answers.
Jump back to a section
Read next