agentleFS
slogsdonslogsdon/skills-writing/skills/plain-language/SKILL.md

plain-language

Skill0 starsChanged 25 days agoMITView on GitHub

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.

11 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 10 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use examples and visuals where they aid comprehension more than prose would.

    line 18
  2. Distinctive:

    Write clear, direct sentences.

    line 22
  3. Distinctive:

    Use one term for one concept, consistently.

    line 25
  4. Distinctive:

    Place modifiers next to what they modify.

    line 26
  5. Distinctive:

    Use informative headings that describe the content ("How to appeal a decision"), not bare labels ("Appeals").

    line 31
  6. Distinctive:

    Use lists only when items are genuinely parallel and discrete.

    line 32
  7. Distinctive:

    Use visual hierarchy — heading levels, white space — to signal structure.

    line 33
  8. Distinctive:

    Don't confuse plain language with dumbing down.

    line 72
  9. Distinctive:

    Don't strip necessary information to shorten — Principle 1 is "what they need," not "as little as possible."

    line 73
  10. Distinctive:

    Don't impose Shane's blog voice here (that's humanize) or term/heading house style (that's ms-style-pass).

    line 74

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.