Claude Opus 5 Output Style: Kill the Jargon Wall

Claude Opus 5 Output Style: Kill the Jargon Wall

I asked Claude Opus 5 a boring question. Why had a client's email open rates dropped about eight points month over month?

The answer was correct. I want to be clear about that up front, because the complaint I'm about to make is not "the model got it wrong." It got it right. It also handed me four paragraphs containing MPP, send-time optimization, geo data, device data, and a distinction between "opens" and "unique opens" that mattered enormously and was explained in exactly one dependent clause. I read it twice. Then I opened a blank document and rewrote it in six sentences so I could send it to a marketing manager who does not know what MPP stands for.

That rewrite took me eleven minutes. And I do that rewrite, in some form, several times a day.

The fix is not a better prompt. I tried better prompts for two weeks and they hold for about three exchanges before the model drifts back to its default register. The fix is a Claude Opus 5 output style — a config layer that sits far deeper in the stack than anything you type into a chat box — plus a handful of skills so small you can write them in a single line. That's the whole post. Two config changes, both copy-pasteable, both reversible in thirty seconds.

But before the files, you need to understand why the obvious fix — putting "be concise" in your CLAUDE.md — is the thing that has been quietly failing you.

Why Opus 5 talks like this in the first place

Two separate problems get mashed together in every complaint thread, and they need two different fixes. Untangling them is most of the work.

Problem one is jargon density. Opus 5 assumes prior knowledge. It reaches for the compact domain term over the plain explanation, and it does this even when the surrounding conversation gives it no evidence you have that domain. The email example is the mild version. The severe version is what one widely-shared write-up called Opus 5 inventing terminology you're expected to already understand — DEV Community's post on the problem is blunt about it, and the community has started calling the output "Claudisms." You ask a question in English and get an answer that requires an English-to-English translation pass.

Problem two is length. Different failure, different cost. Reviewers describe Opus 5 as burying the answer in explanation rather than leading with it, and MindStudio's roundup of the reception documents verbosity as the single most common complaint — scattered, exhausting, hedge-heavy. Anthropic itself has acknowledged that Opus 5's default user-facing responses run longer than prior Opus models, and shipped a prompting guide on release day naming the behavior.

Here's the part that turns an annoyance into a line item. At Opus 5's API rate of $25 per million output tokens (against $5 per million input), verbosity is not a stylistic preference. It is billing. A model that answers a yes/no question in 900 tokens instead of 90 is charging you ten times for the same information, and you're paying twice — once to Anthropic, once in the minutes you spend reading past the answer to confirm it was the answer.

I ran a crude check on my own usage before writing this, and I'd encourage you to run the same one rather than trusting my number. Take your last twenty Opus 5 sessions, and for each, find the response that actually answered your question. Estimate what fraction of that response you needed. My honest read on mine was somewhere between a third and a half. I'm not going to dress that up with a decimal point I didn't earn — but even at the generous end, half of what I'm paying for and reading is scaffolding.

Two problems. Two fixes. The mistake almost everyone makes is trying to solve both with the same instruction.

The CLAUDE.md trap

Your first instinct is to write "explain things simply, avoid jargon, be brief" into CLAUDE.md and move on. I did this. It works, briefly, and then it doesn't.

CLAUDE.md is project context. It gets read, it competes with everything else in the file, and as the conversation grows it drifts further from the model's active attention. If you've already read my breakdown of what to delete from your prompts before you write anything new, you know how fast these files bloat — mine hit 98,733 characters before I audited it. A style instruction buried at line 400 of a context file is a suggestion, not a constraint.

An output style is a different mechanism entirely. It injects into the system prompt, and Claude gets reinforced mid-session to hold it. That's the whole difference. One is something the model read once; the other is something the model is.

This is why the same words that fail in CLAUDE.md succeed as an output style. You're not writing a better instruction. You're moving the same instruction to a layer where it actually binds.

What is a Claude Code output style, exactly?

An output style is a configuration setting that controls the tone, complexity, and delivery format of Claude's responses by modifying its system prompt. Four styles ship built in — Default, Proactive, Explanatory, and Learning — and you can write your own as markdown files that Claude Code loads automatically.

Custom styles live in one of two places:

• ~/.claude/output-styles/ — available in every project on your machine
• .claude/output-styles/ — scoped to a single repository, and shared with anyone who clones it

Now the part that will save you a confused ten minutes, and the reason I'd rather you read this than a tutorial written eight months ago.

The /output-style slash command no longer exists. It was deprecated in Claude Code v2.1.73 and removed outright in v2.1.91. If you type it, nothing happens, and a fair number of guides still tell you to. Use /config instead, find the Output style entry in the menu, and pick from there — or set the outputStyle field directly in your settings file if you'd rather not touch the TUI.

There's history behind that command's disappearance, and it tells you something about how much this feature matters to people who use it. Anthropic deprecated output styles entirely in v2.0.30. Four days later, v2.0.32 shipped with a one-line changelog entry: un-deprecate output styles based on community feedback. A feature that was quietly killed and publicly resurrected inside of a week is not a niche toggle. It's load-bearing for a chunk of the user base, and most people have never opened the menu.

So let's write one.

Fix 1 — The ELI5 output style (copy-pasteable)

The style I actually use is built on two ideas stacked together.

The first is ELI5 — "Explain Like I'm Five." This is not a gimmick. It's a targeting decision. ELI5 is a large, heavily-upvoted corpus of humans explaining hard things to non-experts, and asking for that register gives the model a well-worn groove to fall into rather than a vague instruction like "be simpler." You are naming a genre it knows deeply, not describing an abstraction.

The second is ASD-STE100 Simplified Technical English — and this is where the style stops being a cute trick and starts being an engineering standard. STE is a controlled-language spec maintained by ASD Europe for aerospace and defense documentation, where an ambiguous maintenance instruction is a safety incident. Issue 9, released January 15, 2025, contains 53 writing rules and a dictionary of roughly 900 approved words, each carrying exactly one meaning. Active voice. Short sentences. One word, one definition, no synonyms.

Think about what that does when you point it at an LLM. STE was designed to stop a technician in a hangar from misreading a procedure. The failure mode it prevents — a term that means two things, a sentence that parses two ways — is precisely the failure mode of Opus 5's default register. It's a fifty-year-old solution to a brand-new problem, and it's free.

Save this as ~/.claude/output-styles/eli5.md:

---
name: ELI5
description: Plain-language answers. Conclusion first, jargon translated, one meaning per word.
---

# Delivery rules

You explain things to a smart adult who does not work in this domain.
They are not stupid. They are unfamiliar. Never condescend, never pad.

## Structure — non-negotiable

1. Open with the direct answer in one or two sentences. No preamble,
   no restating the question, no "great question."
2. Then explain the reasoning, in plain language.
3. Then, only if it changes what the reader should do, add caveats.

If the answer is "yes," the first word is "Yes."

## Language

- Follow ASD-STE100 Simplified Technical English principles: active voice,
  one idea per sentence, one meaning per word, no synonym variation for
  the same concept.
- Maximum 20 words per sentence where the meaning allows it.
- Every acronym or domain term gets a plain-English gloss the first time
  it appears, in parentheses, six words or fewer.
  Example: "MPP (Apple's inbox privacy feature)".
- Never invent a term. If no common word exists, describe the thing.
- Banned: "leverage", "utilize", "robust", "seamless", "holistic",
  "it's important to note", "essentially", "fundamentally".

## Length

- Do not pad to seem thorough. A three-sentence answer that is complete
  is better than three paragraphs that are complete.
- Do not add a summary section that repeats what you just said.
- Do not offer next steps unless asked.

## Close

End with one sentence a non-expert could repeat out loud to a colleague
and be correct.

Load it with /config → Output style → ELI5.

Ask it something you'd normally have to rewrite. In my case I went back to the email question, and the difference was the ordering more than anything: the answer came first, MPP got glossed in four words, and the opens-versus-unique-opens distinction that had been hiding in a subordinate clause got its own sentence. I could have forwarded it as-is.

One honest caveat before you go all-in. This style is a blunt instrument, and it should be. If you're deep in a code review and you want the model reasoning at full technical density, ELI5 is the wrong lens — it will translate things that didn't need translating. I keep Default as my working style for engineering sessions and switch to ELI5 when I'm producing something a human outside my team will read. Switching takes about five seconds. Treat it as a lens you pick up, not glasses you weld on.

Which brings me to the thing I got wrong on my first attempt.

Why I took the length rules back out (mostly)

My first version of this style had hard limits. Maximum 150 words. Maximum three bullet points. Never exceed one screen.

It was a disaster, and it took me a while to see why, because the symptom didn't look like the cause. The model stopped being verbose and started being wrong — not factually wrong, but truncated in ways that dropped the qualifier that mattered. I'd ask a question with a genuinely conditional answer and get a confident short one. I had optimized for the metric I could see (length) and paid for it in the thing I actually cared about (correctness).

Here's the principle, and it's the one thing in this post I'd tattoo on someone: sometimes the long answer is the correct answer. A migration plan with seven ordered steps is seven steps long. Compressing it is not a style improvement, it's data loss.

So length does not belong in the output style. Length is situational, which means it belongs in something you invoke when the situation calls for it.

That's what skills are for.

Fix 2 — Three tiny skills for the length problem

A skill in Claude Code is a SKILL.md file with YAML frontmatter and a body of instructions. Global skills live in ~/.claude/skills/, project skills in .claude/skills/. The loading model is worth understanding: at session start Claude reads only the frontmatter of every skill — name and description, a handful of tokens each. The full body loads only when the skill fires. So a dozen small skills cost you almost nothing until you use one.

That frontmatter also controls how a skill fires. invocation: user means it only runs when you type the slash command. invocation: auto lets Claude fire it when it decides the description matches. For everything below, you want user — these are lenses you choose, not behaviors you want the model guessing at. I've written more about the general pattern in my guide to building skills instead of agents, but these three are deliberately trivial.

/bro — translate that back into human

The one I reach for most. It does one job: restate what you just said, in plain language, for someone who is not in this field.

~/.claude/skills/bro/SKILL.md:

---
name: bro
description: Restate the previous response in plain human language with zero jargon.
invocation: user
---

Take your immediately previous message and say it again to a friend who
does not work in this field.

Rules:
- Keep every fact. Change every word that needed a definition.
- Lead with the point. Cut the setup.
- Aim for under a third of the original length.
- No lists unless the original was genuinely a sequence of steps.
- Do not apologise for the first version and do not explain that you
  are simplifying. Just say the thing.

That's the entire skill. Nine lines of instruction. It is the highest-value-per-byte file in my ~/.claude directory, and it exists because I got tired of typing "ok now say that like a normal person" four times a day.

/wait-what — same, but I'm actually lost

Different from /bro in a way that matters. /bro says I understood you, now make it sendable. /wait-what says I did not understand you, and simplifying alone won't fix it — I'm missing context you assumed I had.

---
name: wait-what
description: Re-explain the last response, adding the background context I am missing.
invocation: user
---

I did not follow your last message. The problem is probably missing
background, not vocabulary alone.

Re-explain it, and this time:
- State the assumption you were making about what I already know.
- Fill that gap first, in two or three sentences, before returning
  to the original point.
- Use one concrete analogy from ordinary life.
- Then restate the original answer in plain language.

Do not simply repeat yourself in shorter words. Add the missing piece.

The line that earns its keep is state the assumption you were making. Half the time, seeing the assumption written out is enough — I didn't need the explanation, I needed to know which door I'd walked past.

/quick — compress to N points

The length fix, on demand, with the count under my control instead of baked into a config file.

---
name: quick
description: Compress the previous response (or a supplied text) into N numbered key points.
invocation: user
---

Compress into exactly N numbered points, where N is the number I passed
in. If I passed no number, use 3.

Rules:
- Each point is one sentence. Hard stop.
- Order by importance, not by the order things appeared in the original.
- If something is genuinely conditional, the condition goes in the
  sentence — do not drop it to save words.
- If the content honestly cannot compress to N points without losing
  something that changes a decision, say so in one line, then give
  the smallest honest number.

Output nothing except the numbered points and, if needed, that one line.

/quick 3 is muscle memory for me now. That last rule is the one I added after the failed style experiment — it's the escape hatch that stops compression from becoming distortion. The model is allowed to tell me three isn't enough. That single permission is the difference between a summarizer and a liar.

Three files. Maybe forty lines total. They cost nothing at rest and they cover the overwhelming majority of "that was too much" moments. If you want to see how far the token-reduction idea can be pushed, the Caveman skill experiment takes the same principle to an extreme I find useful more often than I expected.

Write your own next. The pattern generalizes: notice the correction you type more than twice a week, and make it a slash command.

If you'd rather have this whole layer — styles, skills, and the settings that govern how your agents communicate — designed and installed for your team's actual workflow rather than assembled from a blog post, that's a chunk of what I do. You can see the kind of work at fiverr.com/s/EgxYmWD.

The benchmark trap nobody priced in

Step back from the config files for a second, because there's a bigger point here and it's the reason I bothered writing any of this.

Opus 5 posts strong numbers. I went through them line by line in my benchmark breakdown, including the evals where it actually loses. And yet a large number of developers report it feels worse than Opus 4.8 in daily work. Both things are true at once, and the gap between them is not a mystery.

Benchmarks measure whether the answer is correct. They do not measure whether you can read it.

It's the difference between a laptop with excellent specs and a laptop with an excellent trackpad. The spec sheet wins the comparison article. The trackpad decides whether you're still happy with it in March. Nobody benchmarks reading effort, so nobody optimizes for it, so it degrades — and then everyone is confused about why the better model feels worse.

Here's the leverage: that gap is closeable by you, in config, in about ten minutes. Not by waiting for a point release. Not by switching providers. The model is malleable enough that a system-prompt-level style instruction genuinely changes its register, and that malleability is the durable part of this. Opus 6 will ship. Its defaults will be tuned for whatever Anthropic's evals reward, which will not be how tiring is this to read on a Thursday afternoon. The specific words in my ELI5 file will need adjusting. The practice — own your output layer, don't accept the default register — will not.

Output styles and skills are the interface layer of your agentic setup. Everyone spends their time on capability: which model, which tools, which MCP servers. Almost nobody configures how the thing talks to them. It's the cheapest unclaimed win in the whole stack.

One more practical note. Once you've got a style and four or five skills you like, consolidate them into a single reference document — one markdown file with your settings, your styles, and your skills, in copy-pasteable blocks. You'll set up a new machine, or onboard a teammate, or start a client project, and being able to import the whole communication layer in one paste rather than reconstructing it from memory is worth the twenty minutes it takes to write down.

Go break your own default

That email explanation I rewrote by hand at the top of this post? I fed the same question to Opus 5 again after the style was in place, and the thing I noticed was not that the answer was shorter. It was that I stopped reading like an editor. I read it once, as information, and moved on. Eleven minutes of translation work became zero, and it stayed at zero, because the fix was in the system prompt and not in my willpower.

Here's your next twenty minutes. Run /config and look at Output style — just look, most people have never opened that menu. Save the ELI5 file above to ~/.claude/output-styles/. Save /bro to ~/.claude/skills/bro/SKILL.md. Then go find the last Opus 5 response you had to mentally translate, paste the question back in, and compare.

The model was never the problem. You've just been running it on factory settings.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io