SimpleEnglish: an Agent Skill that makes LLMs write like a Boeing manual
Agent skill: make LLMs write docs in ASD-STE100 Simplified Technical
At a glance
- What is it?
- SimpleEnglish is an MIT-licensed agent skill that pushes chat replies and technical documents toward ASD-STE100 Simplified Technical English. The README reports large drops in formatting defects and linter violations, but the project's own audit says the linter numbers measure rule obedience, not reader comprehension.
- Who is it for?
- Adopt SimpleEnglish if you generate runbooks, error messages, release notes or READMEs with an agent and you want a mechanical, checkable style instead of a house style guide nobody reads. Do not adopt it for marketing copy, narrative documentation, or any text where tone and rhythm matter more than parseability; the five-sentence reply cap and the ban on headers will fight you.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is register drift, not grammar
Ask a model for a runbook and you get a LinkedIn post with numbered steps buried inside it. The README states the failure mode directly: the model writes like a LinkedIn post, and the skill makes it write like a Boeing manual. The target is ASD-STE100 Simplified Technical English, a controlled language aerospace has used since 1983 so that a tired mechanic cannot misread an instruction. The README's before-and-after table makes the difference concrete. Without the skill, a passage reads: "Leveraging sqlpipe's robust architecture, users can seamlessly synchronize their Postgres tables to S3 with minimal configuration overhead." With the skill, the same model writes: "sqlpipe copies your Postgres tables to S3. It needs one configuration file." The second version drops the abstraction and names the actor. That is the whole product. It is for engineers who generate documentation with an agent and want the output to be parseable by someone under time pressure, not for anyone who wants the model to sound more human.
Two registers: chat replies and documents
The skill splits behaviour by output type, and this is the design decision that matters most. Replies get a hard five-sentence maximum, prose only, no headers, bullets, bold or tables, the first sentence answers the question, and no contractions, openers or closers. Documents get a different set: maximum 20 words per instruction and 25 per description, condition before command so readers do not execute a step before reaching the qualifier, simple tenses and active voice. The rules live in SKILL.md at roughly 1,700 tokens, and the 53 numbered rules of Issue 9 sit in rule-catalog.md for check mode and Strict mode. The README describes the default as layman-readable, with STE-strict on request. That two-register split is why the skill is not simply a style prompt. A single prompt that bans bullets and caps sentences would wreck a 3,000-word migration guide; a single prompt that allows bullets would let the model answer "is that bad?" with a 240-word essay and a table. The cost is that you now have two mental models for what the skill will do, and the reply register is aggressive enough to be wrong for some conversations.
Install paths and what actually runs
The README gives four routes. With the skills CLI: npx skills add AminBlg/SimpleEnglish. For Claude Code, with the session hook and the output style: claude plugin marketplace add AminBlg/SimpleEnglish && claude plugin install simple-english@simple-english. The output style is named simple-english:simple-english and the README warns that the short name does not resolve; select it with /config under Output style, or put {"outputStyle": "simple-english:simple-english"} in ~/.claude/settings.json. For Codex: codex plugin marketplace add AminBlg/SimpleEnglish followed by codex plugin add simple-english@simple-english, and Codex asks you to trust the hook before its first run. The hooks need Node.js, with details in src/hooks/README.md. If your agent does not support skills, paste the rule block from prompts/system-prompt.md into your system prompt, AGENTS.md, or .cursorrules; the README says that page ends with a 60-token version for tight budgets. Note the asymmetry: the skill folder itself has no dependencies, but two of the four install paths pull in a session hook and therefore a Node.js runtime. The plain skills CLI route does not.
What the benchmark numbers do and do not show
The README is unusually candid about its own measurements, and that candour is the most useful part of it. Replies: 8 chat questions with a jargon term each, two runs, 16 replies total. The table reports 86% fewer visible defects with 2.0.1 than with no skill, 406 down to 58, where defects are over-cap sentences, em-dashes, bold, headers and bullets. The raw counts show em-dashes falling from 62 to 5, bold from 79 to 2, headers from 25 to 0. Documents: the 8 sqlpipe writing tasks scored with an STE linter, violations per 100 words falling from 4.09 with no skill to 0.91 with 2.0.1. Two caveats are stated in the README and both matter. First, the document table is one run per cell and one run moves by about 0.5 on that model, so the README says to read the rows as parity or better, not as a ranking. Second, judges are Claude models on Claude text, so family bias is possible. The project also links a 2026-09-02 audit titled WHY-USELESS-2026-09-02.md which concluded that the older 81.3% linter figure measured rule obedience, not what a reader sees. That is why 2.0.1 reports reply defect counts instead. A project that publishes the audit that invalidates its own headline metric is telling you how to read the rest of its numbers.
The five-sentence cap does not always hold
The README reports that the five-sentence cap holds in 5 of 16 sonnet replies. On gpt-4.1-mini, the same 8 questions went from 23 sentences, 64 bold spans and 101 bullets per 8 replies to 5.2 sentences and zero formatting, with 6 of 8 under the cap. Read those two sentences together. On one model the cap fails in roughly two thirds of replies; on another it holds in three quarters. Compliance is model-dependent, and the README does not claim otherwise. If your workflow depends on hard sentence limits, you cannot assume the skill enforces them, and you should measure on your own model before you rely on it. The same applies to the document rules: the linter is the check, and the linter counts violations, not reader outcomes. The project's own audit says as much. Treat the skill as a strong prior on style, not a validator. If you need a guarantee, you need the linter in CI, which is what the project does with evals/check_numbers.py.
Where a style guide or Vale fits better
The obvious alternative is a prose linter wired into CI, for example Vale with a custom rule set, or a house style guide plus a review step. The difference in approach is where the constraint lives. SimpleEnglish constrains generation: the rules are in the model's context before the first token, so the model never produces the em-dash and nothing has to be rewritten. A linter constrains the artifact: the model writes whatever it wants and the linter fails the build, which means a human or a second model pass fixes it. Generation-time constraints are cheaper per document and useless for text you did not generate. Artifact-time constraints catch human writing too, and they are the only option if your documents come from several sources. There is a second difference. STE's rules are numbered and finite, 53 of them in Issue 9, which is why they fit in a prompt at all. A house style guide is usually longer, more situational, and harder to encode, which is exactly why teams end up with a guide nobody applies. SimpleEnglish is the narrow case that happens to be encodable.
Maintenance, licence and the hook you have to trust
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained; this is a description of the licence text, not legal advice, and you should read LICENSE yourself. Maintenance signals in the supplied material: the default branch is main, the repository is not archived, the last push and the v2.0.2 release both fall on 2026-09-08, and the release history shows v1.2.0 in August, v2.0.0 on 2026-09-01 with the note "plain English by default", then 2.0.1 and 2.0.2 within a week. That cadence suggests active iteration on the rule set, which has a cost: rule text and benchmark tables move together, so a pinned version is safer than tracking main if you depend on specific behaviour. The upgrade surface is small, one skill folder plus references, but the plugin paths add a session hook that runs on every session and needs Node.js. The README says Codex asks you to trust the hook before its first run; that prompt is the moment to read src/hooks/README.md rather than click through. The MIT grant covers the repository's code and text, not the ASD-STE100 specification itself, which is published separately by ASD and has its own terms.
Who should load it, and what to check first
The fit is narrow and clear. You generate technical text with an agent, you want it short and literal, and you would rather prevent bad style than repair it. Runbooks, error messages, release notes, READMEs and incident reports are the cases the README names. The mismatch is equally clear. Marketing pages, tutorials that need narrative momentum, and any document where the reader is meant to enjoy the prose will suffer under a five-sentence cap and a ban on headers. The reply register also assumes the user wants the answer first and nothing else, which is wrong for brainstorming, where a list of options is the answer. Before adopting, confirm that your agent reads the Agent Skills standard, because the paste-into-system-prompt path is a different product with no hook and no output style. Then run the 8-question reply test on your own model, since the cap held in 5 of 16 sonnet replies in the project's own numbers. Then decide whether you want the hook: the skills CLI route avoids Node.js entirely, and for many teams that is the whole decision.
Editorial conclusion
Adopt SimpleEnglish if you generate runbooks, error messages, release notes or READMEs with an agent and you want a mechanical, checkable style instead of a house style guide nobody reads. Do not adopt it for marketing copy, narrative documentation, or any text where tone and rhythm matter more than parseability; the five-sentence reply cap and the ban on headers will fight you. Before you commit, verify three things: that your agent reads the Agent Skills standard at all (otherwise you are pasting prompts/system-prompt.md by hand), that the five-sentence cap holds on your model, since the README reports it holding in only 5 of 16 sonnet replies, and that you accept the MIT terms plus whatever the hooks execute, because the Codex plugin asks you to trust the hook before its first run.
Community notes