# Plain Language

> Apply ISO 24495-1:2023 (Plain Language — Part 1: Governing principles and guidelines) to any document or communication. Use when Shane says: "make this plain language", "apply plain language to this", "review for ISO 24495-1 compliance", "plain language pass", "plain english this", "make this clearer for readers", "simplify this for the audience". Also invoke proactively when reviewing policy, legal, form, or instructional text that a general audience must act on. Distinct from ms-style-pass (term/heading conventions) and humanize (Shane's voice) — this restructures for a reader's task.

- Skill: `slogsdon/plain-language` (Agent Skill)
- Install (CLI): `npx skillmds@latest add slogsdon/plain-language`
- Raw SKILL.md: https://api.skillmd.com/api/skills/slogsdon/plain-language/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: slogsdon (https://skillmd.com/u/slogsdon)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/slogsdon/plain-language

---


# ISO 24495-1:2023 (Plain Language)

ISO 24495-1 defines plain language as communication a reader can find, understand, and use on the first read. It is organized around **four governing principles**. A document is plain when it serves all four for its intended readers — clarity of a single sentence is not enough if the reader can't find it or act on it.

**Audience and purpose are prerequisites.** Principle 1 depends on knowing who the readers are and what they need to do. If Shane hasn't told you the audience or purpose, **ask before drafting** — you cannot apply the standard without them.

## Principle 1 — Readers get what they need

- Identify the readers and their needs before writing. State the assumptions you're making about both.
- Include only information relevant to the readers' purpose. Cut what they don't need, however true.
- Present information in the order **readers will use it** — task order, not the author's logical or legal order.
- Use examples and visuals where they aid comprehension more than prose would.

## Principle 2 — Readers can understand

- Write clear, direct sentences. Prefer active voice. Vary sentence length but keep the average short (~15–20 words).
- Choose words readers know. Avoid jargon unless you define it. Prefer concrete over abstract.
- **Kill nominalisations** — verbs frozen into nouns. "make a decision" → "decide"; "provide assistance" → "help"; "give consideration to" → "consider."
- Use one term for one concept, consistently. Don't elegantly vary "user / customer / account holder" for the same person.
- Place modifiers next to what they modify. Fix ambiguous pronoun references — every "it," "this," "they" must have one obvious antecedent.

## Principle 3 — Readers can find what they need

- Structure the document for the reader's purpose, not the subject's internal logic.
- Use **informative headings** that describe the content ("How to appeal a decision"), not bare labels ("Appeals").
- Use lists only when items are genuinely parallel and discrete. A list is not a substitute for prose that explains relationships or sequence-with-reasons.
- Use visual hierarchy — heading levels, white space — to signal structure.
- In longer documents, add navigation aids: a table of contents, a summary, and signposting ("The next section explains…").

## Principle 4 — Readers can use the document

- Recommend testing the document with representative readers where possible. Note this as a recommendation — you usually can't run the test yourself.
- Iterate based on reader feedback.
- Match the format to the medium: print vs. screen vs. mobile changes line length, chunking, and how much fits above the fold.

## Behavior

**Reviewing supplied text** — for each problem:

1. Name the **principle(s)** violated.
2. **Quote** the problematic passage.
3. Explain **why it fails** the principle — in reader terms ("a claimant skimming for the deadline won't find it here").
4. Give a **revised version**.

Group findings by principle, most impactful first. A structural problem (Principle 1 or 3) usually outranks a sentence-level one (Principle 2).

```
**Plain language review:**

Principle 1 — order of use
> "Under section 4(b), following completion of the prerequisite steps enumerated in Schedule A…"
The reader needs to know *what to do first*, not the statutory cross-reference. Lead with the action.
Revised: "First, complete the three steps in Schedule A. Then…"

Principle 2 — nominalisation
> "Submission of the application is a requirement prior to…"
Revised: "You must submit the application before…"
```

**Drafting new content** — apply all four principles proactively. State the assumptions you made about audience and purpose at the top, so Shane can correct them.

**When audience or purpose is unstated** — ask before drafting. Two or three targeted questions (Who reads this? What do they need to do after reading? What's their prior knowledge?) are enough. Do not guess your way past Principle 1.

## What not to do

- Don't confuse plain language with dumbing down. Concrete and direct, not childish. Keep the precision the reader needs to act correctly — a legal deadline, a dosage, a safety limit stays exact.
- Don't strip necessary information to shorten — Principle 1 is "what they need," not "as little as possible."
- Don't impose Shane's blog voice here (that's humanize) or term/heading house style (that's ms-style-pass). This skill restructures for a reader's task; it's often applied to text that isn't Shane's personal voice at all.