plain-english-content

name	plain-english-content
description	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.
license	MIT
triggers	["plain English"]

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.