Anyone who uses Claude for serious research and development eventually hits the same wall: the way it speaks. If I have to read one more time that I am "right to push back on that," or that we need to "quietly" fix a "load-bearing" component to minimize the "blast radius," I'm going to lose my mind. And honestly? These overused Claude-isms aren't just mildly annoying—they actively get in the way of building software. Anthropic tried to solve this recently with the built-in "concise" output style, but let's be truthful—it didn't really help. After wrestling with this for months, I've found what seems to be the only actual way to force Claude to speak to humans like a normal human.
The Diagnosis: A Noun Problem
Credit where credit is due: the first "aha" moment that cracked this open for me came from a Reddit post on r/ClaudeCodeTLDR titled "Opus 5 has a noun problem". The author perfectly described two massive linguistic crutches the model suffers from: severe over-nominalization (turning processes into abstract nouns) and omitting verbs in favor of trailing modifiers, resulting in robotic phrases like "The runner, built". They described the problem; I went ahead and found the fix that works for me.
Over-nominalization actively weakens the verbs Claude does use, leading to sentences that read like cognitive page faults. This opaque communication obscures system state and introduces severe operational risk through avoidable human error.
Why CLAUDE.md is the Wrong Fix
Most developers try to fix this by dumping communication rules into their CLAUDE.md or AGENTS.md files. That's a mistake. When you put rules there, they carry less weight and compete with your project architecture and coding conventions.
The right tool for the job is a custom output style. The architectural difference that makes this work is that an output style gets injected directly into the system prompt, not the user prompt. That is why this approach actually sticks.
Setting Up the Custom Output Style
Setting it up is straightforward. You just need a plain Markdown file. You can save it in ~/.claude/output-styles/ to apply it globally across your machine, or keep it in .claude/output-styles/ within a specific repository so your team can share it.
There is only one critical detail you cannot miss: you must set keep-coding-instructions: true in the file's frontmatter. If you leave this out, your style file will completely overwrite Claude Code's built-in software engineering instructions, and it will quietly forget how to scope changes or verify its work.
Once you have the file saved, restart Claude Code so it reads the style on startup, and activate it with /output-style. Keep in mind that subagents spin up with their own system prompts, so this style only applies to your main conversation.
The Configuration: Operational Rigor
Below is the exact output style I use to strip away the jargon and force operational rigor. You can copy and paste this verbatim into your own environment.
---
name: operational-rigor
description: Plain-English clarity. Answer first. Active verbs. No nominalization.
keep-coding-instructions: true
---
# Communication Directive: Plain-English Clarity & Operational Rigor
Apply these rules strictly to all conversational dialogue, explanations, technical reviews, error summaries, and documentation directed at the operator.
Do not apply these rules to code syntax, existing APIs, or idiomatic code generation.
1. **Lead with Active Verbs (Eliminate Nominalizations):** Express actions directly as verbs rather than converting them into abstract nouns paired with weak verbs (write "we analyzed," never "we performed an analysis of"). Never reify transient processes into invented jargon.
2. **Enforce Subject-Verb-Object (Ban Trailing Fragments):** Never omit the subject or finite verb in favor of telegraphic participles. Explicitly preserve agency and verb tense so the operator instantly knows who acted, what occurred, and when.
3. **Align Actors with Subjects:** Place the concrete entity performing the action in the grammatical subject position. Never hide operational responsibility behind passive or detached constructions.
4. **Frame Before Content:** Always name the tool, document, or execution context before presenting details or logs. Never dump detached diagnostic output or questions without context.
5. **Concept Before Identifier:** Describe the actual requirement, action, or failure mode in plain English first; place identifiers, codes, or ticket numbers in parentheses at the end.
6. **Decompress into Discrete Statements:** Restrict sentences to one clear idea.
7. **Translate Internal State into Concrete Reality:** State what actually failed in the real world (e.g., what file is missing, what boundary was crossed, and what exact command resolves it). Never expose raw graph concepts or compiler internals.
8. **Synthesize Intent (Never Echo):** When summarizing goals or instructions, translate them into a clear causal chain (Problem -> Mechanism -> Consequence). Do not stitch the operator's exact words back together.
9. **Answer First:** Lead directly with the operational verdict, decision, or fact. Eliminate introductory fluff, high-altitude corporate slogans, and rhetorical throat-clearing.
Jason Vertrees is the founder of Heavy Chain Engineering, which helps lower middle-market vertical SaaS companies and PE firms turn scattered AI usage into measurable delivery leverage — 85% faster feature velocity, six-to-eight-week projects shipped in days. If you want help building an AI-native engineering organization, book an AI Delivery Assessment or email jason.vertrees@gmail.com.