Humanizer: A Skill That Strips the AI Tells Out of Your Writing

You can usually feel it. The em dashes everywhere, the “it’s not just X, it’s Y,” the paragraph that opens with “Let’s dive in” and closes with “the future looks bright.” AI-drafted prose has a house style, and once you’ve seen the tells you can’t unsee them. Neither can your readers. Humanizer is a small open-source skill that rewrites text to remove those tells, working from a concrete checklist rather than vibes: 33 documented patterns of AI writing, lifted from Wikipedia’s “Signs of AI writing” guide.

It’s a plain-Markdown agent skill (MIT-licensed, ~27,700 GitHub stars) that runs inside Claude Code or any harness that supports skills. There’s no API to call and nothing to sign up for. This post covers what it is, how it works, what independent coverage says, and the honest tradeoffs, including the ethics, because “make AI text look human” is a loaded thing to automate. Facts are from the project’s README plus third-party coverage, checked 2026-07-04.

A note before we start. This post was itself run through a humanizer pass, which is why there are no em dashes below and almost no bold. The earlier draft had 22 em dashes and 20 bolded labels, the same tells it describes. I used Anthropic’s humanizer skill rather than blader/humanizer itself, since both work from the same Wikipedia guide, so read this as a demonstration of the idea and not as a test of the specific tool. Every number, quote and link survived the pass unchanged.

What it is

Humanizer is a portable agent skill: a single SKILL.md file of instructions the model reads and follows, not a model or a hosted tool. It detects and rewrites 33 patterns that make text read as AI-generated, grouped into content, language, style, communication and filler categories, each with a before/after example. The rules are grounded in Wikipedia’s Signs of AI writing guide, maintained by WikiProject AI Cleanup from observations of thousands of AI-text instances. Because it’s just Markdown, it installs across harnesses (Claude Code, OpenCode, Cursor, and others via the skills CLI) and runs locally in whatever agent you already use.

Why it matters

The value is that it turns “this sounds like a robot” into a specific, fixable list instead of a vague complaint. A few of the tells it targets, with the fix:

• Em-dash overuse: cut them, using periods, commas, colons or parentheses instead.
• Rule of three (“innovation, inspiration, and insights”): use the natural number of items.
• Negative parallelism (“it’s not just X, it’s Y”): state the point directly.
• Signposting (“Let’s dive in”, “Here’s what you need to know”): start with the content.
• Filler (“in order to”, “due to the fact that”): “to”, “because”.
• Significance inflation (“a pivotal moment in the evolution of…”): the plain fact.

Even if you never humanize a single draft, that list doubles as a self-edit checklist for anyone who writes with AI, which is part of why it resonated. It also does a voice-calibration pass: give it two or three paragraphs of your own writing and it matches your sentence rhythm and word choices instead of producing generic “clean” output.

How it works

There’s no magic model here. It’s prompt engineering as a reusable artifact. The skill hands the agent an explicit rulebook: for each of the 33 patterns, what it looks like and what to do about it. The model reads your text and applies the rewrites. Then comes the part that makes it more than find-and-replace, a final audit pass that asks “what makes this obviously AI generated?” followed by a second rewrite to catch what the first one missed. If you supplied a writing sample, the rewrite is steered toward your voice rather than a neutral one. Everything runs in your existing agent, and nothing is sent to a separate humanizing service.

Getting started

The cross-agent install is one line via the skills CLI:

npx skills add blader/humanizer
# into every configured harness:
npx skills add blader/humanizer --agent '*'

Claude Code users can install it as a plugin instead, then invoke it as /humanizer:humanizer:

/plugin marketplace add blader/humanizer
/plugin install humanizer@humanizer

Either way, usage is just: invoke the skill and paste your text (/humanizer then the text), or ask in plain language (“Please humanize this text: …”). For voice matching, paste a sample of your own writing first.

In practice

The intended workflow is an editing pass on an AI-assisted draft: you write with an agent, then run Humanizer to sand off the tells before the text goes out. The README’s worked example takes a gushing, em-dash-laden travel post (“this city completely stole my heart… a vibrant testament to Portugal’s enduring spirit”) and rewrites it into something specific and uneven, a first-person recap with real detail and varied rhythm, the kind of thing a person actually writes. The goal isn’t a cleaner text so much as a less statistically average one. As the guide it’s based on puts it, LLMs tend toward “the most statistically likely result,” and Humanizer’s job is to pull the text back off that center.

A real run, start to finish

Here is what it looks like in use. I pointed the skill at one section of a draft in Claude Desktop, without handing it the original source document. The agent’s own trace, in order:

Then it wrote back a report, which turns out to be more useful than the rewrite itself, because it says what changed and why:

• Em dashes: all of them. There were six in the section, and it is the most reliable tell of generated text. Replaced with full stops, commas, colons or brackets, depending on the case.
• Bold: from about thirty instances down to zero. It had been applied mechanically, often to words that did not need it (“two”, “zero”, “expensive”). When everything is bold, nothing is.
• Headings that repeated themselves. One read “The problem in one line” and was followed by a line stating the problem. The heading was already the sentence, so it went, and the text now starts directly.
• The “Label: content” pattern, which showed up in one section and again in the closing numbered list. It is a shape that comes from chatbot output. They are ordinary sentences now.
• The bullet list inside the plain-language explanation became a paragraph. Someone explaining an idea out loud does not speak in bullets, and the metaphor held better in continuous prose.
• Sentence length varied more. Before, nearly every sentence ran to the same middling length, which is another common sign. Short and long ones now alternate.

What it deliberately left alone: the table, the two calculation blocks, the formula, and every number. The skill instructs the agent not to touch data or code, and no fact changed in the pass. The same percentiles, the same 0.20 and 55.2, the same four and three stars.

Two things stand out from that run. The skill loaded twice, which is harmless but a reminder that these traces are not always tidy. More importantly, the report is the real deliverable. It is a diff in prose, so you can argue with any single change instead of accepting a black-box rewrite.

For reactions beyond the README, it drew repeated Hacker News discussion and spawned a crop of derivative skills (one fork advertises 43 patterns and an AI-tell score). The idea also jumped to academia. Nature covered an academic adaptation of the same approach, a humanizer tuned for papers and grant proposals, which is where the sharpest criticism surfaced (below).

How it compares

Against the commercial “AI humanizer” web tools, Humanizer is the transparent, developer-flavored option. It’s open source, lists every pattern it applies, runs locally without a signup, and makes no claim about beating any AI detector, which is what most paid humanizers sell as the whole point. Against simply prompting your agent to “write more naturally,” it’s more reliable because the rules are explicit and applied consistently, and because of the audit second pass and the voice calibration. Be fair to the alternatives, though. A good human editor still beats it, the paid tools optimize hard for detector evasion if that’s genuinely what you need, and a personal style guide baked into your agent’s instructions covers much of the same ground for your own writing.

Performance and benchmarks

There are no published benchmarks. No measured “AI-detector pass rate,” and the project pointedly doesn’t promise one. What exists is adoption (~27,700 stars) and the provenance of the rules: they trace to a maintained Wikipedia guideline rather than one person’s taste, which is the closest thing here to a credibility signal. Treat effectiveness as unmeasured, and remember that output quality rides entirely on the model running the skill.

Tradeoffs

The honest cons, including the one that isn’t technical:

• The ethics aren’t hypothetical. “Make AI text undetectable” is the exact use case for academic dishonesty and undisclosed AI content, a concern that sharpened when the approach was adapted for research papers and grant proposals. Nature covered that adaptation with alarm about eroding trust and disclosure norms. Humanizer itself doesn’t beat detectors by design, and removing AI tells doesn’t remove your obligation to disclose AI assistance where it’s expected. Use it to edit, not to deceive.
• It’s still an LLM rewrite. The model can change meaning, drop nuance or introduce errors, and it does not fact-check. Reread the output against the original.
• Some rules are blunt. Cutting every em dash and banning the rule of three is not what a human editor would do. Applied literally, the skill can flatten a legitimate voice while it removes the AI one.
• These are heuristics rather than a specification. The 33 patterns are observed tells from an evolving Wikipedia guide, and new model “accents” appear faster than any list can be updated.
• Quality depends on the model and on the sample you give it. Without a voice sample you get a generic kind of natural rather than your own, and a weak model humanizes weakly.
• Versioning is loose. There are no formal releases; the version lives in the README (currently around 2.8.x) and moves as patterns are added.

Takeaway

Reach for Humanizer when you draft with AI and want the result to stop announcing itself. It works as an editing aid that turns a fuzzy “this sounds like a bot” into 33 concrete fixes, with a voice-matching pass so the rewrite sounds like you rather than like no one. Its best quality is honesty about its own limits: open patterns, local execution, and no snake-oil promise to defeat detectors. Keep the line clear in your head, though. It’s for making your writing better, not for pretending a machine’s writing is yours. And even if you never run it, read the pattern list once. It’s the cheapest writing lesson in the repo.