Can a Flight-Manual Writing Skill Fix AI Slop? A Review of Simplified Technical English

An Instagram reel makes an appealing claim: the cure for verbose AI writing is a technical-English standard used for aircraft maintenance manuals. Its author, Johann Sathianathen, has packaged those principles as a free agent skill. [5]

I traced the tool to jsath/simplified-technical-english and inspected the actual instructions, not just the promotional caption. [1][2]

My conclusion: useful as an optional editor for English documentation, but not a universal cure for weak AI output. It can make procedures easier to read. It cannot verify facts, certify compliance with a standard, or guarantee that a rewrite preserves every important condition.

What the tool actually is

At the reviewed revision, 6d995db, the repository contains three tracked files: a README, an MIT license, and skills/technical-english/SKILL.md. There is no application server, inference model, automated word-counting script, or test suite in that revision. This is a source-audit finding, not a runtime benchmark. [1][2][6]

The skill tells an existing language-model agent how to edit text. Its main rules include:

Keep instructions to 20 words per sentence and descriptions to 25.
Put one instruction in each sentence and use numbered steps for sequences.
Prefer active voice and direct commands for instructions.
Replace inflated wording with simpler alternatives.
Remove a list of phrases associated with generic AI prose.
Preserve facts, code, commands, quotations, and error messages. [2]

It offers Rewrite, Audit, and Light modes. Audit returns findings without rewriting. Light applies a smaller set of rules to copy whose voice should be preserved. [1][2]

That last distinction is important. A deployment procedure, a personal essay, and a product announcement should not all sound like maintenance instructions.

Is the aviation-standard story real?

Yes. The official ASD site describes ASD-STE100 Simplified Technical English as a controlled language for technical documentation. Development began in the late 1970s, and the first AECMA Simplified English Guide was released in 1986. The original goal was to make aircraft maintenance documentation easier to understand for readers with basic English. [3]

The official Issue 9 supports several of the skill’s central ideas: a 20-word limit for procedural sentences, a 25-word limit for descriptive sentences, imperative instructions, consistent technical terms, and paragraphs limited to one topic. [4]

But the community skill is not the standard. It explicitly says that it is STE-inspired, not the official specification. The full standard includes vocabulary rules and permitted technical terminology that a short substitution table cannot replace. [2][4]

The repository’s MIT license applies to its own material. It does not turn ASD’s copyrighted standard and dictionary into MIT-licensed content. [3][4][6]

Where it is genuinely useful

The following are engineering recommendations based on the reviewed rules, not measured claims about this skill’s performance.

1. Runbooks and troubleshooting guides

Procedures benefit from clear actions, named components, and explicit prerequisites. Instead of asking an agent to “make this sound professional,” ask it to identify ambiguity before it rewrites anything.

For example, an editor could turn this deliberately wordy instruction:

Before initiating a restart of the worker service, ensure that the pending queue has been fully drained.

Into:

Before you restart the worker service, make sure the pending queue is empty.

The important feature is not merely brevity. The queue condition remains before the restart. A shorter version that removes that condition would be worse.

2. READMEs and onboarding instructions

It can help separate prerequisites, installation steps, and expected results. It is especially worth trying when an English-language document serves an international team.

However, commands and identifiers must remain exact. “Plain English” is not permission to rename a flag, normalize a file path, or paraphrase an error message.

3. API documentation and support replies

Consistent terms can reduce confusion. Calling the same entity “workspace,” “account,” and “organization” in consecutive paragraphs may create ambiguity even when every sentence is short.

Use the skill with your own glossary. For example, tenant, transaction, token, and request need their domain meanings, not whatever everyday synonym appears simpler.

4. Agent-to-agent handoffs

A clear handoff should distinguish observations, assumptions, constraints, and next actions. Short sentences can help, but structured schemas and validated fields are stronger controls when software will consume the result.

Treat language editing as one layer of reliability, not as a replacement for validation.

The limitations I found in the source

1. Its “hard limits” are instructions to the model, not executable enforcement

The skill repeatedly tells the agent to count words and fix violations. The reviewed repository does not include code that performs that count independently. [2]

That makes the rules advisory in practice: the model can miscount or overlook a sentence. If a team requires a measurable limit, add a separate checker and define how it counts words. A length checker still will not prove factual correctness or full STE compliance.

2. Its own example needs more careful arithmetic

I counted the README’s before-and-after example with Python, using whitespace-separated words:

Before: 41 words in one sentence.
After: 19 words, with sentence counts of 9, 5, and 5.
Reduction: 53.7% in that example.

The example’s labels instead describe a 44-word original and an 11-word longest rewritten sentence, and say the rewrite uses a third of the words. Those descriptions do not match this simple count. [1][2]

This does not mean the rewrite is useless. It is substantially shorter. It means the example should not be treated as evidence of reliable counting, a measured token saving, or guaranteed semantic preservation.

These are counts of the author’s supplied example, not results from a fresh model run. Word reduction is also not the same metric as token reduction.

3. One blanket rule is weaker than the official standard’s conditional guidance

The skill’s warning section says to place the command first and then the condition. Official Rule 5.4 says that when the reader needs to know a condition first, the instruction should begin with that condition. [2][4]

These should not be collapsed into a universal “command first” rule. Preconditions, warnings, and exceptions need judgment. In safety-relevant instructions, use the official standard and a qualified reviewer rather than relying on this summary.

4. “Delete on sight” is too broad for technical terms

The blocklist and substitution table are convenient for removing filler. But words do not become meaningless merely because AI systems overuse them. [2]

As an engineering example, “terminate a process,” “stop a service,” and “pause a job” may describe different operations. Replacing all of them with a simpler verb can hide a distinction.

Likewise, removing a qualification such as “may fail” can turn an honest uncertainty into an unsupported certainty. Preserve necessary caveats even when they make a sentence longer.

5. Shorter writing is not automatically correct writing

A concise sentence can still contain a wrong price, unsafe command, invented benchmark, or missing exception. The skill asks the agent to preserve facts and avoid inventing them, but it supplies no independent fact-checking mechanism. [2]

A useful editorial review must ask two separate questions:

Is this easier to understand?
Does it still say exactly what the source supports?

6. English guidance is not an Arabic-writing standard

ASD-STE100 is an English-language standard. This skill targets English prose. [2][3]

For Arabic posts, we can borrow principles such as clear references, consistent terminology, and short instructions. We should not present those adaptations as formal STE compliance or apply English vocabulary rules mechanically to Arabic.

7. It has costs and privacy boundaries despite being free

The repository is MIT-licensed; the agent that applies it may still consume a paid plan or API tokens. [6]

The skill’s audited file is an instruction document, not a data-protection boundary. If the host agent uses a cloud provider, editing confidential documents may send their contents to that provider under its configured settings. Use approved accounts, remove secrets, and check organizational policy before processing client material.

Start with a non-sensitive document and Audit mode. Do not make the full rewrite policy a global default for every kind of writing.

The repository documents this Claude Code installation: [1]

git clone https://github.com/jsath/simplified-technical-english.git
mkdir -p ~/.claude/skills
cp -r simplified-technical-english/skills/technical-english ~/.claude/skills/

If that destination already exists, inspect it before copying. Keep your local changes rather than overwriting them without review.

Inside Claude Code, begin with:

/technical-english audit: docs/deployment-runbook.md

Then give a bounded editing request:

Rewrite docs/deployment-runbook.md for an international engineering team.

Preserve every fact, condition, exception, warning, and uncertainty.
Preserve commands, paths, flags, identifiers, and error messages exactly.
Keep prerequisites before actions when readers need to know them first.
Use our glossary: tenant, workspace, transaction, rollback.
Do not invent missing steps. Flag them for review.

Show the diff and a list of possible meaning changes.
Do not commit or publish the result.

For a product announcement, explicitly ask for Light mode so the editor does not flatten the author’s voice. This mode is documented in the skill. [2]

After a rewrite, inspect the diff. Count sentence lengths with a tool if the limit matters. For a runbook, also test commands in a safe environment and check that warnings and preconditions survived.

There is no dedicated Docker image or systemd deployment in the reviewed repository. This is a skill loaded by an agent, not a service that needs its own VPS. [1][2]

Comparison with a general humanizing pass

My editorial distinction is straightforward:

STE-inspired editing: best when the goal is precise instructions, consistent terminology, and less ambiguous English.
General humanizing: best when the goal includes natural rhythm, personality, varied sentences, and an identifiable author.
Fact-checking and domain review: required separately when accuracy or operational safety matters.

A document may need all three, but they are not interchangeable.

Final verdict

Yes, this tool has a useful idea and a low-friction implementation. I would use it selectively for English READMEs, runbooks, onboarding material, and support documentation.

I would not treat it as an automatic cure for AI slop, a compliance checker, or a safety guarantee. Its strongest contribution is a reusable editing checklist. Its biggest weaknesses are reliance on the same model to enforce its rules, broad substitutions, and the risk of confusing brevity with correctness.

For our content workflow, the sensible approach is to borrow its clarity rules while preserving voice, citations, qualifications, and Arabic fluency. Use it as an editor—not as the final judge.

Verification scope

This review used the reel’s retrieved caption, visual frames, the author’s matching repository, and the official standard. I inspected the three tracked repository files and ran a Python count on its example. I did not run a controlled before/after LLM benchmark, test reader comprehension, or certify any document against ASD-STE100.