STE is good for some text and bad for other text. So don’t switch it on and off. Write one rule that says when to use it: explanations in 80% ASD-STE100, drafts in your own voice. Put that rule in CLAUDE.md or AGENTS.md. Claude Code reads both, and Codex reads AGENTS.md.
Two other ways fit narrower needs:
- An output style, if you want every single reply in STE. It’s a separate setting, and you switch it with a command.
- A skill, if you want to rewrite one specific text, such as a README, an error message or a tool description. The popular STE skills come with a checker.
Whichever you use, ask for the loose version, not the full standard. Andrej Karpathy suggests “80% of the way to ASD-STE100” himself. In one public test, the full standard made Claude drop almost half of the facts in its explanations of code. In my own runs, every version made sentences shorter but not answers. Both tests are below.
What is ASD-STE100, and why did Karpathy suggest it?
ASD-STE100, or Simplified Technical English, is a controlled form of English. The aerospace industry wrote it in the 1980s so that aircraft maintenance manuals can’t be misread, including by mechanics who don’t speak English natively. The current version, Issue 9 from January 2025, has 53 writing rules and a dictionary of about 900 approved words. It has been free to download since 2013.
The rules you notice first:
- One idea per sentence.
- Instructions of 20 words or fewer, descriptions of 25 or fewer.
- Active voice.
- One word for one meaning.
On October 1, 2026, Karpathy posted that “we’ll be spending a lot more time trying to understand the outputs of language models.” His first tip was to ask the model to explain things in ASD-STE100. Models know the standard well, and he finds the result easier to read. Because the spec is stringent, he sometimes asks for “80% of the way to ASD-STE100.”
Note what he uses it for: reading what the model tells you. He isn’t suggesting you publish in it.
How do you set it up in CLAUDE.md or AGENTS.md?
Add this to ~/.claude/CLAUDE.md to use it in every project, or to a project’s CLAUDE.md to use it in one:
## How to write
- When you explain something to me (answers, summaries, explanations of
files or code), write 80% of the way to ASD-STE100 Simplified Technical
English: one idea per sentence, short sentences, active voice, one word
for one meaning. Keep product names, code names and domain terms as
they are. Do not replace them with simpler words.
- When you draft or edit text for publication (articles, posts,
introductions), do not use STE. Write in a natural voice with varied
sentence length.The first line is Karpathy’s tip. The second keeps STE out of anything that should sound like you. The sentence about names and terms matters more than it looks; the test section below explains why.
A project’s CLAUDE.md is often shared with your team. If the rule is only your reading preference, put it in ~/.claude/CLAUDE.md instead.
The same lines work in a project’s AGENTS.md. If you use both Claude Code and Codex, put them there: Codex reads AGENTS.md, and Claude Code reads it too when the project has no CLAUDE.md (details).
For a personal setting in Codex, use developer_instructions in config.toml (Codex config reference). Its personality setting only offers none, friendly and pragmatic, so it can’t hold this rule.
Either way, it’s an instruction the agent follows, not something the tool enforces.
When is an output style the better choice?
When you want every reply in STE, with no exceptions for drafts. An output style is a set of instructions that sets Claude’s tone, length and format for every response in a session. I didn’t know about it until I looked into this tip, and I suspect many Claude Code users don’t either.
Claude Code has four built-in styles besides Default: Proactive, Concise, Explanatory and Learning. You switch with /output-style <name>, or through /config → Output style (Claude Code docs). For an STE style, save this as ~/.claude/output-styles/ste-80.md:
---
name: ste-80
description: Explain things 80% of the way to ASD-STE100
keep-coding-instructions: true
---
Write 80% of the way to ASD-STE100 Simplified Technical English:
one idea per sentence, short sentences, active voice, one word for
one meaning. Keep product names, code names and domain terms as
they are. Do not replace them with simpler words.Then restart Claude Code, which reads style files when it starts, and run /output-style ste-80.
Two things to know:
- A custom style drops Claude Code’s coding instructions by default. These tell Claude how to scope changes, write comments and check its work. That’s why the file above sets
keep-coding-instructions: true. - To get your own voice back, you switch styles. If you draft in the same project, that means a command each time. This is why I prefer the rule in CLAUDE.md.
Ivapo/asd-ste-100-output-style (MIT) is a ready-made, stricter version.
Should you ask for full ASD-STE100 or 80%?
Ask for 80%, or just “Simple Technical English.” The full standard can cost you facts, and the loose versions read almost the same.
Lucian Ghinda’s test, explaining code. Ghinda asked Claude and Codex to explain four pieces of real code. He compared three conditions: no style, “Simple Technical English,” and “ASD-STE100 Simplified Technical English.” He checked each explanation against six facts per sample.
| Claude | No style | ”Simple Technical English" | "ASD-STE100” |
|---|---|---|---|
| Average words per sentence | 17.8 | 9.1 | 10.2 |
| Facts lost compared with no style | — | 8.5% | 46.8% |
His explanation: the STE dictionary has no words for domain concepts, so the model explains them away. Codex already wrote short sentences by default, and both instructions made it worse. If you use Codex, read a few answers before you keep the rule.
My test, explaining plain prose. I ran Claude Code 2.1.280 with Opus 5.5, with each wording set as an output style, two runs per condition. Each time, I asked it to explain a section of the output styles docs to a writer who doesn’t code. I then checked each answer against eight facts from that section.
| Instruction | Average words per sentence | Total words | Facts kept |
|---|---|---|---|
| None | 16–18 | about 600 | 8 of 8 |
| ”Simple Technical English” | 11–12 | about 570 | 8 of 8 |
| ”80% of the way to ASD-STE100” | 11–12 | 570–660 | 8 of 8 |
| ”ASD-STE100” | 10–11 | about 570 | 8 of 8 |
Sentences got about 35–40% shorter. Here no version lost facts, because the text had few domain terms to lose. Two things surprised me:
- The answers didn’t get shorter. STE split the same content into more sentences. If what bothers you is length, use the built-in Concise style instead.
- The three wordings came out almost the same. “80%,” “Simple Technical English” and the full name all gave sentences of 10–12 words.
Put the two tests together and the deciding factor is how many domain terms your text has. Plain prose survives the full standard. Code, product names and jargon don’t. That’s why the rule above asks for 80% and tells Claude to keep names and terms as they are.
When is a skill the better choice?
When you want to rewrite a specific text, not change how Claude talks to you. A skill loads only when you call it or the task matches it, so the rest of your session stays as it was.
The two STE skills with the most GitHub stars:
- AminBlg/SimpleEnglish (3.7k stars, MIT). Its default Plain mode applies the core rules. Strict mode adds the official vocabulary when you name STE or ASD-STE100. It installs as a Claude Code or Codex plugin, or with
npx skills add AminBlg/SimpleEnglish. The author’s own benchmark reports 78% fewer rule violations. The author also notes that this measures rule-following, not how easy the text is to read. - danyuchn/asd-ste100-skill (3.1k stars, MIT). It’s written for text that another agent reads: tool descriptions, error messages, system prompts. It includes a linter (
scripts/ste-lint.py) that flags passive voice, phrasal verbs and other violations, so you get a real check, not only an instruction. Install it withnpx skills add danyuchn/asd-ste100-skill.
Neither is meant for marketing copy or personal writing. The danyuchn README says so directly.
What about the Claude app?
The Claude app, on the web at claude.ai, on desktop and on mobile, doesn’t read CLAUDE.md. Put the two lines in your profile preferences instead, or create a Style: Search and tools → Use style → Create & edit styles → Create custom style → Describe style instead.
Where does STE help, and where does it hurt?
To see this on real text, I asked Claude to explain the public StashBase README, once with no instruction and once with the 80% instruction. The two answers were about the same length (435 and 411 words) and kept the same product names.
It hurts in an introduction. Here is how each version opened:
Default: This README is for StashBase, an open-source desktop app (Apache 2.0) that bills itself as “like an IDE, but for writing.” You keep your documents and source material in ordinary local folders, and you write with an AI agent (Claude, Codex, or a built-in “Default Agent”) that can search those files and help draft and revise.
80% STE: This README describes StashBase. StashBase is a writing workspace. It is open source and local-first. Its tagline is “Like an IDE, but for writing.” You write in it with an AI Agent, such as Claude or Codex. The Agent uses your own sources and your past work.
The STE version takes four short sentences to say what the default says in one. Each sentence is clear, but together they read like a parts list. An introduction has to connect ideas, and STE cuts the connections.
It helps in text you look things up in. Here is the privacy section:
Default: Files stay on your machine, and removing a project from StashBase doesn’t delete them. Editing, browsing and keyword search work without an account, and OCR runs locally. Chatting with an agent does send your prompts and the relevant context to a model provider.
80% STE: Your files stay in local folders. Editing, keyword search, and OCR work on your machine without an account. Agent chats send your prompts and context to model services. Search by meaning needs your own OpenAI or OpenRouter key. It sends your text to that embedding provider.
Here, one fact per sentence is what you want. Someone checking “does this send my files anywhere?” can scan for the answer without rereading.
The pros and cons, in short:
| Helps | Hurts |
|---|---|
| Long explanations become easier to scan. | Introductions and stories read like a manual. |
| One word stays one meaning, so terms don’t drift. | The full standard drops domain terms and the facts behind them. |
| It works with one instruction; no tool needed. | Answers aren’t shorter, only the sentences are. |
| A skill with a linter can check text you ship. | As an instruction, nothing enforces it. Claude can drift. |
| It flattens your voice. In my runs, “thus” and “occurs” came back again and again. |
So use it for explanations, reference sections, settings, error messages and instructions. Keep it out of anything that’s meant to sound like you. That’s what the second line of the rule is for. For your own voice, give Claude your writing preferences, or clean up a draft with Humanizer, which pushes in the opposite direction.
How do you set this up in StashBase?
StashBase has a Persona picker beside the agent in the message box. Paste the two lines from the CLAUDE.md section into Custom, and the same rule applies whether you're asking about a source or drafting beside it. You don't edit a config file, and your documents stay open beside the chat.
The persona works with every agent: Claude Code, Codex and the built-in Default Agent. Claude Code and Codex use your existing subscription.