Agents misread Hebrew. A 40-year-old aerospace standard helps.

galb — Thu, 22 Oct 2026 07:04:16 +0000

In aerospace maintenance, a misread instruction can ground an aircraft, or cause worse damage. So the industry built ASD-STE100, Simplified Technical English. It is a controlled language with one meaning per word, active voice, short sentences, and one instruction per sentence.

Today a new kind of reader parses technical text with no one to ask: the AI agent. A model reads tool descriptions, error messages, and instructions between agents. It cannot ask the author what the author meant. danyuchn/asd-ste100-skill applies STE100 to English agent text as a Claude Code skill. I ported it to Hebrew.

Why Hebrew needs its own rules

STE100 defines English only. No official Hebrew version exists, so every Hebrew rule here is an adaptation. Some English rules carry over directly. Others have no English equivalent:

Keep את. Headline-style Hebrew drops את before a definite object: "למחוק קובץ ההגדרות". Keep it: "למחוק את קובץ ההגדרות". Then the direct object is explicit.
Put a hyphen before Latin text and digits. In "בשרת הAPI", the prefix merges into the term. Write "בשרת ה-API".
Use one instruction form. Hebrew procedures often mix the imperative ("פתח"), "יש ל-", and the future tense ("תבדוק"). The skill uses the infinitive ("לפתוח") for every instruction. The infinitive is also gender-neutral.
Use one part of speech per word. In "המשתמש משתמש בכלי", משתמש is both "user" and "uses". Keep it a noun and use a different verb: "המשתמש מפעיל את הכלי".
Do not use לבצע with an action noun. "לבצע בדיקה של המסנן" hides the action in a noun. Write "לבדוק את המסנן".

The most important rule: hedges stay hedges

Before:

ייתכן שאירעה שגיאה במהלך עיבוד הבקשה שלך עקב אי-התאמה אפשרית בפורמט הנתונים הצפוי, אשר עשויה להיגרם כתוצאה מגרסת לקוח שאינה מעודכנת.

After:

ייתכן שאירעה שגיאה בעיבוד הבקשה. ייתכן שהסיבה היא אי-התאמה בפורמט הנתונים הצפוי. ייתכן שגרסת לקוח לא מעודכנת גרמה לאי-ההתאמה הזו.

"אירעה שגיאה" ("an error occurred") reads better. But it states an error that the system only suspects. A simplifier that removes uncertainty makes the text clearer and wrong. The skill splits the sentence into three claims and keeps every hedge.

Two modes and a linter

Strict mode is for procedures, error messages, tool descriptions, and agent instructions. It applies every rule, including the length limits.
Flavored mode is for README prose. It removes marketing words that have no measurement, and it keeps every claim.

A Python linter (scripts/ste-lint-he.py) uses only the standard library. It does a mechanical first pass: semicolons, sentence length, nominalization, marketing words, prefix hyphens, slang, and synonym rotation. It cannot check construct chains, homographs, or a dropped את. The model and the author check those.

Try it

npx skills add g4lb/asd-ste100-hebrew-skill

Then ask Claude: פשט את תיאור הכלי הזה ("simplify this tool description").

Repository (MIT license): https://github.com/g4lb/asd-ste100-hebrew-skill

If you write Hebrew for agents, tell me which rules feel wrong.

DEV Community: galb

Agents misread Hebrew. A 40-year-old aerospace standard helps.

Why Hebrew needs its own rules

The most important rule: hedges stay hedges

Two modes and a linter

Try it