Simplified Technical English Rewriter

---
name: simplified-technical-english
description: Use when writing or rewriting technical text — documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports — under ASD-STE100 Simplified Technical English. Triggers on "STE", "Simplified Technical English", "ASD-STE100", "write for non-native readers", "make these docs translate well", or a request to de-slop technical documentation.
---

# Simplified Technical English Rewriter

Rewrite technical text under ASD-STE100, the controlled language behind aerospace maintenance manuals. The target reader is tired, is not a native English speaker, and will not read the sentence twice. Protocol distilled from AminBlg/SimpleEnglish (v1.2.0); the official standard is a free download at asd-ste100.org.

## Pick the mode, then classify every passage

**Pragmatic mode** (default) applies the structural rules and keeps domain vocabulary ("webhook", "idempotent", "endpoint") legal as technical nouns and verbs. **Strict mode** applies full vocabulary discipline and is only for users who name STE or compliance; tell them full compliance needs the official ASD dictionary.

Then classify each passage, because every other rule keys off this:

| | Procedural | Descriptive |
|---|---|---|
| Purpose | Tell the reader what to do | Explain what a thing is or does |
| Verb form | Imperative: "Install the pump." | Simple present, past, or future |
| Sentence limit | 20 words | 25 words |
| Unit rule | One instruction per sentence | One topic per paragraph, max six sentences |

A "Getting started" section is procedural. An "Architecture" section is descriptive. Never mix the two forms inside one passage.

## The rules that do the work

1. **One word, one meaning.** Before drafting, pick one word for each contested concept and hold it for the whole document: one of check/verify/confirm ("make sure that" in strict mode), one of config/configuration/settings, one of run/execute. Synonym rotation is both an STE violation and the loudest AI tell.
2. **The modal ladder.** "Should" as a requirement becomes "must"; "should" as a recommendation becomes a stated fact or gets deleted. "May", "might", and "could" become "can". "Would" restructures into "If X occurs, Y occurs." This matters double in agent instructions, where a model reads "should" as optional.
3. **Condition before command, divided by a comma.** "Increase the timeout if the network is slow" becomes "If the network is slow, increase the timeout."
4. **Simple tenses, active voice.** No present perfect ("has been deployed" becomes "is deployed" or "we deployed it on May 3"), no "-ing" verb forms, no verb chains. Passive voice is legal only in descriptive text when the agent is unknown.
5. **Complete grammar, short sentences.** STE is not telegraph style: keep articles and keep "that". "Ensure file exists before running" is wrong twice; "Make sure that the file exists before you run the command" is STE.
6. **Verbs, not nominalizations.** "Compress the file", never "perform compression of the file".
7. **Warnings lead with the command.** Risk framing follows the imperative: "CAUTION: Do not use the --force flag against production. The flag deletes rows that do not match the source." Never bury the instruction after the explanation.
8. **No semicolons.** Write two sentences.

## Word-count mechanics that save your budget

Quoted text, inline code, alphanumeric identifiers, numbers with units, and hyphenated words each count as ONE word. A long CLI invocation in backticks does not blow the 20-word limit, so there is no excuse for dropping articles around it.

## Untouchables

Leave these exact, even where they violate vocabulary rules: code blocks, inline code, identifiers, CLI commands and flags, file paths, quoted error messages and log lines, product names, API endpoint names, config keys.

## The de-slop substitution layer

On top of the standard, replace or delete the words AI drafts overuse: "leverage/utilize" become "use", "in order to" becomes "to", "prior to" becomes "before", "when it comes to" becomes "for", "due to the fact that" becomes "because". Delete outright: "simply", "seamlessly", "it is worth noting that", "robust", "comprehensive", "is designed to", "dive into". If the word carries no fact, deletion beats replacement. "Gracefully handles errors" becomes what the code does: "retries three times, then stops".

## Self-check before delivery (not optional)

1. Count the words in your three longest sentences; split any over the 20/25 limit.
2. Search the draft for contractions, "has been", "have been", "should", semicolons, and "-ing" verbs after a comma.
3. Find every "if" and "when"; each one must stand at the start of its sentence, before the command.
4. Search for the synonyms you did not pick in the vocabulary step and replace every hit with the chosen word.

## Check mode

When asked to audit text instead of writing it, report each violation as: the offending text, what rule class it breaks (sentence limit, banned modal, condition order, vocabulary rotation, banned verb form), and a compliant rewrite. Do not cite ASD rule numbers from memory; models invent them.

## Scope limit

STE is for technical facts and instructions. If the user points it at marketing or brand copy, say that STE deletes persuasion by design and offer to apply it to their documentation instead.