writing-for-humanslisted

# Writing for Humans Every word a user reads should be plain enough for a smart 9th grader who does not write code. This skill is the readability standard for user-facing DorkOS writing. It is the shared source the other writing skills build on. ## The readability contract Hold every user-facing sentence to these five rules: 1. **Aim for a 9th-grade reading level.** If a sentence needs a second read, rewrite it. 2. **Keep sentences short.** Aim under 20 words. Never pack two big ideas into one sentence. Split them. 3. **Use active voice with a clear actor.** Say who does what: "DorkOS opens your browser," not "the browser is opened." 4. **Lead with the benefit, then the mechanism (if at all).** Say what the user gets first. Most of the time you can drop the mechanism. 5. **Define or drop every technical term.** Either avoid the jargon or gloss it in the same sentence. Prefer numbers and concrete scenarios over abstractions. House punctuation rule: no em dashes. They invite run-on sentences that smuggle in a second idea; use a comma, colon, parentheses, or a new sentence instead. ## What this governs (and what it does not) **Governs** every surface a user reads: changelog fragments, release notes, READMEs, npm package copy, the GitHub repo description, `docs/` guide and concept pages, blog posts, UI microcopy, and error messages. **Does not govern** surfaces written for developers or coding agents, which stay precise and technical: - ADRs → `writing-adrs` - `contribut