orwell-writing
SolidUse when an agent is asked to draft, rewrite, edit, review, polish, copyedit, simplify, humanize, or create written prose, including creative writing, essays, posts, scripts, speeches, emails, documentation, product copy, and other style-sensitive text. Apply George Orwell's six rules and ASD-STE100 Simplified Technical English as a plain-English discipline while preserving the user's intended meaning, audience, tone, and explicit constraints.
Install
Quality Score: 85/100
Skill Content
Details
- Author
- tamdogood
- Repository
- tamdogood/builder-essential-skills
- Created
- 2 months ago
- Last Updated
- 3 weeks ago
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
ste-writing
Rewrite prose (docs, READMEs, PR descriptions, error messages, release notes, comments, commit messages, changelogs - never code) into ASD-STE100 Simplified Technical English to remove "AI slop". Use when asked to make writing not sound like AI, make docs clear or plain, remove slop or fluff from text, enforce a controlled writing style, or write technical documentation that reads human. Two modes - strict (procedures, safety, error messages) and STE-flavored (general prose).
simple-english
Write or rewrite technical text with the rules of ASD-STE100 Simplified Technical English so it is clear, unambiguous, and free of AI slop. Use for documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports, and API guides. Also use when the user says "STE", "Simplified Technical English", "ASD-STE100", "de-slop", "make this readable", "write for non-native readers", or asks for docs that translate well. Enforces the standard's 53 rules: 20/25-word sentence limits, one word one meaning, simple tenses, active voice, condition before command.
simplified-technical-english
Enforce ASD-STE100 Simplified Technical English (STE) in all technical documentation you write or edit. Use this skill whenever you draft, generate, or revise READMEs, specifications, design docs, architecture decision records (ADRs), runbooks, technical playbooks, API docs, configuration and setup guides, troubleshooting guides, release notes, inline code comments, or docstrings — any project documentation that describes technical aspects of a system. Apply it even when the user does not mention "STE", "controlled language", or "plain English". It keeps documentation short, active, and consistent so a global audience with basic English can read it correctly the first time. Do not apply it to marketing copy, casual chat replies, or narrative prose where a natural voice is wanted.