openhands/extensions

plain-english-content

This skill should be used when the user asks to "write in plain English", "make this easier to read", "rewrite guidance", "improve report clarity", or produce accessible public-facing prose. It applies plain English content design principles: active voice, front-loaded content, sentence case, and no bold or italics for emphasis.

First seen Jun 30, 2026

Installation

$ npx skills add openhands/extensions --skill plain-english-content

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from openhands/extensions · top by installs.

npx skills add openhands/extensions

Browse all from openhands/extensions

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 143
License LICENSE
Default branch main
Open issues 45
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

LicenseMIT

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 6,023 B
  • docs SUMMARY.md 359 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 19 installs

SKILL.md

Open content up so anyone can understand it the first time they read it, without losing substance, nuance or precision. Aim to open up, not dumb down. Apply the GOV.UK style guide approach: plain English, user needs first, active voice, front-loaded structure and accessible formatting.

Use this skill for reports, research write-ups, guidance, documentation, summaries, and public-facing prose where clarity and accessibility matter. When writing a report, default to this style. When briefing a research agent, pass this skill so the report follows the same style.

Content design principles

  • Start from the user need. Write what the reader needs to know to do or decide something, not what the writer wants to say.
  • Front-load everything. Put the most important point first in the document, each section, each paragraph and each sentence. Use the inverted pyramid: conclusion first, then detail, then background.
  • Keep one idea per sentence and one topic per paragraph. Split sentences that contain more than one idea.
  • Be specific and concrete. Give the number, name and date. Cut vague abstractions like "a range of", "going forward" and "in terms of".
  • Cut everything that does not add meaning. Shorter is clearer. Remove duplication.

Plain English

  • Open content up, do not dumb it down. Keep the substance, nuance and precision. Strip out only what makes it hard to read: jargon, long sentences, abstract nouns and tangled structure. Make the content clear enough for a non-specialist and precise enough for an expert.
  • Use the active voice. Say who does what. Write "We reviewed the data", not "The data was reviewed".
  • Keep sentences short: about 15 to 20 words, and rarely more than 25. Keep paragraphs short.
  • Use everyday words. Replace jargon and formal wording with plain alternatives:

- use, not utilise or leverage - help, not facilitate or empower - work with, not collaborate, liaise or engage with - make or provide, not deliver - about, not in relation to or with regard to - so, not in order to - start, not commence - end, not terminate - buy, not purchase - enough, not sufficient - solve, fix or deal with, not tackle or combat - effect on, not impact on

  • Do not use impact as a verb.
  • Avoid metaphors and cliches: drive, unlock, deep dive, robust, key, ring-fence, hub, portal, landscape, ecosystem and going forward.
  • Address the reader as "you". Write about the organisation as "we". Use "they", "them" and "their" rather than gendered pronouns. Write "disabled people", not "the disabled".
  • Use contractions for a warmer tone when appropriate, such as "we'll" and "you'll". Avoid negative contractions: write "cannot", not "can't". Avoid "should've", "could've" and "would've".

Formatting

  • Do not use bold or italics for emphasis. Plain words and good structure carry the meaning. Use bold only for a literal interface element in an instruction, for example: select Save. Use single quotation marks for the titles of schemes or documents, not italics.
  • Use sentence case everywhere: headings, titles and table headers. Capitalise only proper nouns.
  • Front-load headings, keep them under about 65 characters, and make them unique and descriptive. Do not use a full stop, dash, slash or question mark in headings. Use headings to help readers skim.
  • Introduce bullet lists with a lead-in line that ends in a colon. Start each bullet lowercase. Keep each bullet to one idea. Do not put "and" or "or" after each bullet. Do not use semicolons. Do not use a full stop after the last bullet unless the bullet is a full sentence.
  • Use a numbered list only for steps readers must follow in order. Write steps as full sentences that end with a full stop. Do not use a lead-in colon.
  • Use descriptive link text that says where the link goes and front-loads the key words. Never write "click here" or "read more". Make link text understandable out of context.
  • Do not use Latin abbreviations. Write "for example" not "eg", "that is" not "ie", and "and so on" or "such as" not "etc". Latin abbreviations confuse some readers and screen readers.
  • Write "and", not "&", except in a registered name or logo.
  • Write "one", but use numerals from 2 upwards. Use the % symbol with numerals, such as 50%. Use £ with no decimals unless there are pence: £75, £75.50. Spell out millions and billions, such as £5 million. Write ranges with "to", not a hyphen: 10 to 20, Monday to Friday.
  • Write dates as "4 June 2026" with no comma or ordinal suffix. Use "to" for ranges, such as "4 to 8 June". Write times as "10am to 11.30am". Use "midday" and "midnight".
  • Do not use FAQs when the content can meet the user need directly. Do not use exclamation marks. Do not use all caps for emphasis.

Before finishing: self-check

  • Is the single most important thing first?
  • Could a non-expert understand every sentence on first read?
  • Is every sentence active, short and focused on one idea?
  • Have all bold or italic emphasis, jargon, Latin abbreviations and marketing language been removed?
  • Is everything in sentence case, with descriptive headings and links?
  • Can any more words be cut without losing meaning? If yes, cut them.

Scope note

The no-bold and formatting rules apply to produced prose, such as reports, guidance and summaries. Keep the conventions of code, data tables and direct quotations. Markdown headings and lists are acceptable because they provide structure, not emphasis.

Source

Imported and adapted from the public gist at https://gist.github.com/fofr/505e225f9bf5e839d30c12ba6bfa0be2.