All right, so I've been spending a lot of time reviewing frontier models lately, and here's the thing: the models are getting incredibly smart. They can do the work, no problem. But there's a big issue that keeps cropping up. As the intelligence goes up, the clarity of the output seems to go down. Yes, the model can solve the problem, but when it generates a response, it's often a wall of jargon that's just harder for an average person to parse.
The other day, I asked Claude to explain a bug to me. What I got back was a dense block of text full of technical terms that I had to re-read three times. And it's not just me. Matt Pocock recently tried out Claude Opus 5 while building an application and found himself completely lost. He had no idea what the model was saying, and he even shared a screenshot of the AI-generated text that had him stumped.
So, what's the fix? Do we need a different model? Not according to an Anthropic engineer who shared a much simpler solution. Instead of swapping models, we can change the style of the output. You can make the model communicate in a way that's actually clear for you. That's exactly what we're going to cover: how to customize your Claude Code output styles so the explanations you get are actually easy to understand.
How an Anthropic Engineer Configures Her Output Style
The solution comes from Lindia, an AI engineer at Anthropic. She shared her approach on X, and it's surprisingly straightforward. You don't need to be a prompt engineering wizard to make this work.
Her method is simple. You drop your instructions for the output style inside your Claude Code project, specifically into a .claude/output-styles folder. Then, you just run the /config command, and you can select that output style to use. That's it.
She shared one she created called "Explain to me like I'm 5." Inside that output style file is a set of instructions that tells Claude to simplify everything down to a level a five-year-old could grasp. You can literally take a screenshot of her configuration, feed it to Claude, and ask it to install that same output style on your machine. It works.
But you don't even have to go that far. Claude Code ships with a set of built-in output styles that you can start using right now.
The Default Output Styles Already in Claude Code
If you open up Claude Code and type /config and hit enter, then navigate to "output style," you'll see several options that come out of the box. Each one changes how Claude communicates with you.
The default style has Claude complete coding tasks efficiently and provide concise responses. It's the standard, no-frills mode.
Then there's the proactive option. This one is for when you want less chatter and more action. Claude will start executing immediately instead of asking you a dozen clarifying questions. Less interruption, more doing.
The concise option is for when you just want results. If you don't care about the narration or the thought process and just want the output, this is the mode for you. It cuts the fluff.
The explanatory style is the opposite. If you want Claude to walk you through its implementation choices, the patterns it's using, and the reasoning behind its decisions, this is the one to pick.
Finally, there's a teaching style. If your goal is to learn how to code, not just get code, this output style is designed to educate you as it works.
These are solid templates, but they might not fit your specific needs. What if you want something truly custom?
How to Generate Your Own Custom Output Style
Here's the workflow I use. Let's say Claude gives you an output and you're not satisfied. It's too wordy, too vague, or just too complex. You don't have to settle for that.
First, ask Claude to generate three or four different variations of that same output. Have it rephrase the response in different styles. Then, you pick the variation you like best. Once you've chosen, ask Claude to generate a persistent output style based on that variation, one you can save globally inside your Claude Code.
After it generates the output style, you can switch it on or off anytime by typing /config. For example, I created one called "map first." Every time I ask for an explanation, I want Claude to map out the entire architecture of the application first. A lot of developers look at a response and think, "Okay, what are you actually referring to?" A visual map that shows up right in front of you makes things instantly easier to understand.
I generated this output style, saved it, and now if I go to /config and scroll down, I see "map first" as an option. I can select it, and from that point on, every single interaction starts with a map of how things work. If I set it once in my config, it becomes the default. Every time I open Claude Code, it's already using that style.
Everyone has their own preferred communication style. Yours will be different from mine. And Matt Pocock has a brilliant example of this with his "wait what" skill.
The "Wait What" Skill and the Power of STE-100
Matt Pocock created a skill called "wait what." The idea is simple: when Claude says something confusing, you trigger the skill and it essentially says, "Say that again, but in plain English."
What makes his approach unique is that he embedded something called STE-100 into the skill. STE-100 stands for Simplified Technical English. If you've never heard of it, it's a controlled language that was created for safety and clarity. It originated in the 1980s when technicians were writing repair manuals for airplanes. If a wrong word is used in an airplane repair manual, that's a massive problem for the mechanics on the ground.
The rules of STE-100 are designed to eliminate confusion. One word has one meaning. There are no synonyms. You can't switch between "start," "begin," and "launch." You must choose one approved word and stick to it every single time. Sentences that give instructions are capped at a maximum of 20 words, and there's only one action per sentence. You wouldn't write "open the valve and check the pressure." You'd split that into two separate lines.
The benefit is zero confusion. It removes all vague language, all slang, everything that could be misinterpreted. It also makes translation cheaper and faster, with fewer errors, because the language is so rigid and predictable.
Matt embedded this STE-100 standard into his skill. So whenever you interact with Claude using that skill, it explains things with no errors and no confusion. It's a system that's been working in the aerospace industry for decades, and now we can apply it directly inside Claude Code.
And here's where it gets powerful. Since we're talking about output styles, you can combine the two. You can create an output style that triggers the "wait what" logic every single time you talk to Claude. That means every discussion automatically follows the Simplified Technical English standard. You get that clarity by default, without having to invoke a skill manually.
My Personal Output Styles for Different Team Roles
Knowing how this works, I built a set of output styles for my own team. I have different people with different backgrounds, from technical to non-technical, and I created an output style tailored for each role.
These output styles live in my current project folder, which I share with my team. For example, the folder is called "Eric OS," and it contains curated skills and output styles that everyone can access. If they're working on a CRM or a building project, they have access to these pre-configured styles.
For a technical project manager, someone who is technical but doesn't write code. They understand how APIs work, they know the frontend, backend, and database, but they aren't in the trenches writing code. The output style for them cuts straight to the briefing. It uses principles from the "wait what" skill, explains things with one decision per trade-off, and always includes a clear recommendation. No fluff, just the decision-making framework they need.
Then there's the technical translator style. This is for someone with zero technical background. Maybe they're in data entry, or they're a marketer. They have no context for what's happening in the codebase. This output style translates everything Claude says into language they can actually understand. If they're looking at our second brain or any shared context, they can read it without getting lost.
For engineers, the need is different. An engineer knows everything, but they don't want to read a thousand words of output. They want Claude to cut to the chase. Similar to Lindia's "explain to me like I'm 5" approach, but for a technical audience. If I've had a long day and I've been reading code for hours, I don't want to read through a wall of text. Give me small words, shorter sentences, smaller paragraphs. I don't need hand-holding to make a decision or a trade-off recommendation. I know all that. Just give me the simpler version so I can onboard and understand faster.
For each personality, each responsibility, each job on the team, I have a dedicated output style. If you have a business or a team, I highly recommend you do the same. Once you select an output style, the AI uses it going forward. If I switch to the PM style and say "hi," Claude responds in that exact format.
Points clés à retenir
- La clarté diminue à mesure que l'intelligence augmente. Les modèles sont plus intelligents que jamais, mais leurs réponses sont souvent remplies de jargon difficile à comprendre.
- Changez le style, pas le modèle. Un ingénieur d'Anthropic recommande de personnaliser le style de sortie au lieu de changer de modèle pour obtenir des explications plus claires.
- Claude Code a des styles intégrés. Utilisez
/configpour basculer entre les modes par défaut, concis, proactif, explicatif et pédagogique selon vos besoins immédiats. - Générez votre propre style. Demandez à Claude de créer plusieurs variantes d'une réponse, choisissez celle que vous préférez, puis demandez-lui d'en faire un style de sortie global.
- Le STE-100 élimine toute confusion. La compétence "wait what" de Matt Pocock intègre l'anglais technique simplifié (un mot, un sens, phrases courtes) pour des explications sans erreur ni ambiguïté.
- Adaptez les styles aux rôles de votre équipe. Créez des styles dédiés pour les chefs de projet techniques, les traducteurs non techniques et les ingénieurs qui veulent aller à l'essentiel.
What I find most useful about output styles is the flexibility. I can use different styles for different situations. On one project, I might be focused on learning about implementation choices and codebase patterns, so I'll switch to explanatory mode. If I've already done the planning and I want Claude to run overnight and just execute without asking a million questions, I'll switch to proactive mode. If I want to get things done quicker, concise is the option. And if I want a specific team member to use it, there's a custom output style ready for them.
Output styles are incredibly configurable and easy to customize, and they'll save you a ton of tokens. As models get smarter and smarter, you've got to find a style that Claude can use to communicate with you effectively. The output style is the way to go.