I read 100s of Claude replies a day: status updates, explanations, questions, summaries. Out of the box they are long, hedged and padded. This note is about one thing only: how Claude talks to me in chat, so I can read a reply once and act on it.
It is a different problem from AI-sounding output. Emails, posts and decks in my name follow my persona spec, and the tells that give AI text away have their own note (The New Em-Dash: 9 Tells of AI Writing). Here the reader is me, and the only goal is clarity.
The stack
4 layers, each with one job, all written into my global CLAUDE.md:
| Layer | Job | Source |
|---|---|---|
| Zinsser's 4 principles | The goal: simplicity, brevity, clarity, humanity | On Writing Well |
| ASD-STE100, about 80% | The mechanics of each sentence | Aerospace controlled language |
| Google developer documentation style | Formatting, contractions, instructions | developers.google.com/style |
| My own conventions | Numerals, European dates, no em-dashes, British spelling | Me |
When they collide, the order is fixed: Zinsser's clarity > my conventions > Google style > STE mechanics. Never cut a word the meaning needs.
Why ASD-STE100, and why only 80%
ASD-STE100 Simplified Technical English is a controlled language written for aircraft maintenance manuals, where an ambiguous sentence can kill someone. One meaning per word, active voice, short sentences, an approved dictionary. Every rule that makes a manual safe also makes a chat reply easy to scan.
On 2nd October 2026 Andrej Karpathy posted the same idea, with one refinement I adopted the same day:
"Ask your LLM to explain something in ASD-STE100 [...] it comes with heavy constraints on clean writing style that I often find a lot more readable. Sometimes I've tried to soften it a bit e.g. ask for "80% of the way to ASD-STE100" because the spec is quite stringent."
Full STE reads like a manual: choppy, stiff, sometimes contorted to dodge a banned word. And a model only knows its idea of the standard, not the dictionary, so asking for strict compliance buys stiffness, not accuracy. 80% keeps the readable core and drops the rest.
| Kept (the readable core) | Relaxed (the stiff 20%) |
|---|---|
| One word for one meaning, no synonyms for variety | Sentence length: 20 and 25 words are targets, not caps |
| Plain words: "use", not "utilise"; "start", not "initiate" | Vocabulary: plain English, not only the STE dictionary |
| Active voice, actor named | A perfect tense or an "-ing" form is fine when the alternative reads worse |
| One idea per sentence, one topic per paragraph | Noun stacks broken up when it reads better, no strict limit of 3 |
| Articles kept: "the file", not "file" | |
| Instructions as commands: "Run the script." | |
| No metaphors, idioms or jokes that hide the fact | |
| A list for more than one step or item |
What Google's developer style adds
STE says nothing about formatting or tone. Google's developer documentation style fills that gap:
- Contractions. "Don't" is safer than "do not" for a reader who scans and misses the "not".
- Condition before instruction. "To delete the file, run X", not "Run X if you want to delete the file".
- Sentence-case headings, numbered lists for sequences only, never a one-item list.
- No directional language ("above", "below") and no "simply", "just" or "easy".
- Descriptive link text, never "click here" or a bare URL.
- Every pronoun has a clear antecedent. Repeat the noun rather than leave an ambiguous "it".
The rules around the language
Language rules alone don't fix a reply. These do as much work:
- No restating my request, no preamble, no "Great question!" The answer starts at the answer.
- The point first. Then the detail, then what I need to decide.
- Line breaks where the thought changes, not one wall of text, and not a metronome of one-line paragraphs either.
- Numerals: "3 options", not "three options".
- One question at most. If something is unclear, ask once; otherwise make the best assumption and say so.
- Own the mistake plainly. "I was wrong", not "an error occurred".
Before and after
The same status update, raw and with the stack applied.
Before:
I've gone ahead and taken a look at the issue you mentioned, and it seems like the export process may have been failing due to what appears to be a configuration-related problem, which I have now addressed by updating the relevant settings so it should hopefully work going forward.
After:
The export failed because the API key was missing from
.env. I added it and ran the export again: it finished with 0 errors.
Half the length, the cause named, the proof included, no hedging.
Scope: chat only
This register governs how Claude speaks to me: replies, explanations, questions, summaries, status updates, commit messages. It never touches deliverables. Nobody should receive an email from me that reads like a maintenance manual. Those follow my persona spec instead (The NicAI voice stack).
Set it up yourself
Paste a block like this into your global CLAUDE.md (or your custom instructions):
## How to write to me
Write every message to me about 80% of the way to ASD-STE100 Simplified Technical English.
Keep: one word for one meaning, plain words, active voice with the actor named,
one idea per sentence, articles, instructions as commands, no metaphors or idioms,
lists for more than one item.
Relax: sentence length is a target (about 20-25 words), not a cap; plain English
beyond the STE dictionary; a perfect tense or -ing form when it reads better.
Also follow Google's developer documentation style: contractions, condition before
instruction, sentence-case headings, no "above/below", descriptive link text.
No preamble, no restating my request, point first, one question at most.
This applies to chat only, never to documents written in my name.
Further reading
- Andrej Karpathy's post on reading LLM output
- ASD-STE100 official site and free Issue 9
- Google developer documentation style guide
- On Writing Well, by William Zinsser
- The New Em-Dash: 9 Tells of AI Writing and The NicAI voice stack