Humanizer: The Skill That Strips AI Tells Out of Your Writing

Humanizer is a Claude Code skill with one job: read a piece of AI-written text and rewrite it so it stops sounding like AI wrote it. No model fine-tuning, no browser extension, just a very specific list of tells (thirty-three of them) and instructions for fixing each one.

View humanizer on GitHub

What it actually checks for

The skill is a single markdown file, not a model or a plugin, built on Wikipedias “Signs of AI writing” page, the same reference editors use to catch bot-written Wikipedia articles. It groups thirty-three patterns into buckets: content problems (inflated significance, vague “experts believe” attributions, promotional filler like “nestled” and “breathtaking”), language problems (rule-of-three padding, passive voice, copula avoidance, that whole family of AI vocabulary words like testament and underscore), and style problems, most notably em dashes, which the skill treats as a hard cut rather than a “use sparingly” suggestion.

That last rule is the one that gets argued about the most, since plenty of human writers use em dashes constantly. The skills own guidance addresses this directly: one em dash proves nothing, but an em dash stacked with rule-of-three lists and the word “tapestry” is a confession.

We actually used this on our own templates

We run a tutorial and mini-blog site, and we plugged this skill directly into our writing templates rather than just reading about it. The interesting part was not the pattern list itself. It was figuring out where it collides with SEO requirements that want the opposite of natural writing: an exact keyword phrase repeated at specific spots, a formulaic title structure, headings written the same way across every post for consistency.

The answer turned out to be a scope boundary, not a compromise. Free body prose gets humanized. Structured metadata (title, meta description, slug), literal heading strings tied to CSS components, and the exact keyword occurrences required at fixed points stay untouched. The two systems do not actually fight; they are optimizing different layers of the same document.

The em-dash rule turned out to matter for a reason that had nothing to do with style. Our publishing pipeline injects HTML through a PHP single-quoted string, and single-quoted PHP does not interpret hex escapes: writing an em dash as an escape sequence inserted the literal eight characters of the escape code instead of the actual character. We had a documented workaround for it. Since the skill treats em dashes as a hard cut rather than a style preference, the whole bug class stopped applying to new posts, not because we fixed the escaping, but because the text feeding into it no longer contains the character that triggers it.

Voice calibration is the underrated feature

Past version 2.4, the skill accepts a sample of your own writing and matches its sentence length, word choices, and paragraph habits instead of defaulting to one generic “human” voice. Feed it a few of your own paragraphs alongside the AI text you want fixed, and the rewrite starts sounding like you specifically, not like a stock human template. Skip the sample and it falls back to a varied, opinionated default voice, which is still a real improvement over most raw LLM output, just less personalized.

Try it

npx skills add blader/humanizer

Or install it as a Claude Code plugin directly: /plugin marketplace add blader/humanizer, then /plugin install humanizer@humanizer. Either way you end up with one file, invoked with a slash command or a plain request to humanize a block of text.

Humanizer will not make a bad draft good. What it does well is catch the specific tics that make competent AI writing read as AI writing: the dashes, the rule of three, the “stands as a testament” reflex. Worth installing even just to run your own writing through it once and see what it flags.