---
name: ste
description: Write or rewrite technical documentation in ASD-STE100 Simplified Technical English — the aerospace controlled language (53 rules + a one-word-one-meaning dictionary) that produces terse, unambiguous, non-AI-sounding prose. Use whenever the user says "STE", "simplified technical english", "ASD-STE100", "controlled language", asks for docs that "don't sound like AI", or wants procedures, runbooks, manuals, README instructions, API guides, or maintenance/operations documentation written to a strict clarity standard. Also use to AUDIT existing docs against STE and report violations.
---

# STE — Simplified Technical English (ASD-STE100)

Write technical documentation to the ASD-STE100 standard. STE exists so that a
non-native reader under time pressure (originally: an aircraft mechanic on a
night shift) cannot misread an instruction. Every rule below removes a way a
sentence can be misread. That same discipline is what makes prose sound
human-engineered instead of AI-generated: no hedging, no synonym rotation, no
filler.

Two modes:
- **Write/rewrite**: produce the document in STE.
- **Audit**: check a document against the rules below and list violations with
  rule references and suggested rewrites. Do not rewrite unless asked.

## First: classify each sentence

STE has different limits for the two kinds of text. Decide which one you are
writing before you write it.

| Kind | What it is | Limit |
|------|-----------|-------|
| **Procedural** | Tells the reader to do something | ≤ 20 words per sentence, ONE instruction per sentence |
| **Descriptive** | Explains what something is or why | ≤ 25 words per sentence |

## Verb rules (the core of STE)

- Use only these verb forms: **imperative** ("Remove the cover"), **simple
  present**, **simple past**, **simple future** ("will"), **infinitive**, and
  **past participle as an adjective only** ("the installed pump").
- Never use present perfect / past perfect ("has been", "had configured") —
  use simple past.
- Never use `-ing` verb forms ("configuring the server requires…",
  "when running the tests…"). Rewrite: "When you run the tests…". The `-ing`
  form is allowed only inside a technical name ("the operating system",
  "logging level").
- Active voice always in procedures. In descriptive text, passive is allowed
  only when the agent is unknown or irrelevant.
- Write instructions as commands: "Restart the service", not "The service
  should be restarted" or "You may want to restart the service".

## Sentence and paragraph rules

- One instruction per sentence. Split compound steps into numbered steps.
- Do not omit words to save space. Keep articles and verbs: "Install the
  package", not "Install package". Telegraphic style is a violation, not a
  virtue.
- Use "that" to introduce clauses after verbs like "make sure": "Make sure
  that the port is open."
- Use a vertical numbered list for any sequence of more than one step, and a
  bulleted list for more than about three parallel items in a sentence.
- One topic per paragraph. Maximum 6 sentences per paragraph. Start the
  paragraph with the topic sentence.
- Noun clusters: maximum 3 words. "The database connection pool timeout
  configuration value" → "the timeout value for the connection pool".
- Connect sentences with plain connectors (thus/then/but/because), not
  "furthermore", "additionally", "moreover", "it is worth noting that".

## Word rules

- **One word, one meaning, one part of speech.** Pick one term per concept and
  use it every time. Never rotate synonyms for variety — if you called it "the
  config file" once, it is "the config file" everywhere.
- Prefer the short common word. See `references/word-choices.md` for the
  replacement table (utilize→use, ensure→make sure, prior to→before, …). Read
  it before writing; it covers the words that most often leak in.
- Use a word only as its one part of speech: "test" the noun ("do a test"),
  not also "test" the verb — pick one usage per document and hold it.
- **Technical names are exempt.** API endpoints, commands, flags, error
  strings, product names, and domain nouns/verbs stay verbatim. STE controls
  the connecting language, not the terminology.

## Warnings, cautions, notes

- Put the warning BEFORE the step it protects, never after.
- Start with a command, then give the condition/reason: "Do not run the
  migration on the primary. Data loss will occur." — not "Note that running
  the migration on the primary could potentially lead to data loss."
- A warning is one short command plus at most one short reason. No hedging
  ("could potentially", "may in some cases").

## Anti-slop enforcement (why this works)

These are the STE rules doing double duty against AI-sounding prose — apply
them ruthlessly:

- No hedging stacks: "may potentially", "can help to", "is designed to
  provide" → state the fact or the command.
- No throat-clearing openers: "In this section, we will explore…" → start
  with the first fact or step.
- No nominalizations: "perform the installation of" → "install".
- No empty intensifiers: "seamlessly", "robust", "powerful", "comprehensive",
  "simply", "easily" — delete; if the claim matters, state the measurable
  fact instead.
- No summary paragraphs that restate what was just said.

## Document shape

STE fixes the sentences; these rules fix the document so a distracted reader
can act on it (adapted from the i-have-adhd output style):

- Start a how-to document with the first action or the prerequisite command,
  not with background. Put explanation after the procedure it explains.
- Number every multi-step procedure. One bounded action per step.
- Cap lists at about 5 items; past that, split into "do now" / "later" or
  regroup under headings.
- State prerequisites before step 1, never mid-procedure ("you should have
  already…" is a failure).
- End a procedure with the check that proves it worked ("Run X. The output
  is Y."), not with a summary.

## Output format

- **The standard is invisible in the deliverable.** Never write that the
  document follows, conforms to, or "is written in" STE/ASD-STE100, and never
  add disclaimers about certification or compliance. STE is how you write,
  not a fact about the document. The reader should only notice that the text
  is clear. Mention the standard only when the user asks about it, or in the
  header of an explicitly requested audit report.
- Deliver the document; do not narrate what you did.
- On request ("audit", "check against STE"), output a violations table:
  `line/quote | rule broken | suggested rewrite`.
- STE was written for aerospace maintenance manuals. For software docs, apply
  the rules pragmatically: the sentence/verb/word rules transfer verbatim;
  code blocks, identifiers, and CLI output are technical names and are exempt.

## Example rewrite

Before (typical AI output, 41 words):
> Before proceeding with the deployment process, it is important to ensure
> that all of the required environment variables have been properly
> configured, as failing to do so could potentially result in the
> application encountering unexpected runtime errors.

After (STE):
> Make sure that all required environment variables are set before you
> deploy. If a variable is missing, the application will fail at runtime.