
Simplified Technical English
FreeEnhance clarity in technical writing with controlled language.
Free · Opens the source repo
What Simplified Technical English does
Simplified Technical English (STE) is a controlled-language standard developed to ensure clarity and prevent misinterpretation in technical documentation, particularly in the aerospace and defense sectors. This skill leverages the principles of ASD-STE100 to guide users in producing clear and concise prose that minimizes ambiguity. By adhering to specific rules regarding word choice, sentence structure, and overall composition, users can create documents that are straightforward and easy to understand, which is critical when instructions or reports are acted upon by others.
The skill is particularly useful for developers and technical writers who need to communicate complex information clearly. It emphasizes using one meaning per word, active voice, and simple tenses, which helps in crafting messages that are direct and unambiguous. This is especially important in environments where miscommunication can lead to errors or safety issues. The guidelines provided in this skill can be applied to various forms of writing, including reports, pull request descriptions, commit messages, and instructions for other agents.
To effectively use this skill, users are encouraged to apply the rules from the start, rather than drafting complex sentences that require later revision. The skill includes a set of rules that dictate how to structure sentences, such as keeping them short, using lists for multiple instructions, and avoiding jargon unless defined. This structured approach not only aids in clarity but also enhances the readability of technical documents, making them more accessible to a broader audience.
Overall, this skill is an essential tool for anyone involved in writing technical content that must be understood and acted upon by others, ensuring that communication is efficient and effective. By following the STE principles, users can significantly reduce the risk of misinterpretation in their written communications.
When to use it
Use this skill when writing any technical document that requires clear instructions or information for others to act on.
When not to use it
Avoid this skill for creative writing or marketing content where tone and persuasive language are essential.
What you can build with it
Writing Technical Reports
Use this skill to create clear and concise technical reports that can be easily understood by the intended audience.
Creating Pull Request Descriptions
Apply the rules of STE to write pull request descriptions that clearly outline changes and their implications.
Drafting Instructions for Agents
Utilize this skill when writing instructions for other agents to ensure they can act without confusion.
How to install Simplified Technical English
View source1. Install with the skills CLI
npx skills add posthog/posthog/writing-simplified-technical-english --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by posthogWriting simplified technical English
ASD-STE100 is a controlled-language standard. The aerospace and defense industry wrote it so that a technician cannot misread a maintenance instruction. It removes the two biggest sources of misreading: words that carry more than one meaning, and sentences that support more than one structure.
The same discipline fixes the usual failure of agent-written prose. Agent output is often correct and unreadable: long sentences, stacked hedges, passive voice, and a synonym rotation that makes one action look like three. The reader has no author to ask, so ambiguity costs them a re-read at best and a wrong action at worst.
Apply the rules below as you write. Do not write a dense draft and clean it up afterward.
When to use this
Use it for text that a person or another agent must act on:
- Reports, findings, and summaries.
- PR descriptions, commit messages, and code comments.
- Instructions passed to another agent, and prompts.
- Tool descriptions, error messages, empty states, and log lines.
Do not use it where voice is the point: marketing copy, blog posts, or anything persuasive. STE is deliberately flat. Also leave quoted text alone. If you quote a user, a log, or a document, quote it as it is.
The rules
| Rule | Do | Do not |
|---|---|---|
| One meaning per word | Pick one verb per action and reuse it every time | Rotate "check", "verify", and "confirm" for the same action |
| One part of speech per word | "Apply oil to the valve" | "Oil the valve" |
| Active voice | "The worker deletes the file." | "The file is deleted." |
| Simple tenses | "We received the report." | "We have received the report." |
| One idea per sentence | "Open the file. Read line 3." | "Open the file and read line 3, then check it matches." |
| Sentence length | 20 words or fewer for instructions, 25 or fewer for descriptions | Chains of subordinate clauses |
| Noun clusters | 3 words or fewer ("fuel pump valve") | "high pressure fuel pump inlet valve assembly" |
| No missing words | Keep the subject, the verb, and the article, even if it reads longer | "Files not backed up will be lost", which hides which files |
| One hedge, at most | "The client version is probably out of date." | "An error may have occurred which could be caused by..." |
| Paragraphs | One topic, 6 sentences or fewer | Multi-topic paragraphs |
| Lists | Use a list for 3 or more steps or conditions | A sequence buried in one sentence |
| Jargon | Keep the technical term you need, and define it once | Use an internal name the reader has never seen |
PostHog house style sits on top of these rules and wins where the two disagree. We use American English, sentence case, and the Oxford comma. We do not use the em-dash.
How to rewrite
- Read the text once for meaning. Do not start rewriting before you know what it must still say.
- Go sentence by sentence. Name the rule each sentence breaks.
- Rewrite the sentence to fix that break. Keep every fact, number, condition, and qualifier.
- Check the result against the rules again. A rewrite often introduces a new long sentence.
Precision beats brevity. If a shorter sentence would drop a safety condition, a scope qualifier, or a number, keep the longer sentence and say why.
If the text already follows the rules, say so. Do not change compliant text.
Self-check
Before you send the text, read it once and ask:
- Does any sentence run past 25 words?
- Does any sentence carry two instructions?
- Does the same action appear under two different verbs?
- Can a passive sentence name its actor?
- Would a reader who joins here, with no context, know what to do next?
References
references/writing-rules.md: the detail behind the table, plus sources.references/before-after.md: worked examples of the rewrite, including agent output.
Frequently asked questions about Simplified Technical English
Similar skills
Supabase Docs Authoring
Streamline your Supabase documentation process.
Docs Writer
Streamline your documentation process with precision.
Clinical Case Report
Generate structured medical case presentations.
CrossFrame Suite
Streamline complex workflows for Chinese structural analysis.
Em Dash Expert
Master the em dash for clear, precise writing.
Nature Statistics Reporting
Enhance manuscript statistics for high-impact journal submissions.
