mcpbeat Sign in

Simple English Agent Skill

Use when the user wants technical or developer writing (docs, issues, READMEs, comments, UI text) drafted or rewritten to be clear and simple for a global audience

3k tokens
context cost
the whole folder, loaded on every use
3
files
instructions only
0
copies elsewhere
how many repositories repackaged it
123
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/vinta/hal-9000 --skill simple-english

What comes with it

9 496 bytes besides the instruction
references/README.md
references/writing-rules.md

The instruction itself

3 sections, as written by the author

Simple English

Write or rewrite the given text in Global English: the global-audience tier that Google, Microsoft, MDN, Red Hat, and GitLab documentation follows. Clear structure, unambiguous words, translation-friendly grammar, no controlled dictionary, no hard word caps. The rewrite must give the same technical facts as the source and still sound like a native speaker wrote it.

Ground rules

  • Meaning is untouchable. Every fact, value, condition, and caveat in the source survives the rewrite. Softened obligations stay soft: "should" stays a recommendation unless the source means a requirement.
  • Never invent specifics. Keep each fact at its original precision and flag gaps. Do not fabricate values, names, or conditions.
  • Quoted text is frozen. Code spans and blocks, commands, config keys, file paths, UI labels, error messages, and identifiers stay exactly as they are. Rewrite the prose around them.
  • Voice survives. Clarity edits that flatten prose into staccato fragments are regressions. Filler drops freely ("it should be noted that"), personality stays.

Workflow

  • Load the rules. Read references/writing-rules.md in full: sentence structure, word choice, the clarity helpers, tone, and the substitution table.
  • Collect the source. Take the text from the conversation, or Read the files or sections the user pointed at. When the user wants new text drafted instead of existing text rewritten, collect the facts to convey (from the conversation, code, or files) and treat them as the source for every later step. Done when you hold every passage to rewrite or every fact to state.
  • Sort each passage into procedure (imperative work steps), description (declarative prose), or micro-text (headings, UI labels, error messages). Procedures get imperative mood and condition-first ordering. Micro-text gets a verb when clarity needs one.
  • Map the terminology. List each concept that appears under more than one name, pick one term per concept (prefer the project's established names), and use it everywhere. Done when no concept has two names and no word carries two meanings.
  • Rewrite sentence by sentence. Subject-verb-object with the subject early, one idea per sentence, active voice and present tense, conditions first, small words kept ("that", "who", articles), pronouns with more than one possible referent replaced by their nouns, noun stacks broken at two modifiers, hidden verbs uncovered ("install", not "perform an installation"), idioms and phrasal-verb bloat swapped per the substitution table. Kohl's cardinal rule arbitrates every edit: no change that sounds unnatural to a native speaker.
  • Verify every paragraph and sentence against the checklist:
  • One topic per paragraph, the point stated in its first sentence
  • Subject and verb early, at most three linked clauses, no "there is/are" openers
  • Procedures imperative with conditions first
  • Every pronoun's referent unambiguous, every abbreviation defined at first use
  • Terminology consistent with the map from step 4, parallel ideas in parallel form
  • No idioms, culture-specific references, Latin abbreviations, or directional cross-references ("above", "below")
  • The sentence still reads naturally aloud

Done when every sentence passes, or its deviation is deliberate and appears in the report.

  • Deliver. Present the rewrite. Edit files in place only when the user asked for the files to change. After the rewrite, report only what applies:
  • The terminology map, so the user can veto term choices
  • Judgment calls where the source was ambiguous and the rewrite picks one reading
  • Gaps where the source lacks specifics the reader will need

Other skills for the same job

different authors, same section of the catalogue
Doc Coauthoring
by anthropics
vendor ×10

Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.

4k tokens
Changelog Generator
by frostant
×9

Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.

774 tokens
Test Driven Development
by w95
×7

Use when implementing any feature or bugfix, before writing implementation code

2k tokens
Writing Plans
by ZhanlinCui
×4

Use when you have a spec or requirements for a multi-step task, before touching code

816 tokens
Writing Skills
by ZhanlinCui
×4

Use when creating new skills, editing existing skills, or verifying skills work before deployment

26k tokens scripts
Crafting Effective Readmes
by softaworks
×3

Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.

15k tokens
Humanizer
by softaworks
×3

| Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, negative parallelisms, and excessive conjunctive phrases.

6k tokens
Opentrons Integration
by christophacham
×3

Official Opentrons Protocol API for OT-2 and Flex robots. Use when writing protocols specifically for Opentrons hardware with full access to Protocol API v2 features. Best for production Opentrons protocols, official API compatibility. For multi-vendor automation or broader equipment control use pylabrobot.

9k tokens scripts

How to use it

Copy the folder

Take vinta/simple-english from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.