Simple English OpenCode: A Skill That Rewrites Text Until Every Word Earns Its Place

⬅️ Back to Projects

🔧 Simple English OpenCode

What it isAn OpenCode skill that rewrites verbose or AI-sounding prose into simple English
StackSKILL.md + markdown references, YAML frontmatter, GitHub, symlink install
StatusWorking, v1 released (MIT)
Codegithub.com/TMFNK/Simple-English-OpenCode

The itch: every humanizer pass I ran on a draft cleaned the tells, but the result stayed wordy, passive, and mechanically varied. I wanted a rewrite that was short, plain, and active, and that showed me what it cut. So I built Simple English OpenCode, a skill that rewrites marketing copy, docs, blog posts, specs, and AI text under fixed rules, then returns the rewritten text, a cuts table, and before/after stats. On a Shopify enterprise page it took 85 words to 50 and average sentence length from 28 to 8 words. The rules do the work.

What I learned

  1. Fix the output shape first. Before writing any rule, I decided every run returns the same three blocks: the rewritten text, a cuts table, and before/after stats. That contract makes the skill auditable. You see exactly what changed and why, which stops the agent from polishing quietly in the background.

  2. Set sentence limits by passage type, not by mood. Procedural text caps at 20 words, descriptive at 25, and each paragraph holds one topic. The skill classifies the passage before rewriting, and it refuses to mix instructions with explanations in one paragraph. “If the build fails, read the log” is the shape: condition first, command second.

  3. “One word, one meaning” beats a ban list. Forbidding synonym rotation with a rule beats listing every word to avoid. Check, verify, confirm, and validate collapse to one verb for the whole piece; config, settings, and options collapse to one noun. It kills a tell that no finite list can catch.

  4. Untouchables make it safe on technical text. Code, identifiers, CLI commands, quoted errors, and numbers with units are exempt and count as one word toward the limit. Without this, a rewrite would rename variables or paraphrase error strings and break the copy. In the GitHub docs example, gh repo create stays exactly as written.

  5. The hardest rule to hold: never invent facts. A rewrite cannot add claims. “Best-converting checkout on the planet” becomes “strong conversion driver” in the Shopify example, because the superlative is unsupported. Empty claims get cut or replaced with a concrete fact that already exists in the source. Otherwise the skill becomes a lie generator.

  6. The self-check is part of the skill, not a suggestion. Four passes run before delivery: count the three longest sentences, search for has been, should, , making, semicolons, and the synonym words, check that every if or when in a procedure leads the sentence, then re-scan vocabulary. The rules only hold if the agent audits itself.

  7. The honest catch: simple English can over-correct into flat, charmless prose, and the word counts in Stats are approximate. Genre hints for marketing, docs, blog, and spec exist to stop the flatness, and the examples show a rewrite of a real landing page. This is a practical tool, not ASD-STE100 compliance, and it shows.

How it works

The skill is one SKILL.md with three reference files: substitutions for filler, genre notes, and a longer checklist. It triggers on “rewrite”, “simplify”, “de-slop”, “plain English”, “make this readable”, and runs in three modes: Rewrite, Check, and Shorter (about 30% fewer words). Install is a symlink into ~/.config/opencode/skills/ or a project .opencode/skills/, and opencode also picks up .claude/skills/ and .agents/skills/. The skill ships with two real before/after examples: Shopify’s enterprise page and GitHub’s repository quickstart.

Steal this if: you write for a living and you’re tired of AI-flavored prose, or you’re building a skill and want a fixed output contract instead of vibes. Skip it if you want full aerospace-grade controlled vocabulary.

Related TMFNK Content

Crepi il lupo! 🐺