simple-clear-humble-terms — quality + safety report

---
name: simple-clear-humble-terms
description: Force plain, low-ego language in any writing, doc, or naming decision. Use this skill aggressively when the user is writing a memo, drafting technical documentation, preparing a presentation, scoping internal docs, naming a new subsystem or feature, debating jargon in a design review, onboarding a new hire, writing release notes, or asking "what should we call this", "everyone on the team already knows what FOO means", "we need a glossary for this", "the spec uses a lot of internal terminology", "can you make this sound more technical", "write this in our company voice", or "shorten this with an abbreviation". Also fires when reviewing any doc that ships with a glossary, any slide that introduces a made-up three-letter acronym, any wiki page that assumes tribal knowledge, or any spec where a reader outside the team would stall on vocabulary. The bar: if it requires explanation, it impedes communication. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - shortest-path-communication
---

# Simple Clear Humble Terms

> "The most simple, straightforward, low-ego terms are generally best. You want to close the loop on reality hard."
> — Elon Musk, *The Book of Elon* (Chapter: Simple Communication)

## What this skill captures

Made-up acronyms and clever in-group vocabulary feel like productivity but are a tax on every future reader. Musk's rule at SpaceX and Tesla is blunt: "Excessive use of made-up acronyms is a significant impediment to communication." A few coined terms feel harmless; a thousand engineers each coining a few produces a glossary nobody remembers, and people "don't want to seem dumb in a meeting, so they just sit there in ignorance."

This skill forces the writer to kill jargon at the source, choose the plainest possible word, and stop hiding behind vocabulary. The value: docs that a new hire can read on day one, meetings where nobody is silently lost, and a team that closes the loop on reality instead of on its own private dictionary.

## When to use this skill

- Writing or reviewing a memo, spec, RFC, or design doc.
- Naming a new system, service, subsystem, feature, or process.
- Preparing slides for an internal or external presentation.
- Onboarding docs, runbooks, or anything a new hire will read.
- Debating whether to introduce an abbreviation in a design review.
- Auditing existing docs or a wiki for accumulated tribal vocabulary.

## The how-to

1. Apply the explanation test: if the term needs a glossary entry, it is broken.
   > "In general, anything that requires an explanation inhibits communication. We don't want people to have to memorize a glossary just to function."
   > — *The Book of Elon*
   If the reader has to look up the word, you have not communicated — you have made them work for you.

2. Reject the made-up acronym by default.
   > "I noticed a creeping tendency to use made-up acronyms at SpaceX and Tesla. Excessive use of made-up acronyms is a significant impediment to communication, and keeping communication clear as we grow is incredibly important."
   > — *The Book of Elon*
   "A few here and there" is the trap. A thousand people each adding a few is how you end up issuing a glossary to every new employee.

3. Allow only acronyms that already live outside your walls, or that pass an explicit owner.
   > "An acronym that most engineers outside of SpaceX already know, such as GUI (graphical user interface), is fine to use. It is also okay to use a few acronyms or contractions every now and again, assuming I have approved them... But they need to be kept to a minimum."
   > — *The Book of Elon*
   The default is no. The exception is an industry-standard term or a single named approver. Everything else dies.

4. Run the help-or-hurt test on every coined term.
   > "The key test for an acronym is to ask whether it helps or hurts communication."
   > — *The Book of Elon*
   If you cannot point to a clear win in reader comprehension, the term loses. "It is shorter" is not a win when the reader does not know it.

5. Pick the lowest-ego word available.
   > "The most simple, straightforward, low-ego terms are generally best."
   > — *The Book of Elon*
   The fancy word, the Latin word, the consultant word, the inside-joke word — they all signal status, not meaning. Pick the word a smart fifteen-year-old would understand.

6. Delete existing jargon that cannot be justified.
   > "If there is an existing acronym that cannot reasonably be justified, it should be eliminated."
   > — *The Book of Elon*
   Audit the doc you are in. Every coined term that fails the test gets cut and replaced with plain language. Do it now, not in a future cleanup pass.

7. Close the loop on reality, not on vocabulary.
   > "You want to close the loop on reality hard."
   > — *The Book of Elon*
   Words are a transport layer for reality. Optimize for whether the reader's model of the world now matches yours — not for how technical or polished the prose sounds.

## Common failure modes

- **"Everyone on the team already knows what it means."** Today, maybe. The new hire next month does not, and nobody will tell you they were lost in your meeting. Musk: people "don't want to seem dumb in a meeting, so they just sit there in ignorance."
- **Stacked acronyms.** A doc where TLAs reference other TLAs is a glossary disguised as prose. The reader is now decoding, not understanding.
- **Branding a system with a clever codename and then using the codename in technical docs.** Codenames are for marketing or morale, not for specs. Specs need the function name.
- **Latin / consultant / corporate vocabulary.** "Leverage," "synergize," "operationalize," "utilize." These are high-ego words for plain ideas. Use the plain word.
- **Shipping a glossary with the doc.** A glossary is an admission that the prose failed. Rewrite the prose.

## When NOT to use this skill

- The term is a genuine industry standard the audience already uses daily (HTTP, GPU, SQL, GUI). Spelling it out wastes their time.
- You are writing marketing or product naming copy where a memorable brand name is the actual goal — different problem, different rules.
- The audience is a single specialist team and the term is precise domain vocabulary (e.g., a chemistry paper using "enthalpy"). Plain language is not the same as dumbed-down language.
- Legal, regulatory, or safety documents where a specific defined term carries legal weight and must be used verbatim.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Simple Communication" (in "Designing the Organization").