publish-plugins
(project) Use when editing any file under skills/ or plugins/ to bump the plugin version and check the manifests
Use when the user explicitly asks for simple English, plain English, or for text a non-native English speaker can read easily — rewrites docs, READMEs, issues, comments, or UI text into plain words and translation-friendly grammar, still native-sounding. Prose the user signs in
$ npx -y skills add vinta/hal-9000 --skill simple-english --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/simple-englishContext preview
The summary Claude sees to decide when to auto-load this skill.
Use when the user explicitly asks for simple English, plain English, or for text a non-native English speaker can read easily — rewrites docs, READMEs, issues, comments, or UI text into plain words and translation-friendly grammar, still native-sounding. Prose the user signs in
name: simple-english description: Use when the user explicitly asks for simple English, plain English, or for text a non-native English speaker can read easily — rewrites docs, READMEs, issues, comments, or UI text into plain words and translation-friendly grammar, still native-sounding. Prose the user signs in their own voice goes to write-like-me instead argument-hint: [text, file, or pointer to rewrite] model: claude-opus-5-5 effort: medium
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.
1. **Load the rules.** Read [references/writing-rules.md](references/writing-rules.md) in full: sentence structure, word choice, the clarity helpers, tone, and the substitution table.
2. **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 state (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.
3. **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.
4. **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.
5. **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 main rule decides every edit: no change that sounds unnatural to a native speaker.
6. **Verify every paragraph and sentence** against the checklist:
Done when every sentence passes, or its deviation is deliberate and appears in the report.
7. **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:
Opinionated AI coding agent and dev environment automation for macOS that dominates your dev setup like cats rule the Internet. This project is named after Arthur C.
(project) Use when editing any file under skills/ or plugins/ to bump the plugin version and check the manifests
(project) Use when upgrading install tasks in playbooks/roles/ against upstream docs — bumping a pinned version, adopting a newly…
Use when auditing Claude Code or Codex settings and env vars against the latest docs to suggest tailored changes
Use when about to choose, configure, or refine a tool, library, config format, API pattern, or project setup, or before proposing…
Use when the user asks for a blindspot pass or to find their unknown unknowns, or signals unfamiliarity with a domain, tool, or…
Use when making any git commit. Pass the failure, false claim, or risk the changes fix as the argument; for an addition or a…