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
- HeBtcd/skillstheir own version, first seen Nov 1, 2026
- JarvusInnovations/agent-skillstheir own version, first seen Oct 20, 2026
- slogsdon/skills-writingtheir own version, first seen Oct 19, 2026
- alumpe/skillstheir own version, first seen Sep 11, 2026
- olivervvvv/plain-language-skilltheir own version, first seen Sep 2, 2026
- crfldrxyz/AuthorOps-Skillstheir own version, first seen Sep 1, 2026
Other versions11 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 11
- mgifford/accessibility-skills★ 48same name
- HeBtcd/skills★ 5same name
- olivervvvv/plain-language-skill★ 3same name
- Vaibhavkkm/vkkm-aegis-plugin★ 2same name
- Demon-Ryan/plain-words★ 1same name
- JarvusInnovations/agent-skills★ 1same name
- miovrag/claude-skills★ 1same name
- alumpe/skills★ 0same name
- crfldrxyz/AuthorOps-Skills★ 0same name
- janrau9/claude-skills★ 0same name
1 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository8 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- compressed-deliberationSkill
- de-slopSkill
- navigable-referencesSkill
- proportionate-executionSkill
- subagent-returnsSkill
- simplified-technical-englishSkill
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
- Distinctive: line 10
Write so that a reader finds what they need, understands it the first time, and can act on it.
- Distinctive: line 19
Use plain language when a general public reader must decide or act.
- Distinctive: line 20
Use Simplified Technical English when a technician follows a procedure.
- Distinctive: line 21
Follow one standard in one document.
- Distinctive: line 36
Put the main idea before any exception or condition.
- Distinctive: line 37
Start each section with the point, not with the background.
- Distinctive: line 39
Write headings that state the content, and prefer the question the reader asks.
- Distinctive: line 40
Use a list when the text holds several conditions, steps, or items.
- Distinctive: line 41
Use transition words to show how one idea follows another.
- Distinctive: line 45
Use the simple word in place of the formal word.
- Distinctive: line 47
Do not use jargon. Define a technical term when the reader needs it.
- Distinctive: line 48
Do not build long noun strings.
- Distinctive: line 49
Use the same term for the same thing every time.
- Distinctive: line 50
Use few abbreviations. An abbreviation that the reader must memorize costs more than it saves.
- Distinctive: line 52
Put each word close to the word that it modifies.
- Distinctive: line 56
Write short sentences, and put one idea in each sentence.
- Distinctive: line 57
Keep the subject, the verb, and the object close together.
- Distinctive: line 58
Write short paragraphs and short sections.
- Distinctive: line 63
Use the active voice, and name the actor.
- Distinctive: line 64
Use the present tense.
- Very specific: line 65
Use must to state a requirement.
- Very specific: line 66
Do not use shall. It is ambiguous, and courts have read it both ways.
- Distinctive: line 67
Use contractions where they suit the reader and the register.
- Distinctive: line 69
Do not use a slash between two words.
- Distinctive: line 73
Use a table when the reader must match a condition to a result.
- Distinctive: line 75
Use few cross-references. Each one sends the reader away from the answer.
- Distinctive: line 76
Use a visual when it carries the meaning better than a sentence does.
- Distinctive: line 80
Write link text that names the destination.
- Distinctive: line 81
Do not publish a long PDF where a web page serves the reader better.
- Distinctive: line 83
Avoid a page of frequently asked questions.
- Distinctive: line 87
Test the document with real readers before you publish it.
- Distinctive: line 88
Ask a reader to restate the content in their own words.
- Distinctive: line 101
Every statement above is accounted for in a public trace.
“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.
Files
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, notmake 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
mustto 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.
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
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.

