I edit a lot of drafts that started life in a chat window. Some are mine, some come from clients, and a growing share come from tools. For most of this year the last thing I run before a post goes out has been blader humanizer, the open-source agent skill at blader/humanizer on GitHub. If you searched for it because someone in a thread said "just run it through humanizer," this is the write-up I wish I'd had: what it is today, what changed since the early versions most posts describe, and how I actually fit it into a publishing routine.
A quick note on my setup so the rest makes sense. For one small client site, keyword picking and first drafts come out of SupaTraffic, which finds the queries their buyers type and drafts an article for each one. For my own posts I write the first pass myself. Either way, humanizer gets the draft last, right before I read it out loud.
What blader humanizer actually is
It's a skill file. The repo describes itself as an "agent skill that removes signs of AI-generated writing from text," and the core of it is a single SKILL.md that your coding agent loads. There is no web UI, no API key, and no service sitting behind it. It runs inside whatever agent you already use: Claude Code, Codex, Claude Desktop, and the other agents the Skills CLI supports. The repo also ships a Cursor plugin manifest.
The pattern list is built on Wikipedia's "Signs of AI writing" page, the guide Wikipedia editors use when they clean up machine-written articles. So the rules come from people who review a lot of AI text for a living, and the 3.0 release realigned the list with the current version of that page.
The README is direct about one thing that trips people up: getting past AI detectors is not a goal, and detectors still flag most of its output. It edits for human readers. If your plan is to sneak an essay past a classifier, this is the wrong tool, and the author says so up front.
The other rule I lean on is that it does not invent facts. A name, number, date, quote, or citation has to come from the source text or from you. When a sentence needs a detail that isn't there, the skill is told to ask instead of making one up. For client work that one rule is the reason I trust it with a draft at all.
What changed since the posts you'll find on dev.to
The dev.to article that ranks for blader humanizer right now was written in February 2026, when the repo had about 6,600 stars and checked 24 patterns. As of this week it sits at 54.4k stars and 4.3k forks, and the latest release is v3.1.0 from September 28, 2026. The pattern count went up and then came back down, which surprised me when I read the changelog.
| Version | Patterns | What happened |
|---|---|---|
| 2.1.0 | 24 | Before/after examples added for every pattern |
| 2.4.0 to 2.9.x | grew to 33 | Writing-sample matching (2.4.0), new patterns, the no-invented-facts rule (2.9.0) |
| 2.10.0 to 2.11.x | 35 | Patterns for leftover drafting ideas, a Plain Language rewrite |
| 3.0.0 | 25 | Rebuilt around one explanation of why AI text sounds the way it does; 35 merged into 25 |
| 3.1.0 | 26 | New section for replies that re-explain what the reader already knows; Cursor plugin manifest |
The 3.0 rewrite is the interesting one. Instead of a growing list of word bans, the skill now starts from a single idea: a language model picks the choice that fits the widest range of readers, while a person picks for one reader and one subject. Every pattern is treated as a form of that default choice. The patterns are numbered by strength, and the first five justify an edit on a single sighting:
- Not X but Y ("It's not just a feature, it's a shift.")
- One-line closers ("Let that sink in.")
- Sayings that sound deep ("At its core, what really matters is...")
- A staged run-up ("Here's the thing.")
- Arguing with no one ("I'm not saying X, but...")
Some patterns are marked "weak alone" and only count when several tells share a passage. Dashes, stacked qualifiers, hyphenated pairs, passive voice, and curly quotes fall in that group, because a careful writer may use any of them on purpose. In practice, a single dash in a clean paragraph gets left alone, while a paragraph stacked with dashes, hedges, and passive constructions gets rewritten.
The README also cites a blind test where judges preferred the humanizer rewrite over the original AI text 16 times out of 16 (issue #229 in the repo). I haven't run anything like that myself, so take it as the maintainer's claim.
Installing it
Once installed, the skill answers to /humanizer. These are the commands from the current README:
Inside Claude Code 2.1.142 or newer, the plugin route is two slash commands, and the plugin then answers to /humanizer:humanizer:
/plugin marketplace add blader/humanizer
/plugin install humanizer@humanizer
Everything else goes through the Skills CLI in your terminal:
# Claude Code on older versions
npx skills add blader/humanizer --global --agent claude-code
# Codex
npx skills add blader/humanizer --global --agent codex
# every agent the Skills CLI knows about (Gemini CLI, Copilot, Windsurf...)
npx skills add blader/humanizer --global --agent '*'
Drop --global to install it only in the current project. For Claude.ai or Claude Desktop, download the repo as a ZIP and upload it as a skill in Settings. For an agent the Skills CLI doesn't recognize, copy SKILL.md into that agent's skill folder.
How I use it day to day
I use all three modes.
Pasted text. I call /humanizer and paste a section. It returns a first rewrite, a short critique of what still sounds artificial, and a final version. I read the critique more carefully than the rewrite, because it shows which habits keep coming back.
File mode. I point it at the file: Humanize the prose in drafts/launch-post.md. In this mode it writes only the final text back to the file and changes prose only. Code blocks, inline code, commands, paths, front matter, and link targets stay untouched. For dev.to drafts full of code samples, this is the mode I use most.
Voice matching. This is the feature people miss. You can give it two or three paragraphs of your own writing first:
/humanizer
Here's a sample of my writing for voice matching:
[2-3 paragraphs you wrote yourself]
Now humanize this text:
[the draft]
The sample overrides the pattern rules, including the dash rule. If your sample uses dashes, the rewrite keeps them at about the same rate. Without a sample, it takes voice from the type of text: blog posts keep opinions and asides, while reference and technical prose stays neutral.
Blader humanizer vs. building your own
The dev.to post that currently ranks for this topic argues that you should build your own humanizer, calibrated to a corpus of your published writing, because a generic tool checks against a generic baseline and can still leave you with voiceless prose. That's a fair point, and the author's project (voice-humanizer, built on blader's pattern list) is a reasonable answer to it.
The upstream project covers part of that gap. Voice matching from a sample has been there since 2.4.0, and in the current SKILL.md the sample explicitly wins over the pattern list. You don't get a persistent corpus file, so you paste the sample each time or keep it in a snippet. For me that's enough. If you write in several registers (technical posts vs. newsletters, say), keeping two short samples is simpler than maintaining a corpus.
| Need | Upstream blader humanizer | A corpus-based fork |
|---|---|---|
| Strip common AI tells from any draft | Yes, 26 patterns | Yes, inherits the list |
| Match your voice | Paste a sample per run | Reads your corpus file automatically |
| Leave code and front matter alone | Yes, in file mode | Depends on the fork |
| Get updates when Wikipedia's guide changes | Yes, tracked in the changelog | Only if the fork merges upstream |
| Setup effort | One install command | Install plus building a corpus |
My suggestion: start with upstream. Fork it if you find yourself pasting the same sample fifty times a week.
Where it falls short
It won't make a thin draft good. If the source has no specifics, the no-invention rule means the rewrite has none either, and you get a shorter, plainer version of the same empty post. When it asks for a missing detail, answer it; that's where the improvement comes from.
Pattern 26, re-explaining what the reader already knows, only applies to replies, so don't expect it to restructure a long article around a decision.
The full pattern list is in the repo README, grouped into six sections with a before and after for each. It's worth reading once even if you never install anything.
FAQ
Is blader humanizer free?
Yes. It's MIT licensed and runs inside the agent you already pay for or use. There's no separate subscription.
Does blader humanizer bypass AI detectors like GPTZero or Turnitin?
The README says getting past detectors is not a goal and that detectors still flag most of its output. Use it to make text better for readers.
How do I update blader humanizer to v3.1.0?
Reinstall with the same command you used before, for example npx skills add blader/humanizer --global --agent codex. The version is listed in the metadata.version field of SKILL.md.
Does it work outside Claude Code?
Yes. The README covers Codex, Claude.ai and Claude Desktop (ZIP upload), and any agent the Skills CLI supports, including Gemini CLI, GitHub Copilot, and Windsurf. There's a Cursor plugin manifest in the repo too.
Closing thoughts
Humanizer earned its spot as the final pass in my routine because it is conservative: it keeps facts, leaves code alone, and tells me when it needs something it doesn't have. The research and drafting happen earlier, and for the client site that part runs through SupaTraffic, which gives me a calendar of drafts tied to real search queries that I can review and edit before anything goes live. Then the draft goes through humanizer, I read it aloud, and I publish.
Top comments (0)