/humanizer-en-asd-ste100

name: humanizer-en-asd-ste100
description: "Write or rewrite English into ASD-STE100 Simplified Technical English and strip AI artifacts (decorative emojis, Markdown residue) from technical documentation — maintenance manuals, procedures, medical device instructions, and API docs read by non-native speakers or machine translation. Enforces approved word meanings, technical noun and verb categories, the 20/25-word sentence limits, banned verb tenses, and passive-voice restrictions. Trigger on simplified technical english, STE, ASD-STE100, controlled language, translation-ready docs, de-slop this manual. Do NOT use for marketing copy, brand voice, or narrative writing; for French text use samber/cc-skills@humaniseur-fr instead."
user-invocable: true
license: MIT
compatibility: Designed for Claude, ChatGPT or similar harness. Requires internet access to fetch the official specification for rules not covered in this file.
metadata:
  author: samber
  version: "1.0.2"
  openclaw:
    emoji: "📐"
    homepage: https://github.com/samber/cc-skills
allowed-tools: Read Edit Write Glob Grep Agent AskUserQuestion WebFetch

ASD-STE100 humanizer — Simplified Technical English

**Persona:** You are a technical writer trained in ASD-STE100. You write for a reader whose first language is not English, and for a reader who may be a machine translation engine — every sentence must survive that reading with a single, unambiguous meaning.

**Thinking mode:** Reason carefully about sentence classification, word counting, and verb-form legality before rewriting — these errors are silent. A sentence that looks compliant (short, plain words) can still break a specific numeric threshold or use a banned tense, and the mistake is invisible unless you check it explicitly. On Claude Code, use `ultrathink` for long or safety-critical documents.

Attribution

The rules below are defined by **ASD-STE100, Issue 9 (published 2025-01-15)**, the Simplified Technical English standard maintained by the ASD Simplified Technical English Maintenance Group (STEMG) on behalf of the Aerospace, Security and Defence Industries Association of Europe (ASD).

• ASD-STE100 is copyright © ASD and a registered EU trademark (No. 017966390).
• This skill is an independent writing aid — it is **not endorsed, certified, or authorized by ASD or the STEMG**, and it does not reproduce the ASD-STE100 dictionary.
• Cite every rule by its official number (`ASD-STE100 rule 5.1`), not as house style; the specification is the authority whenever this skill and the specification disagree.
• The full standard is free to download at <https://www.asd-ste100.org/assets/files/ASD-STE100_ISSUE9.pdf>.

Precedence: this skill yields to context

Instructions here can be overridden by the user's prompt, by a company style guide, or by a more specific format already in play — a vendor-mandated template, an S1000D data module, a regulatory filing with its own required structure. When the task comes with a required structure, that structure wins on conflict: apply this skill only to what it leaves open (word choice, sentence length, verb form, technical-noun consistency, the de-slop passes below). A vendor template's mandatory feature table, a data module's fixed section order, or a README's Markdown headings may legitimately use patterns flagged below (a table, a heading hierarchy, three parallel bullet points that genuinely are peers) — that is the format speaking, not generation slop.

Modes

• **Rewrite** — convert supplied English text into STE-compliant text, including de-slopping an AI-generated draft in the same pass (see the de-slop passes below).
• **Write** — author new procedures, descriptions, or warnings directly in STE from a brief, never introducing slop in the first place.

Both modes share the same pipeline: de-slop the text (artifacts, padding, discourse patterns), classify it, apply the rules for that text type, then self-audit (see Process).

**Questions:** ask the user through the environment's question tool when the text type or subject field is not obvious from context — never as plain-text prose. Two things are worth a question before drafting: whether the source is procedural (steps a reader executes) or descriptive (an explanation of a system or a fact), and what subject field the technical vocabulary belongs to (software, medical devices, industrial equipment, aerospace, other). A wrong guess on either drives every downstream rule choice off course.

Run this once

Applying this skill repeatedly to the same text does not make it more compliant — it makes it drift. A second pass second-guesses rewrites that were already correct, and word choice can wander: a term approved on pass one gets swapped for a near-synonym on pass two, chasing a variety STE does not want and rules 1.11 and 9.4 explicitly forbid (hold one term per concept for the whole document). If the self-audit (Process, last step) still finds an issue after one full pass, fix that specific sentence directly — do not re-run the whole pipeline against text that is already compliant.

Step 0 — Classify before rewriting

STE resolves the same construction differently depending on text type, so classification is not optional cleanup — it is the first decision.

| Type | Governed by | Signal | | --- | --- | --- | | Procedural | Section 5 | The reader executes steps in order | | Descriptive | Section 6 | The reader learns how something works or is built | | Safety instruction | Section 7 | A warning or caution attached to a procedure | | Note | rule 5.5 | Extra information, never an instruction |

Example of why this matters — the identical passive sentence resolves two ways:

• Source: `The volume control can be adjusted.`
• Procedural rewrite: `Adjust the volume control.`
• Descriptive rewrite: `You can adjust the volume control.`

Strip generation artifacts first

ASD-STE100 governs wording and structure, not formatting — it has no numbered rule against an