agentleFS
rookslogrookslog/stylewright/skills/standards/plain-language/SKILL.md

plain-language

Skill2 starsChanged 4 months agoMITView on GitHub

Use when writing for a general public audience that must act, such as public guidance, policy, eligibility text, forms, or web content.

11 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

33 rules. 0 are common, 31 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 31

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write so that a reader finds what they need, understands it the first time, and can act on it.

    line 10
  2. Distinctive:

    Use plain language when a general public reader must decide or act.

    line 19
  3. Distinctive:

    Use Simplified Technical English when a technician follows a procedure.

    line 20
  4. Distinctive:

    Follow one standard in one document.

    line 21
  5. Distinctive:

    Put the main idea before any exception or condition.

    line 36
  6. Distinctive:

    Start each section with the point, not with the background.

    line 37
  7. Distinctive:

    Write headings that state the content, and prefer the question the reader asks.

    line 39
  8. Distinctive:

    Use a list when the text holds several conditions, steps, or items.

    line 40
  9. Distinctive:

    Use transition words to show how one idea follows another.

    line 41
  10. Distinctive:

    Use the simple word in place of the formal word.

    line 45
  11. Distinctive:

    Do not use jargon. Define a technical term when the reader needs it.

    line 47
  12. Distinctive:

    Do not build long noun strings.

    line 48
  13. Distinctive:

    Use the same term for the same thing every time.

    line 49
  14. Distinctive:

    Use few abbreviations. An abbreviation that the reader must memorize costs more than it saves.

    line 50
  15. Distinctive:

    Put each word close to the word that it modifies.

    line 52
  16. Distinctive:

    Write short sentences, and put one idea in each sentence.

    line 56
  17. Distinctive:

    Keep the subject, the verb, and the object close together.

    line 57
  18. Distinctive:

    Write short paragraphs and short sections.

    line 58
  19. Distinctive:

    Use the active voice, and name the actor.

    line 63
  20. Distinctive:

    Use the present tense.

    line 64
  21. Very specific:

    Use must to state a requirement.

    line 65
  22. Very specific:

    Do not use shall. It is ambiguous, and courts have read it both ways.

    line 66
  23. Distinctive:

    Use contractions where they suit the reader and the register.

    line 67
  24. Distinctive:

    Do not use a slash between two words.

    line 69
  25. Distinctive:

    Use a table when the reader must match a condition to a result.

    line 73
  26. Distinctive:

    Use few cross-references. Each one sends the reader away from the answer.

    line 75
  27. Distinctive:

    Use a visual when it carries the meaning better than a sentence does.

    line 76
  28. Distinctive:

    Write link text that names the destination.

    line 80
  29. Distinctive:

    Do not publish a long PDF where a web page serves the reader better.

    line 81
  30. Distinctive:

    Avoid a page of frequently asked questions.

    line 83
  31. Distinctive:

    Test the document with real readers before you publish it.

    line 87
  32. Distinctive:

    Ask a reader to restate the content in their own words.

    line 88
  33. Distinctive:

    Every statement above is accounted for in a public trace.

    line 101

“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

plain-language

Purpose

Write so that a reader finds what they need, understands it the first time, and can act on it. This guide is based on the Federal Plain Language Guidelines, which support the Plain Writing Act of 2010.

Plain language is not simplified language. It does not remove detail. It puts the reader ahead of the writer.

Choosing between this and Simplified Technical English

  • Use plain language when a general public reader must decide or act.
  • Use Simplified Technical English when a technician follows a procedure.
  • Follow one standard in one document. Do not mix them.

The two standards disagree in places. Plain language allows contractions and asks for a conversational tone. Simplified Technical English forbids contractions, because they are hard for a reader whose first language is not English. The reader decides which standard wins.

Audience

  • Identify your reader before you write, and learn what they must do.
  • Address the reader directly as you.
  • Separate the guidance for each audience when one document serves several.

Organization

  • Put the main idea before any exception or condition.
  • Start each section with the point, not with the background.
  • Give each paragraph a topic sentence.
  • Write headings that state the content, and prefer the question the reader asks.
  • Use a list when the text holds several conditions, steps, or items.
  • Use transition words to show how one idea follows another.

Words

  • Use the simple word in place of the formal word.
  • Replace a hidden verb with the verb itself. Write apply, not make an application.
  • Do not use jargon. Define a technical term when the reader needs it.
  • Do not build long noun strings. Break them apart with prepositions.
  • Use the same term for the same thing every time.
  • Use few abbreviations. An abbreviation that the reader must memorize costs more than it saves.
  • Define few terms. A definition that contradicts ordinary usage confuses the reader.
  • Put each word close to the word that it modifies.

Concision

  • Write short sentences, and put one idea in each sentence.
  • Keep the subject, the verb, and the object close together.
  • Write short paragraphs and short sections.
  • State what is true rather than what is not true.

Tone

  • Use the active voice, and name the actor.
  • Use the present tense.
  • Use must to state a requirement.
  • Do not use shall. It is ambiguous, and courts have read it both ways.
  • Use contractions where they suit the reader and the register.
  • Give an example when a rule is hard to picture.
  • Do not use a slash between two words. Write the relationship out.

Design

  • Use a table when the reader must match a condition to a result.
  • Highlight the concepts that carry the decision.
  • Use few cross-references. Each one sends the reader away from the answer.
  • Use a visual when it carries the meaning better than a sentence does.

Web

  • Write link text that names the destination.
  • Do not publish a long PDF where a web page serves the reader better.
  • Rewrite print material for the web. Do not paste it.
  • Avoid a page of frequently asked questions. Organize the content by topic instead.

Testing

  • Test the document with real readers before you publish it.
  • Ask a reader to restate the content in their own words.

Source and boundary

This skill is an operational digest written in our own words. The source is public domain under CC0, so it places no limit on quotation. This digest does not replace the official guidelines, which carry the examples and the rationale.

Standard: Federal Plain Language Guidelines

The original site at plainlanguage.gov now redirects to digital.gov. The archived guidelines in the repository above are the source of record.

Every statement above is accounted for in a public trace. Each one either cites a named guideline, or is marked as our own editorial guidance, or is marked as narrative that asserts no rule. The trace lives in the stylewright repository. It is not installed with this skill.

Notice

This skill is not affiliated with, endorsed by, or approved by the General Services Administration, the Plain Language Action and Information Network, or any United States government agency.

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.