Claude Code output styles change how the terminal agent phrases its answers, and they are the quickest fix for technically dense responses from smart models like Opus 5. You drop a markdown file into .Claude/output-styles, run /config, and pick a style. Five styles ship by default, and custom ones persist across sessions.
What Claude Code output styles are and why they matter
Claude Code output styles are markdown instruction files that change how Anthropic terminal coding agent writes its responses, and they load at the start of every session. Claude Code ships five built-in styles, and any custom style you add to the .Claude/output-styles folder appears in the same selector.
The problem they solve showed up as models got stronger. The video's author, an ex-Amazon AI engineer, found that frontier models like Opus 5 completed the coding work but wrapped explanations in jargon average readers could not parse. Developer Matt Pocock publicly hit the same wall: he used Opus 5 on an application and could not follow what the model was saying.
Anthropic engineer Lydia Hallie published one early example, an 'explain like I'm five' output style that rewrites answers in plain language. Her post showed the whole mechanism: put your instructions in a markdown file, drop it in the folder, run /config, and select it. No model switching is required.
The five built-in output styles and when to pick each
Five styles ship with Claude Code, and each suits a different working mode. You switch between them with /config, and the choice applies from the next session onward. Pick based on whether you want speed, teaching, or autonomous execution.
| Style | What it does | Best when |
|---|---|---|
| Default | Efficient task completion, concise replies | Everyday coding work |
| Proactive | Executes immediately, asks fewer questions | Overnight runs after planning is done |
| Concise | Results over narration | You want answers fast and short |
| Explanatory | Explains implementation choices | Learning a codebase's patterns |
| Learning | Teaches as it goes | You are learning to code |
The video author's own pattern: explanatory while studying a codebase, proactive for unattended execution after planning, concise to move quickly, and a team style when colleagues share the session setup.
How to create a custom output style
You create a custom output style by having Claude generate one for you and saving it where the agent expects it. The whole loop takes minutes and requires no code. Custom styles persist globally or per project, depending on where you put the file.
- Take an output you dislike and ask Claude for three or four variations of the same answer in different registers.
- Pick the variation you prefer and ask Claude to turn it into an output style file.
- Save the file in .Claude/output-styles, either in your project folder or your user directory.
- Run /config, select Output Style, and choose your new style.
- Restart the session if needed; the style then loads by default every time.
The author's first custom style, called 'map first', opens every explanation with a drawn map of the relevant architecture so readers always know which part of the application the agent is describing. Because the file lives in a shared project folder (his is named 'Eric OS'), his whole team inherits the style.
Output style versus skill: the loading difference
An output style loads at session start; a skill only fires when triggered. That is the distinction the video stresses. A style governs every reply from the moment Claude Code boots, while a skill like Matt Pocock's 'wait, what' skill runs only when you invoke it, asking the agent to say the same thing again in plain English.
The two compose. You can write an output style that references or triggers the skill's rules on every turn, so the plain-English discipline applies to the whole conversation instead of only when you remember to invoke it. If you want a guaranteed register for a whole team, the style is the right container; if you want an occasional re-explanation, the skill is lighter weight.
Why Simplified Technical English makes a good style rulebook
Simplified Technical English (ASD-STE100) is a controlled-language standard created in the 1980s for aircraft maintenance manuals, where a misunderstood word could cause a repair error. It works well as the backbone of a readability output style because the rules are already battle-tested for safety-critical clarity.
Its core rules map directly onto model output problems:
- One word, one meaning: no double meanings to misread.
- No synonyms: choose one approved word (say, 'start') and never alternate with 'begin' or 'launch'.
- Short sentences: instructions capped at 20 words, one action per sentence.
- No slang or vague language, which also makes text cheaper to translate and produces fewer errors.
The standard is maintained by the Aerospace, Security and Defence Industries Association of Europe, and its official ASD-STE100 specification page documents the current rules. Matt Pocock embeds it in his 'wait, what' skill so Claude re-explanations follow the same register, and the video author borrows the same rules in his team styles.
Three team output styles for three kinds of reader
Different roles need different registers, so the author built one output style per team profile rather than one for everyone. Each style assumes a different technical background and changes what the agent explains and what it leaves out.
- Technical project manager: knows APIs, frontend, backend, and databases but does not write code. The style cuts to the brief, gives one decision per trade-off with a recommendation, and borrows the plain-English rules above.
- Technical translator: near-zero technical background, such as marketing or data-entry colleagues. The style explains project context and the team's shared notes without assuming any engineering vocabulary.
- Engineer: knows everything already, so the style skips hand-holding, uses short words and short paragraphs, and compresses a thousand-word answer into a scannable summary.
Sharing the files through a common project folder means every teammate gets the right register automatically. Once a style is selected, even a plain 'hi' gets answered in that style, and the author reports the setup also saves tokens because answers stop narrating at length.
FAQ
- Where do custom output style files live? Put the markdown file in a .Claude/output-styles folder, either in your project or your user directory. Run /config, choose Output Style, and pick it; it loads at the start of each session from then on.
- Do output styles change which model is used? No. A style only changes how responses are written, not the model doing the work. That is why they work as a readability fix when a strong model's explanations get dense.
- Can I combine an output style with a skill? Yes. A style loads every session while a skill fires on trigger, so you can write a style that applies a skill's rules, such as Simplified Technical English, to every reply.
- Which built-in style should I use for unattended work? The video author uses proactive mode after planning is complete, because the agent executes immediately and asks fewer questions. Use concise when you are present and just want shorter answers.
- Who published the popular 'explain like I'm five' style? Lydia Hallie, an Anthropic engineer, shared her ELI5 output style configuration publicly, and it works by placing her instructions file in the output-styles folder and selecting it via /config.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits