simplified_technical_english v1.0.0

name: "simplified_technical_english" description: "Write and rewrite technical documentation in Simplified Technical English (ASD-STE100): the controlled dictionary principle of one word, one meaning, one part of speech, the core sentence and verb rules, a step by step rewrite method for procedures, descriptions, and warnings, and a no-software check with a bundled mechanical checker script. Triggers on requests to write in STE or ASD-STE100, simplify a procedure or warning, make documentation readable for second language readers, reduce ambiguity in instructions, or check a document against controlled language rules." metadata: { "includeInPrompt": true }

Simplified Technical English

Purpose

Write technical documentation that a reader can interpret in only one way. Simplified Technical English (STE) is the controlled language defined in ASD-STE100, maintained by ASD through its STEMG maintenance group. Issue 9 of the specification is dated 15 January 2025. STE was built for aircraft maintenance manuals, where many readers use English as a second language and a misread step can cause damage or injury. The same rules work for any procedure, warning, or product document where one wrong reading has a real cost.

STE has two parts. Part 1 gives 53 writing rules in 9 sections. Part 2 is a dictionary: each approved word has one approved meaning and, with stated exceptions, one approved part of speech, and words that are not approved are listed with an approved alternative. This skill teaches the core rule set and the rewrite method. It does not reproduce the full dictionary, and it does not certify compliance. For work that must comply with ASD-STE100, get the specification itself. ASD has distributed it free of charge since Issue 6.

Workflow

1. Sort the text. Mark each block as procedure (steps the reader does), description (facts about a thing), or safety instruction (warning or caution). The limits differ: a procedural sentence has a maximum of 20 words, a descriptive sentence a maximum of 25 words, and a paragraph a maximum of 6 sentences.

1. Fix the words first. Read references/core-rules.md. For each content word, ask three questions. Is this word approved? Do I use it in its approved part of speech? Do I use it with its approved meaning? Replace failures with the dictionary pattern: "follow" means only "come after", so write "obey" for instructions; "test" is a noun, so write "Do the leak test"; "acceptable" is not approved, so write "permitted". Keep one word for one thing in the whole document. Do not rotate synonyms for variety.

1. Fix the verbs. Keep only the approved forms: infinitive, imperative, simple present, simple past, simple future, and the past participle only as an adjective. Remove the present perfect and rewrite it in the simple past. Remove the -ing form unless it is part of a technical name. Put the action in a verb, not in a noun made from a verb.

1. Fix the voice. In procedures, write the active voice and start each step with the command verb. A step names no actor because the reader is the actor: "Remove the cover." In descriptions, use the active voice and name the actor. Use the passive only when the actor is unknown or does not matter, and say so in your delivery notes.

1. Split the sentences. One instruction per sentence. Two instructions can share a sentence only when the actions occur at the same time. One topic per descriptive sentence. Do not drop the subject, the verb, or articles to save words. Remove semicolons and split at that point instead.

1. Break the noun clusters. A noun cluster has a maximum of three words. For a long technical name, hyphenate to show the structure, explain the name in words one time, or define a short name and use that short name in the rest of the document.

1. Rebuild the paragraphs. One topic per paragraph, maximum six sentences. Put the steps in the order the reader does them. Put a condition before the instruction it applies to. Use a vertical list for a set of conditions, results, or values.

1. Rewrite the safety instructions. Put the warning or caution before the step it belongs to. Start it with a clear command, then state the hazard and the result if the reader does not obey, in short sentences. Do not put the command after an explanation. Worked form: "WARNING: Disconnect the power supply before you start this procedure. Electrical power can kill you."

1. Run the checker. Run python3 scripts/ste_check.py <file> --mode procedure for procedures or --mode description for descriptive text. It reports sentence length over the limit, paragraphs over six sentences, semicolons, contractions, possible passive voice, sentences that start with an -ing form, and a starter list of words that are not approved, with their approved alternatives. Fix every finding or record why it stands.

1. Read for meaning one time. The checker cannot see meaning. Read the result and ask of each sentence: can a tired reader, or a reader with basic English, read this in a second way? If yes, rewrite that sentence. Compare the rewrite against the original fact by fact. A rewrite that changes a value, a condition, or a sequence is wrong even if every rule passes.

Study references/rewrite-examples.md before your first rewrite. It has five before and after examples, and the full procedure rewrite in it passes the bundled checker with no findings.

Output Contract

Deliver:

• The rewritten or new text, in STE style, with procedures as numbered steps and safety instructions placed before the steps they belong to.
• A change log with one line per material change: the original wording, the new wording, and the rule it follows (word, verb, voice, sentence, noun cluster, paragraph, or safety).
• The checker output for the final text, or a statement of each finding you left in place and why.
• A short list of terms you treated as Technical Names or Technical Verbs for this document, so the user can approve them and reuse them in the next document.
• A plain statement of scope: this text follows the core STE rules in this skill. It is not certified ASD-STE100 compliance unless the words were checked against the full specification dictionary.

Operating Rules

1. Accuracy first. Never change a fact, value, unit, condition, or sequence during a rewrite. If the original is ambiguous about a fact, flag it for the user instead of picking a reading. A clear sentence with a wrong fact is worse than a hard sentence with the right one.
2. One word, one meaning, one part of speech. If you cannot verify that a word is approved in the STE dictionary, prefer a plain word with one common meaning and note the choice in the change log. Never present a word as dictionary approved when you did not check it.
3. The word limits are maximums, not targets. A 9 word step that says the whole action beats a 20 word step that says it with decoration.
4. Safety text outranks style. If a rule and a clear hazard statement conflict, keep the hazard statement clear and note the conflict.
5. Do not shorten by deletion of content. STE removes ambiguity, not information. If a sentence carries a condition, a limit, or an exception, the rewrite carries it too, in its own sentence if necessary.
6. Keep the user's defined Technical Names and Technical Verbs consistent. Propose new ones in the delivery list, never silently mid-document.
7. The checker is a floor, not a verdict. Report its output honestly. A clean checker run plus your meaning read is the standard for delivery, and both are stated in the output.