ASD-STE100 Skill Review: Aerospace English for AI Agents

TL;DR

asd-ste100-skill (danyuchn/asd-ste100-skill) is a Claude Code skill that rewrites dense, ambiguous English into a loose form of ASD-STE100 Simplified Technical English. STE is the controlled language that the aerospace and defense industry uses so that aircraft maintenance instructions can only be read one way. The skill is aimed at text that another machine must parse with no human to ask: tool descriptions, error messages, system prompts and instructions between agents. It also ships ste-lint.py, a small Python linter with no dependencies that checks the structural rules.

Facts as of October 12, 2026:

4,623 GitHub stars, 268 forks, MIT license. The repo was created on July 20, 2026, and it is on GitHub’s weekly trending list today.
No tagged releases. SKILL.md declares version: 0.4.0. The last commit (October 4, 2026) fixed how the linter treats modal perfects (“may have run”).
2 open issues and 4 open pull requests. One open PR adds Codex support.
Contents: a 139-line SKILL.md, a rule summary, before/after examples and a 486-line linter.

Not run by us: our hands-on lab could not start today because the GitHub Actions job behind it was blocked by a billing limit on the account. Everything below comes from reading the repository, its issues and published third-party tests. We did not install the skill or run the linter.

Our verdict: this is one of the more careful “anti-slop” skills we have read. Its best idea is not shortness. It is the modality rule: a rewrite must never turn “may have failed” into “failed”. The linter is honest about how little it checks, and an open bug report shows it checks even less than it claims. Use it for strings that machines read and that you ship: tool descriptions, error messages, agent handoffs. Do not use it as a style for every conversation. Independent tests suggest the strict standard can make a model drop facts.

What ASD-STE100 is, and why agents are suddenly using it

ASD-STE100 was first released in 1986 for European airlines whose mechanics were often not native English speakers and could not call the author to ask what a sentence meant. The current edition is Issue 9 (January 2025): 53 writing rules in 9 sections and a dictionary of roughly 900 approved words, each with one meaning and one part of speech. The rules people notice first are one instruction per sentence, at most 20 words per procedure sentence (25 for descriptions), active voice, simple tenses, no phrasal verbs and no semicolons at all (Rule 8.1).

In 2026 this aerospace standard became a developer trend. The trigger was a familiar complaint: frontier models write walls of abstract prose. In a July Hacker News thread about a similar skill, one commenter wrote that “since Opus 5 I’m much more often staring at the wall of text and I have no idea what it’s telling me.” According to StashBase, Andrej Karpathy then posted on October 1 that his first tip for reading model output was to ask for it in ASD-STE100, or “80% of the way to ASD-STE100” when the full standard is too stiff.

danyuchn’s repo takes a narrower position than most of the wave. Its README argues that an LLM reading another agent’s output is in the mechanic’s position: it has “no back-channel, no way to ask ‘did you mean X or Y?’” So the skill targets text written for machines, not your chat replies.

What the skill actually does

The core is a single SKILL.md. Claude Code loads it when you ask it to “disambiguate this”, “apply STE100 to this”, or “rewrite this error message so an agent can’t misparse it”. The skill then follows a fixed process.

1. It picks a mode. Strict covers procedures, error messages, tool descriptions and inter-agent instructions, where a wrong reading has a cost. STE-flavored covers READMEs, PR descriptions and changelogs. That mode keeps the sentence rules (length caps, active voice, no semicolons, no marketing adjectives) but drops the “one word, one meaning” lockdown. The skill’s reasoning is that a strict rewrite of prose “reads as a personality transplant rather than a clarification.”

2. It splits the rules into two kinds. This is the most honest part of the design. Structural rules are about sentence shape, and you can apply them from the rule alone. Lexical rules depend on ASD’s approved dictionary, which the repo does not include. The standard is free to request but not free to redistribute: Issue 9 grants reproduction rights only to listed categories of organisation. So the skill applies lexical rules only as “a direction of travel” and is told to say so rather than imply dictionary compliance.

3. It flags, then rewrites. It checks each sentence against the rule tables and a six-item checklist (synonym rotation, hedge stacking, nominalization, marketing adjectives, run-ons, soft phrasal verbs). If a shorter phrasing would drop a safety condition, a scope qualifier or a number, it keeps the longer phrasing.

4. It prints only the result. No preamble, no change summary, just the rewritten text plus an optional Kept as-is: line. Ask to “show the diff” and you get a table of rules violated instead.

Here is the README’s own error-message example:

BEFORE
An error may have occurred while processing your request due to a possible
mismatch in the expected data format, which could be caused by an outdated
client version.

AFTER
Your request may have failed. The cause may be a data format that does not
match what the server expects. An outdated client can cause this mismatch.
Check your client version.

The modality rule is the real contribution

Most “write simply” prompts reward shorter sentences. The danger is that the easiest words to cut are hedges, and hedges carry information. “The request may have failed” and “The request failed” are different claims.

The skill makes this a hard rule: “A shorter sentence that upgrades a hedge to a fact is not a simplification — it is a different claim.” The examples file admits that an earlier version of its own error-message rewrite made exactly this mistake. That version produced “The request failed” and invented the phrase “the most common cause”. It also states a priority: when the simple-tense rule conflicts with a hedge, “modality wins”. “May have failed” keeps its compound verb because removing it would delete the uncertainty.

A second rule is just as useful for agent pipelines: “Never add a fact the source did not state.” If you write tool descriptions for MCP servers or system prompts for sub-agents, these two rules are worth copying even if you never install the skill.

The linter: useful, small, and with known gaps

scripts/ste-lint.py is a regex-based checker that uses only the Python standard library. The README documents this usage:

# Lint files; exit 1 if hard violations exceed the baseline (default 0)
python scripts/ste-lint.py docs/tools.md

# Pipe text in, get structured JSON out
echo "The cache was cleared; please reach out to support." | python scripts/ste-lint.py --json

# Adopt on existing docs: tolerate N hard violations, silence named rules
python scripts/ste-lint.py --baseline 41 SKILL.md
python scripts/ste-lint.py --disable passive-voice,present-perfect README.md

# Built-in assertions, including "may have failed" passing clean
python scripts/ste-lint.py --selftest

From the source, the rules split into two levels:

Rule	Level	What it catches
`semicolon`	hard	Any `;` (Rule 8.1)
`phrasal-verb`	hard	spin up, reach out, dive into, kick off, circle back, touch base
`marketing-adjective`	hard	seamless, robust, cutting-edge, effortless, blazing-fast, world-class, state-of-the-art, game-changing
`nominalization`	hard	”perform/conduct/carry out a …tion/ment/ysis”
`long-sentence`	hard	More than 25 words
`synonym-rotation`	hard	Mixing check/verify/confirm/validate and nine similar groups in one file
`dangling-conjunction`	hard	List items that end in “and” / “or”
`passive-voice`	advisory	”is/was/were + -ed or common participle”
`present-perfect`	advisory	”has/have/had + participle”, except after a modal

Advisory findings never fail the run. Hedges are never flagged by design. The code comment says a linter that pressures hedges out “would rewrite claims”, and the self-test asserts that “The request may have failed. It could be a timeout.” produces zero findings.

The README is frank about the limits. There is no noun-cluster rule (it needs part-of-speech tagging), only six phrasal verbs are known (“take off the panel” passes), and the linter cannot compare an original with its rewrite. The repo’s own SKILL.md does not lint clean, hence --baseline 41.

Open issue #17, filed October 4 by a team that vendors the linter, adds gaps the README does not mention. Sentences ending at a closing quote are not split, so two short sentences get flagged as one long one. An “e.g.” splits a 29-word sentence into two passing halves. And because the linter works line by line, a 28-word sentence hard-wrapped across two Markdown lines is never measured. The reporters also say argument flags are silently misparsed, and an open PR (#20) targets all of it. Until it merges, treat long-sentence as a hint, not a gate, if your docs are hard-wrapped.

Does STE actually help? What independent tests show

The repo publishes no benchmark of its own, which is fair: it says what it does and does not claim a quality number. Two outside tests are useful.

Lucian Ghinda’s code-explanation test (write-up, data) asked Claude and Codex to explain four pieces of real code. It compared no instruction, “Simple Technical English” and “ASD-STE100 Simplified Technical English”. Claude’s sentences fell from 16.3–19.6 words to 8.1–10.7 words with either instruction. But facts went missing. In his first run, Claude kept 23 of 24 checked facts with no style, 21 with “Simple Technical English”, and only 14 with “ASD-STE100”. His explanation is that the strict standard pushes the model to explain domain terms away. Codex already wrote short sentences, and both instructions made its fact counts worse.

StashBase’s prose test (write-up) had Claude Code with Opus 5.5 explain a plain-language docs page. Sentences got about 35–40% shorter with no facts lost, but the answers were not shorter overall. The author’s conclusion: the deciding factor is “how many domain terms your text has”.

Neither test used this skill; both tested a one-line instruction. They still show the risk the skill’s modality and no-new-facts rules exist to prevent.

Community reaction

The July Hacker News thread on AminBlg’s SimpleEnglish skill reached 363 points and 122 comments. danielbarla said a plain STE prompt mainly gave “shorter sentences, and fewer drumroll, pitch-deck / vacuous section titles.”

Others asked why a skill is needed when ASD-STE100 “was surely in the training material” (dan_sbl). QuercusMax gave the best case for this repo: “skills can often include helper scripts or other binaries.” A prompt cannot run ste-lint.py in CI.

A public gist turns the repo into a Claude Code output style for all replies, and open issue #19 proposes a companion “rewrite-fidelity” checker for lost numbers, conditions and hedges, the gap the linter admits it cannot fill.

Installation

# Per project, via the skills CLI (sends anonymous install telemetry;
# set DISABLE_TELEMETRY=1 to opt out)
npx skills add danyuchn/asd-ste100-skill

# Or globally, as a live git checkout
git clone https://github.com/danyuchn/asd-ste100-skill ~/.claude/skills/asd-ste100

Then ask “Disambiguate this tool description”. The linter needs only Python 3.

Honest limitations

Not a certified STE tool. Without the ~900-word dictionary, it cannot claim dictionary compliance, and it says so. For real aircraft documentation, get the standard.
Claude Code first. Codex support is an open PR (#21), not a merged feature. The npx skills installer works with other harnesses, but the README is written for Claude Code.
The linter is shallow. Six phrasal verbs, eight marketing words, no noun-cluster rule, and the sentence-splitting bugs in issue #17.
It fixes form, not substance. In the README’s words: “A paragraph with nothing to say comes out short, clean, and still empty.”
Strict mode can cost facts in technical explanations, judging by Ghinda’s test. Read the output.
No releases. Pin a commit if you vendor the linter into CI.

How it compares

Option	Best for	Enforcement
danyuchn/asd-ste100-skill	Tool descriptions, error messages, agent handoffs	Skill + deterministic linter
AminBlg/SimpleEnglish (3,875 stars, MIT)	Docs; Plain and Strict modes; plugin for Claude Code and Codex	Skill
One line in CLAUDE.md / AGENTS.md (“80% of the way to ASD-STE100”)	How the model explains things to you	None; the model can drift
Claude Code output style	Every reply in STE	None
Vale with a style package	Gating docs in CI with mature tooling	Linter only

If you only want Claude to talk to you more plainly, one line in your instructions file is enough. If you ship strings that other machines read and want a check in CI, this repo is the more serious choice. For other skills that shape agent behaviour, see our reviews of Ponytail and Matt Pocock’s skills.

FAQ

What is asd-ste100-skill?

It is an MIT-licensed Claude Code skill by danyuchn. It rewrites ambiguous English into a loose form of ASD-STE100 Simplified Technical English and includes ste-lint.py, a deterministic linter for the structural rules. As of October 12, 2026, it has 4,623 GitHub stars.

Does it include the official ASD-STE100 dictionary?

No. ASD allows free download but restricts redistribution, so the skill applies the principle (the plainest word, used the same way every time) and treats dictionary rules as advisory.

Will it make my AI agent’s answers shorter?

Not necessarily. Tests of STE instructions by StashBase and Lucian Ghinda found much shorter sentences, but StashBase found total length about the same. Ghinda found that the strict standard made Claude drop facts when it explained code.

Can I use the linter without Claude Code?

Yes. scripts/ste-lint.py is a standalone Python script with no dependencies. It reads files or stdin, supports --json, --baseline and --disable, and exits 1 when hard violations exceed the baseline, so it fits a CI step or pre-commit hook.

Is it the same as AminBlg/SimpleEnglish?

No. Both appeared in July 2026 and apply the same standard. SimpleEnglish targets documentation and installs as a plugin. danyuchn’s skill targets text that machines read and adds the linter.

Verdict

asd-ste100-skill is small and knows it. Its value is not the aerospace branding but a clear set of rules for rewriting text without changing what it claims: keep hedges, add no facts, flag what you could not simplify. The linter is a reasonable first pass with known blind spots. Install it for the strings your agents and tools hand to each other; for everyday chat, one line of instruction does most of the job.