Skip to content
Back to skills

Asd Ste100

ASecurity

Explains, drafts, reviews, and validates technical documentation and LLM outputs in ASD-STE100 (Simplified Technical English) or Karpathy's 80% Pragmatic Mode. Enforces short sentences, active voice, controlled vocabulary, and high cognitive parseability. Use when the user asks for ASD-STE100, STE, Simplified Technical English, "80% STE", Karpathy-style writing, or a clean low-cognitive-load explanation, or asks to lint or rewrite docs for passive voice, long sentences, or vague words.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 5, 2026
ai-agentsgoapidatabasesecuritydocumentation

Works with

  • claude code
  • cli
  • api

Security analysis

A100/100

Scanned October 5, 2026

npx -y skills add JAICHANGPARK/ASD-STE100 --skill asd-ste100 --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Asd Ste100?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Asd Ste100
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/jaichangpark-asd-ste100/badge)](https://www.skillsdirectory.com/skills/jaichangpark-asd-ste100)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: asd-ste100
description: Explains, drafts, reviews, and validates technical documentation and LLM outputs in ASD-STE100 (Simplified Technical English) or Karpathy's 80% Pragmatic Mode. Enforces short sentences, active voice, controlled vocabulary, and high cognitive parseability. Use when the user asks for ASD-STE100, STE, Simplified Technical English, "80% STE", Karpathy-style writing, or a clean low-cognitive-load explanation, or asks to lint or rewrite docs for passive voice, long sentences, or vague words.
---

# ASD-STE100: Simplified Technical English & 80% Pragmatic Mode

A comprehensive skill for generating, transforming, and validating technical content using **ASD-STE100 (Simplified Technical English, Issue 9, January 2025)** and Andrej Karpathy's **"80% Pragmatic Mode"**.

> *"Writing. Something I've had success with: Ask your LLM to explain something in ASD-STE100, it's a controlled language specification originally developed for aerospace maintenance documentation. LLMs well-versed in this language and it comes with heavy constraints on clean writing style that I often find a lot more readable. Sometimes I've tried to soften it a bit e.g. ask for '80% of the way to ASD-STE100' because the spec is quite stringent..."*  
> — **Andrej Karpathy**

---

## 1. When to Use This Skill

Activate this skill when:
- The user requests an explanation or documentation in **ASD-STE100** or **Simplified Technical English**.
- The user asks for **"80% ASD-STE100"**, **"Karpathy-style writing"**, or **clean, low-cognitive-load explanations**.
- Complex architecture, code, algorithms, or system workflows must be parsed rapidly without ambiguity.
- You need to audit or lint existing documentation for passive voice, bloated sentences, or ambiguous words.
- The user wants multi-modal cognitive aids alongside STE (e.g., Mermaid diagrams, interactive HTML explainers, or 3b1b/Manim video scripts).
- The user asks to **summarize or record a session, a conversation or a meeting** in STE (see "Session records" below).

---

## 2. Core Philosophy & Modes

ASD-STE100 was created by aerospace manufacturers (ASD, formerly AECMA) to eliminate catastrophic maintenance errors caused by complex, ambiguous English. Its philosophy is:
- **One word, one meaning**: Avoid synonyms that create confusion.
- **Cognitive clarity**: Human working memory processes short, direct sentences up to 4x faster.
- **Zero ambiguity**: Eliminate vague qualifiers, passive constructions, and speculative modals.

### Mode Comparison: 100% Strict vs. 80% Pragmatic

| Rule Dimension | Strict Mode (100% ASD-STE100) | 80% Pragmatic Mode (Karpathy) [Default] |
| :--- | :--- | :--- |
| **Target Audience** | Aerospace, mission-critical hardware, ISO standard docs | Software engineers, AI researchers, general technical readers |
| **Sentence Length** | Procedural: ≤ 20 words<br>Descriptive: ≤ 25 words | All sentences: target 15–22 words (absolute max 25 words) |
| **Voice** | Active voice. Passive only in descriptive text when the agent is unknown. Imperative for steps. | Active voice prioritized; direct subject-verb-object order. |
| **Ideas per Sentence** | Exactly 1 thought per sentence. | 1 primary idea per sentence. |
| **Vocabulary** | Approved ASD-STE100 dictionary words, plus technical nouns and technical verbs. | Controlled English: replaces bureaucratic jargon with simple verbs, but allows standard modern tech terms (e.g. *API*, *container*, *latency*). |
| **Noun Clusters** | Max 3 consecutive nouns. | Max 3 consecutive nouns (break up with prepositions). |
| **Punctuation** | No semicolons. No contractions. No Latin abbreviations. | Avoid semicolons. Contractions and *e.g.* are tolerated. |
| **Multi-modal Visuals** | Standard technical drawings/tables. | Pairs text with **Mermaid diagrams** or **Interactive HTML** widgets. |

---

## 3. ASD-STE100 Writing Rules (Issue 9)

ASD-STE100 Issue 9 (January 2025) is an international standard with **53 writing rules in 9 sections** and a dictionary of about 900 approved words. The rule labels below (for example `STE 3.6`) match the labels in the `/asd check` linter report.

> This skill summarizes the rules. It does not contain the official dictionary. To get the full standard and dictionary, request a free copy at [asd-ste100.org](https://www.asd-ste100.org/). Issue 9 calls "technical names" **technical nouns**.

### Section 1: Words
- **STE 1.1–1.3 — Approved words, part of speech, and meaning:** Use only approved words, and use each one only as its listed part of speech and with its approved meaning. One word, one meaning:
  - **Use** (not *utilize*) · **Stop** (not *terminate*, *abort*, *cease*) · **Start** (not *commence*, *initiate*)
  - **Close** (not *shut*) · **Change** (not *modify*, *alter*) · **Get** (not *obtain*)
  - **Before** (not *prior to*) · **After** (not *subsequent to*) · **Because** (not *in view of the fact that*)
  - **If** (not *in the event that*) · **And** (not *as well as*) · **To** (not *in order to*, *for the purpose of*)
- **STE 1.5–1.11 — Technical nouns:** You can use words that are not in the dictionary only as technical nouns (for example *API*, *cache*, *container*). Use short, clear technical nouns. Do not use slang or jargon. Do not use different technical nouns for the same thing.
- **STE 1.7, 1.13 — Do not change the part of speech:** Do not use a technical noun as a verb (❌ *"Cache the result"* in strict mode → ✔ *"Put the result in the cache"*).
- **STE 1.14 — Spelling:** Use American English spelling.

### Section 2: Multi-Word Nouns
- **STE 2.1 — Maximum 3 nouns in a row.**
  - ❌ "user session timeout error handler configuration"
  - ✔ "configuration for the handler of user session timeout errors"
- **STE 2.2:** If a technical noun has more than 3 words, give the full name first, then use a shorter name or hyphens.

### Section 3: Verbs
- **STE 3.1–3.3 — Approved verb forms only:** infinitive, imperative, simple present, simple past, simple future (*will*), and the past participle as an adjective.
  - ❌ present perfect (*has processed*), progressive (*is running*) → ✔ *processed*, *runs*
- **STE 3.4 — No complex verb structures:** Do not combine helping verbs (❌ *"will have been sent"*).
- **STE 3.5 — No "-ing" forms**, except in technical nouns (*"landing gear"*, *"load balancing"*).
- **STE 3.6 — Active voice:** Use the active voice. In descriptive text, you can use the passive voice **only when the agent is unknown**. In procedures, always use the active voice.
  - ❌ "The configuration is verified by the daemon." → ✔ "The daemon checks the configuration."
- **STE 3.7 — Use verbs for actions, not nouns:** ❌ *"Do an inspection of the logs"* → ✔ *"Examine the logs."*

### Section 4: Clarity
- **STE 4.1 — Short, clear sentences:** One topic per sentence.
- **STE 4.2 — Do not omit words or use contractions:** Keep articles and *that*. ❌ *"Make sure valve open"*, *"don't"* → ✔ *"Make sure that the valve is open"*, *"do not"*.
- **STE 4.3 — Vertical lists:** Use a list or a table for more than two items or conditions.
- **STE 4.4 — Connecting words:** Use words such as *then*, *but*, and *because* to connect related sentences.
- **STE 4.5 — Articles:** Put an article (*a*, *the*) or a demonstrative (*this*, *these*) before a noun when applicable.

### Section 5: Procedures (Instructions)
- **STE 5.1 — Maximum 20 words per sentence.**
- **STE 5.2 — One instruction per sentence**, unless you must do two actions at the same time.
- **STE 5.3 — Use the imperative:** *"Download the archive."* *"Run the setup script."*
- **STE 5.4 — Condition first:** If an instruction starts with a condition or description, divide it from the command with a comma: *"If the test fails, examine the log."*
- **STE 5.5 — Notes give information, not instructions.**
  - ❌ "Turn off the server, disconnect the power cable, and then verify that the LED has stopped blinking."
  - ✔ 1. Stop the server. 2. Disconnect the power cable. 3. Make sure that the LED is off.

### Section 6: Descriptive Writing
- **Maximum 25 words per sentence.**
- **One topic per paragraph, and maximum 6 sentences per paragraph.**
- Put the most important information first.

### Section 7: Safety Instructions
- **STE 7.1 — Use the correct signal word:** **WARNING** (risk of injury or death) or **CAUTION** (risk of damage to equipment). In software, use them for data loss, security risk, or production outages.
- **STE 7.2 — Start with a clear command or condition.**
- **STE 7.3 — Then give a short explanation of the risk.**
  - ✔ *"WARNING: Do not run this migration on the production database. The migration deletes all rows in the users table."*

### Section 8: Punctuation and Word Counts
- **STE 8.1 — Do not use semicolons.** Write two sentences.
- **STE 8.2 — Use hyphens** to connect directly related words. A hyphenated word counts as one word.
- **STE 8.3–8.7 — Word counts:** Parentheses are permitted. A number, a unit, and a code identifier each count as one word. In a vertical list, a colon counts like a full stop.

### Section 9: General Writing Practices
- **STE 9.1:** If a direct word replacement does not work, write the sentence again with a different structure.
- **STE 9.3 — No phrasal verbs:** ❌ *"set up"*, *"carry out"*, *"find out"* → ✔ *"install"*, *"do"*, *"find"*.
- **Grammar rules:** Do not use Latin abbreviations (*e.g.*, *i.e.*, *etc.*). Make clear what each pronoun (*it*, *this*) refers to.

### Vague Words and Modals
These words cause ambiguity. Replace them in both modes:
- *should*, *could*, *might*, *ought to* → *must*, *can*, or an exact condition
- *adequate*, *properly*, *sufficiently*, *approximately* → an exact value or instruction
- *and/or* → *and* or *or*

## 4. Karpathy's 4 Multimodal Artifact Modalities

In addition to ASD-STE100 writing, Andrej Karpathy highlighted that LLM outputs should leverage higher abstraction layers:

### Modality 1: Pure ASD-STE100 Text
Use for runbooks, architecture overviews, operational guidelines, and PR reviews. Clean, rapid, unambiguous.

### Modality 2: Diagrams (Mermaid)
Whenever a process involves 3 or more components or state transitions, include a Mermaid flowchart or sequence diagram:
```mermaid
flowchart TD
    A[Client Request] --> B[API Gateway]
    B --> C{Token Valid?}
    C -->|Yes| D[Worker Service]
    C -->|No| E[Return 401 Unauthorized]
    D --> F[Database Write]
```

### Modality 3: Interactive Web Pages (HTML)
When explaining dynamic systems, render an interactive single-file HTML component (inline widget or standalone artifact) with sliders, step-by-step playback, or live toggles.

### Modality 4: Explainer Video Storyboards & Scripts
Generate complete 3b1b (3Blue1Brown / Manim) animation scripts with voice narration markers formatted for Text-to-Speech (e.g. ElevenLabs):
- Scene breakdown (visual coordinate layout)
- Precise narration text (written in STE for clear pacing)
- Audio timing timestamps

---

## 5. Quick Transformation Reference Table

| Non-STE / Bloated English | ASD-STE100 (Strict) | 80% Pragmatic Mode (Karpathy) |
| :--- | :--- | :--- |
| *In order to utilize the database, it is necessary that authentication be performed prior to commencing queries.* | You must log in before you send queries to the database. | Log in before you query the database. Authentication is required. |
| *The worker pool should be terminated subsequent to the completion of all scheduled tasks.* | Stop the worker pool after all tasks finish. | Stop the worker pool after all tasks finish. |
| *Make sure the system is properly configured with an adequate number of replicas.* | Configure the system with at least 3 replicas. | Configure the system with at least 3 replicas to prevent downtime. |
| *The data was transmitted across the network by the client agent.* | The client agent sent the data across the network. | The client agent sent the data across the network. |

---

## 6. Execution Workflow for Agents

When requested to explain or rewrite a topic:
1. **Determine Mode:** Default to **80% Pragmatic Mode** unless the user specifies "100%", "strict", or aerospace compliance.
   - **Language:** Write in the language of the user's request. ASD-STE100 is an English standard, but apply its principles to the user's language: short sentences, one idea in each sentence, the active voice, simple and literal words. A Korean request gets a Korean STE answer.
   - **Document structure:** Start with `# <title>`. Give each topic a `## <heading>` (do not number the headings yourself). Write procedures as numbered steps with one command in each step. Write risks as `WARNING:` or `CAUTION:` lines. Keep code blocks and technical names unchanged.
2. **Deconstruct the Core Concepts:** Identify the actors, actions, and sequence.
3. **Draft Sentences:** Keep each sentence under 22 words. Use active voice.
4. **Vocabulary Audit:** Check against unapproved words (*utilize* -> *use*, *prior to* -> *before*, *etc.* -> list explicitly) and phrasal verbs (*set up* -> *install*).
5. **Add Visuals if Helpful:** Add a Mermaid diagram or interactive HTML widget for multi-step logic.
6. **Self-Check:** Verify against the 8-point checklist:
   - [ ] No sentence exceeds its limit (strict: 20 procedural / 25 descriptive; 80%: 25).
   - [ ] Active voice (strict: passive only in descriptive text when the agent is unknown).
   - [ ] Max 3 nouns in clusters.
   - [ ] One clear idea per sentence. Max 6 sentences per paragraph.
   - [ ] Simple, unambiguous verbs. No phrasal verbs. No "-ing" forms except in technical nouns.
   - [ ] No fluff words (*it should be noted that*, *in order to*).
   - [ ] No semicolons (strict: also no contractions and no *e.g.*, *i.e.*, *etc.*).
   - [ ] Safety risks use **WARNING** or **CAUTION**, a command first, then the risk.

### Session records

When the user asks to summarize or record a session, a conversation or a meeting, write an STE record with these sections. Leave out a section that has no content.

- `## Purpose`: what the user wanted.
- `## Decisions`: what was decided, and why.
- `## Completed work`: what was done, as numbered steps in time order.
- `## Open items`: what is not done, as a list.

Write only facts from the conversation. Do not add new facts. Write risks as `WARNING:` or `CAUTION:` lines.

The `/asd` mod does the same on request: `/asd session` writes the record of the current Claude Code session in the STE pane (`/asd session lite` uses a small model). The mod never runs it by itself, as it uses tokens.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…