govuk-style

name	govuk-style
description	Write and edit in GOV.UK / GDS house style: plain English, active voice, front-loaded content, sentence case, and no bold or italics for emphasis. Use when the user asks for GOV.UK or GDS style, or when writing reports, research write-ups, or guidance for external readers. Not for repo docs, UI strings, commit messages, or code comments; those follow writing-voice.
user-invokable	true
args	[{"name":"target","description":"The document or text to write or rewrite in GOV.UK style (optional)","required":false}]

Open the content up so anyone can understand it the first time they read it — without losing any of the substance, nuance or precision. The goal is to open up, not to dumb down. This skill applies the GOV.UK style guide and the Government Digital Service (GDS) content design principles. It is based on the GOV.UK A to Z style guide and writing guidelines (guidance.publishing.service.gov.uk).

Apply it to reports, research write-ups and guidance written for external readers. When you write a report, default to this style. When you brief a research agent, pass this skill so its report follows the same style. Repo documentation, UI strings, commit messages and code comments follow writing-voice instead.

Content design principles

• Start from the user need. Write what the reader needs to know to do or decide something, not what you want 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.
• One idea per sentence. One topic per paragraph. If a sentence has more than one idea, split it.
• Be specific and concrete. Give the number, the name, the date. Cut vague abstractions ("a range of", "going forward", "in terms of").
• Cut everything that does not add meaning. Shorter is clearer. Remove duplication.

Plain English

• Open it up, do not dumb it down. Keep all the substance, nuance and precision. Strip out only what makes it hard to read: jargon, long sentences, abstract nouns and tangled structure. A non-specialist and an expert should both grasp it on first read. Plain English carries complex ideas better, not worse — even experts read faster and prefer it.
• 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, never more than about 25. Keep paragraphs short.
• Use everyday words. Replace jargon and "government-speak" 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 clichés: drive, unlock, deep dive, robust, key, ring-fence, hub, portal, landscape, ecosystem, going forward.
• Address the reader as "you". Write about yourself or the organisation as "we". Use "they", "them" and "their" rather than gendered pronouns. Write "disabled people", not "the disabled".
• Contractions are fine for a warmer tone (we'll, you'll), but avoid negative contractions — write "cannot", not "can't" — and avoid "should've", "could've", "would've".

Formatting

• Do not use bold or italics for emphasis. Plain words and good structure carry the meaning. Bold is only acceptable to name 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, table headers, the lot. Capitalise only proper nouns.
• Headings: front-load them, keep them under about 65 characters, make them unique and descriptive. No full stop, dash, slash or question mark. Use them to let people skim.
• Bullet points: introduce the list with a lead-in line that ends in a colon. Start each bullet lowercase. Keep each to one idea. No "and"/"or" after each item, no semicolons, no full stop after the last bullet (unless a bullet is itself a full sentence).
• Numbered steps: use a numbered list only for a sequence the reader follows in order. Steps are full sentences and end with a full stop. No lead-in colon needed.
• Links: use descriptive link text that says where the link goes — front-load the key words. Never write "click here" or "read more". The link text should make sense out of context.
• Do not use Latin abbreviations. Write "for example" not "eg", "that is" not "ie", "and so on" or "such as" not "etc". They confuse screen readers and some readers.
• Ampersands: write "and", not "&" (except in a registered name or logo).
• Numbers: write "one" but use numerals from 2 upwards (2, 9, 25). Use the % symbol with numerals (50%). Use £ with no decimals unless there are pence (£75, £75.50). Spell out millions and billions (£5 million, not £5m). Write ranges with "to", not a hyphen (10 to 20, Monday to Friday).
• Dates and times: write "4 June 2026" (no comma, no "th"). Use "to" for ranges ("4 to 8 June"). Write times as "10am to 11.30am"; use "midday" and "midnight".
• Do not use FAQs. If you have answered the user need in the content, you do not need them. Do not use exclamation marks. Do not use ALL CAPS for emphasis.

Before you finish: 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 one idea?
• Have you removed all bold/italic emphasis, jargon, Latin abbreviations and marketing language?
• Is everything in sentence case, with descriptive headings and links?
• Could you cut any more words without losing meaning? If yes, cut them.

Note on this skill's own scope

The "no bold" and formatting rules apply to the prose you produce (reports, guidance, summaries). Code, data tables and direct quotations keep their own conventions. Markdown headings and lists are fine — they are structure, not emphasis.