danyuchn/asd-ste100-skill: ASD-STE100 Simplified Technical English as a Claude Code Skill

The reader this skill writes for is a model, not a mechanic

ASD-STE100 Simplified Technical English was built so that aircraft maintenance instructions cannot be misread by a non-native speaker with no author to call. The README states the standard's fix plainly: one meaning per word, active voice, simple tenses, one instruction per sentence, short sentences, no dropped words. This project takes that discipline and points it at a different reader. The target is an AI agent parsing another agent's output, a tool description, an error message, or an inter-agent instruction, with no back-channel to ask what a phrase meant. That framing is the whole justification for the skill, and it holds up. A downstream model cannot ask a clarifying question. It resolves ambiguity by guessing, and it guesses from the same distribution that produced the ambiguity. The people who benefit are the ones writing the strings a model reads: tool schemas, failure messages, handoff prompts. It is not a general prose editor and it is not aimed at human documentation sites.

Two modes, five steps, and a rewrite that must not drop qualifiers

The skill runs a fixed sequence. It picks a mode first. Strict covers procedures, error messages and tool descriptions. STE-flavored covers READMEs, PR descriptions and explanatory prose, and keeps the sentence discipline without the fixed-vocabulary lockdown. Then it reads the input for meaning, flags violations sentence by sentence, and rewrites each flagged sentence. The flagged categories are listed in the README: ambiguous word choice, present-perfect and complex tense, passive voice with an unclear actor, multi-instruction sentences, oversized noun clusters, dropped words, sentences over length, phrasal verbs, nominalized actions, semicolons, hedge stacks and marketing adjectives.

The constraint that matters is the fourth step. The rewrite must not drop any fact, condition or scope qualifier. When a shorter phrasing would lose required precision, the README says the skill keeps the longer phrasing and flags the trade-off instead of simplifying silently. Output is the rewritten text alone, with no preamble, no mode announcement and no change summary, plus a one-line Kept as-is: note when something was deliberately left unsimplified. Ask for the reasoning and it produces a before/after table naming each rule. That output discipline is the design choice worth noting: a rewriting tool that also explains itself doubles the tokens the caller pays for, so the default is silence.

Installing the skill with npx and a first rewrite

The README gives two install paths. The quick one uses the skills CLI and needs no clone or path setup. Run it from your project root:

npx skills add danyuchn/asd-ste100-skill

The README states this pulls the skill from the GitHub repo and installs it for the current project. It also states the CLI sends anonymous install telemetry (skill name and timestamp, no personal or device information) to rank skills on the skills.sh leaderboard, and that setting DISABLE_TELEMETRY=1 opts out. Update later with npx skills update.

The second path is a clone into the Claude Code skills directory, which makes the skill available in every project:

git clone https://github.com/danyuchn/asd-ste100-skill ~/.claude/skills/asd-ste100

With the skill installed, trigger it by asking for a simplification or a clarification. The README's usage section shows prompts of this shape:

Disambiguate this tool description
Rewrite this error message so an agent

What you should see is the rewritten text by itself. No mode banner, no list of changes. If the skill left a sentence long on purpose, a single Kept as-is: line follows it. Ask for show the diff or which rules did it break and you get the before/after table instead.

The linter is deterministic, and deliberately narrow

scripts/ste-lint.py is the mechanical half. The README states it checks semicolons, phrasal verbs, nominalizations, marketing adjectives, passive voice, present-perfect forms, long sentences, synonym rotation, and dangling conjunctions in supported list items. It never flags hedges or modality. You can run it against a file directly:

python scripts/ste-lint.py examples/linter-edge-cases.md

The README states this reports two expected findings, and that the file is a test fixture with intentionally invalid Markdown list items, not a model of compliant STE prose. The dangling-conjunction rule is the most specified part of the project. It looks at list markers at the start of a line with zero to three leading spaces and ASCII spaces after the marker. It supports the unordered markers -, * and +, and ordered numeric markers ending in . or ), such as 1. or 1). It checks indented continuation lines up to the final meaningful line. It does not parse list syntax inside blockquotes, lazy continuation, or full nested-list semantics. A standalone line with four or more leading spaces is not treated as a list marker. Inside an active list item, indentation at the computed content column counts as continuation text. Fence detection is equally simple: a stripped line beginning with three backticks or three tildes toggles the fence state. Those boundaries are documented, which is better than most linters manage, but they are boundaries. Anything that relies on nested list semantics or blockquote list syntax will pass unchecked.

No approved dictionary, so the interesting rules are advisory

The README is direct about the largest limitation. The skill does not reproduce ASD's official roughly 900-word approved dictionary. Issue 9 permits reproduction only with ASD's written authority, or by eight listed categories of organisation that this project does not belong to. So the skill applies the underlying principle, plainest available word used the same way every time, rather than checking against a fixed word list. That means the rules depending on ASD's dictionary are flagged as advisory rather than enforced, and the rules that need taste are left to the user.

The linter is narrower still. The README states it checks structural patterns only. It does not compare an original text with a rewrite, verify that requirement strength stayed the same, or prove that the rewrite preserved meaning. A zero-violation result means the configured structural checks found no problems. It does not mean the text is compliant, and it does not mean the rewrite is faithful. If you need certified STE-compliant documentation, the README says to use the real standard. This is the wrong tool for a compliance deliverable, and the project says so itself.

Where this sits next to a general-purpose prose linter

Vale is the obvious alternative, and the difference is in what gets checked. Vale is a configurable prose linter that runs style rules against a markup-aware parser, with rule packages you write or install and a vocabulary system you populate yourself. It knows nothing about ASD-STE100 out of the box, and it will not rewrite anything. You get a report, and you fix the text.

This project inverts that. The rewriting is the product, and the linter is the supporting check. The rule set is fixed to STE's structural categories rather than configurable, which is a real cost if your house style disagrees with STE on, say, semicolons or passive voice. The upside is that you do not have to author rules before the tool does anything useful. Pick Vale when you want a CI gate with your own rules and you intend to edit by hand. Pick this skill when the text being written is consumed by a model and you want the rewrite produced, not just flagged.

Maintenance, licence, and what the repository layout tells you

The repository is not archived. The last push was on 2026-09-08, nine days before this writing, so the checkout is current. There are no retrieved releases, which means installation is from the default branch master and there is no tagged version to pin. That is the upgrade cost in practice: npx skills update or git pull moves you to whatever is on master, and the README documents no rollback path and no version pinning. The linter's behaviour is specified in prose in the README rather than in a versioned changelog, so a change to the dangling-conjunction rule would be visible as a README edit, not as a release note.

The licence is MIT, which covers the code in this repository. It does not cover ASD-STE100 itself. The README states the standard is free to obtain but not free to redistribute, and that Issue 9 permits reproduction only with ASD's written authority or by eight listed categories of organisation the project does not belong to. MIT on this repo therefore gives you no rights to the standard's word list. If your use case depends on the approved dictionary, the licence question and the technical question point the same way: get the standard from ASD.

Editorial conclusion

Adopt it if you write tool descriptions, error messages or inter-agent instructions that another model must parse without a human to resolve ambiguity, and if you accept that the linter checks structure only. Do not adopt it if you need certified ASD-STE100 compliance, because the README states the project does not reproduce the official approved dictionary. Before you rely on it, run python scripts/ste-lint.py examples/linter-edge-cases.md and confirm the two expected findings appear, then check references/writing-rules.md for the rule set you are actually getting.

Frequently asked questions

Official sources

1. danyuchn/asd-ste100-skill on GitHub
2. Issues
3. License: MIT
4. README