blader/humanizer: an agent skill that rewrites AI tells out of your prose
Agent skill that removes signs of AI-generated writing from text. It is plain Markdown, so it can run in any harness that supports skill-style instructions.
At a glance
- What is it?
- Humanizer is a Markdown skill built on Wikipedia's Signs of AI writing guide. It rewrites 26 patterns of machine-flavoured prose in Claude Code, Codex and other skill-aware agents, and it explicitly does not try to beat AI detectors.
- Who is it for?
- Adopt blader/humanizer if you already work inside Claude Code, Codex or another agent the Skills CLI supports, and you want a documented, pattern-by-pattern pass over prose you suspect was machine-shaped. Skip it if your goal is passing an AI detector, since the README states detectors still flag most of its output, and skip it if you need a library you can call from your own Python code, because the repository ships a skill rather than an importable package.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Humanizer actually fixes, and who it is for
The problem Humanizer targets is not grammar and not detection evasion. It is the specific set of habits a language model falls into when it picks the most probable next sentence: a line that announces importance instead of adding a fact, three items where one would do, a closing sentence that restates the paragraph above it. The project is built on Wikipedia's Signs of AI writing page, the guide Wikipedia editors use to spot machine-generated text, and it turns that guide into a checklist an agent applies to your draft.
The audience is narrow and specific. You are writing inside an agent that supports skill-style instructions, you have text that reads as machine-produced, and you want it to read as though a person wrote it without changing what it claims. The README is direct about the boundary: Humanizer edits for human readers, getting past AI detectors is not a goal, and detectors still flag most of its output. That sentence alone disqualifies it for a chunk of the people who search for the phrase "AI humanizer for free". If your requirement is a green checkmark from a detector, this is the wrong tool and the project says so.
The 26 patterns, ranked by how strongly they signal a machine
Humanizer does not run a statistical classifier. It carries a numbered list of 26 patterns, ordered by strength and frequency, and it rewrites any of them on sight. The first five justify an edit from a single sighting: not X but Y constructions, one-line closers and dramatic fragments, sayings that sound deep, a staged run-up before the point, and arguing with no one. The rest are grouped under rhythm by rule and similar headings, and some are marked weak alone, meaning a careful writer might use one on purpose and it only counts when several tells share a passage.
That ranking is the most interesting design decision in the project. A flat checklist would flag every em dash and every triad; a ranked one lets the agent spend its edit budget where the evidence is strongest. The trade-off is that the boundary between strong and weak is a judgement call encoded in prose, not a threshold in code, so two runs over the same text can land differently. The README does not document a way to tune that ranking.
How the rewrite runs: mark, draft, check, finalise
The mechanism is a four-stage pass described in the README. Humanizer marks every tell it finds, strongest first. It drafts a rewrite without treating the original structure as fixed. It checks that draft against the patterns and against the original claims. Then it writes the final version.
Two constraints sit on top of that loop. The first is a no-invention rule: a name, number, date, quote or citation must come from the source or from the writer, and if a sentence needs a detail that is missing, Humanizer asks rather than inventing one. The second is scope. When you paste text, the skill shows its work, meaning the first rewrite, a short critique of anything that still sounds artificial, and the final version. When you point it at a file, it changes only the prose and leaves code, data, frontmatter and link targets alone.
That file mode is where the design gets opinionated. Personal writing keeps the writer's opinions and quirks; technical and reference prose stays neutral and plain. The same tool applies opposite registers depending on what it thinks it is editing, and the README does not spell out how it decides which register a given file belongs to.
Installing the humanizer skill and running a first rewrite
Installation depends on your agent. For Codex, and for every agent the Skills CLI supports, the README gives a single npx command. Run it and the CLI reports which agents it configured.
npx skills add blader/humanizer --global --agent codexDropping --global installs it only in the current project instead of for your whole user profile. Passing --agent '*' installs it for every agent the Skills CLI knows about, which the README lists as including Gemini CLI, GitHub Copilot and Windsurf.
In Claude Code the route is the plugin marketplace, and the plugin answers to a namespaced command rather than the bare one.
/plugin marketplace add blader/humanizer
/plugin install humanizer@humanizerThe README states this requires Claude Code 2.1.142 or newer. On older versions it points you back to the npx route with --agent claude-code. For Claude.ai and Claude Desktop there is no command at all: download the repository as a ZIP from Code, Download ZIP, and upload it as a skill in Settings.
Once installed, the skill answers to /humanizer. The plainest first use is to paste text after the command.
/humanizer
[paste your text here]You should see three things back: a first rewrite, a short critique of what still sounds artificial, and a final version. To rewrite a file instead, name its path. The README's example is Humanize the prose in docs/launch-post.md, and the expectation is that code, data, frontmatter and link targets come out unchanged.
If you want the output to sound like you rather than like a neutral editor, the README supports a voice sample: paste two or three paragraphs of your own writing before the text you want rewritten. The skill then follows the sample's rhythm, word choice, punctuation and deliberate quirks, including dashes if your sample uses them. That last detail matters, because pattern 8 in the list treats dashes as a weak tell on their own, and a voice sample overrides the default.
Where Humanizer fails, and the claims it does not make
The largest limitation is stated by the project itself: detectors still flag most of Humanizer's output. Anyone arriving from a search for an AI humanizer that defeats detection has the wrong product. The README frames the goal as editing for human readers, which is a different objective with a different success criterion.
The second limitation is structural. Humanizer is plain Markdown, so it runs only where an agent will load skill-style instructions. The README notes that for an agent the Skills CLI does not know, you copy SKILL.md into its skill folder by hand. There is no documented library API, no Python entry point and no CLI of its own, even though the repository's primary language is listed as Python. If you wanted to call this from a build pipeline or a CI job, the repository gives you nothing to call.
The third is verification. The README cites a blind test in which judges preferred Humanizer's rewrite over the original AI text 16 times out of 16, linking to a GitHub issue. That is a single reported result with no described sample, no selection method and no independent replication in the README. Treat it as a claim from the project, not as a benchmark. The no-invention rule is also a soft guarantee: it is an instruction to the model, not a validator that compares every number in the output against the input, and the README does not describe a check that would catch a hallucinated figure after the fact.
How it differs from a detector-driven rewriting service
The obvious alternative is a hosted AI humanizer, the category the related searches keep pointing at, where you paste text into a web form and get a rewrite scored against a detector. The difference in approach is the whole point. A detector-driven tool optimises against a classifier's output, which means its target moves every time the classifier is retrained, and its success metric is a score rather than a sentence. Humanizer optimises against a published editorial guide, so its target is stable and inspectable: you can read the 26 patterns and disagree with any of them.
A second alternative is the general-purpose editing pass already inside your agent, or a grammar tool. Those fix mechanics and clarity but have no opinion about staging, forced triads or one-line closers, because those are not errors in any style guide aimed at correctness. Humanizer's list is specifically about the residue of statistical text generation, which is why the patterns read the way they do.
The cost of Humanizer's approach is that it cannot promise a number. A detector-driven service can at least report a before and after score. Humanizer reports a rewrite, a critique and a final version, and the judgement of whether the prose improved is left with you.
Maintenance, licence and what a version bump costs you
The repository is not archived, and the last push was on 2026-09-28, the same day as the v3.1.0 release. The release history shows v3.0.0 on 2026-09-06 and v2.11.1 on 2026-08-18, so the project has been cutting versions on a roughly monthly cadence across the period the release notes cover.
Upgrade cost is unusually low for a tool of this kind, and that is a consequence of the architecture rather than a promise. The skill is plain Markdown and the patterns are numbered prose, so a version bump changes instructions the agent reads, not an interface you compile against. There is no dependency to pin and no migration guide to follow in the README. The flip side is that a change to the pattern list can shift output on text you had already accepted, and since the numbering is ordered by strength, reordering is a behavioural change even when no pattern is added or removed. The CHANGELOG.md file at the repository root is where that would be recorded; the README itself does not document a rollback path if a new version rewrites more aggressively than you want.
The licence is MIT. That is permissive and permits commercial use and modification, but this is a description of the licence identifier, not legal advice; read the LICENSE file and your own counsel if the terms matter to your organisation.
Editorial conclusion
Adopt blader/humanizer if you already work inside Claude Code, Codex or another agent the Skills CLI supports, and you want a documented, pattern-by-pattern pass over prose you suspect was machine-shaped. Skip it if your goal is passing an AI detector, since the README states detectors still flag most of its output, and skip it if you need a library you can call from your own Python code, because the repository ships a skill rather than an importable package. Before relying on it, verify two things yourself: that your agent version meets the Claude Code 2.1.142 floor the README names for the plugin route, and that a rewrite of one of your own files leaves code, frontmatter and link targets untouched as the README claims.
Frequently asked questions
How do I install the humanizer skill in Claude?
In Claude Code, add the marketplace with /plugin marketplace add blader/humanizer and then run /plugin install humanizer@humanizer. The README states this needs Claude Code 2.1.142 or newer; on older versions it directs you to npx skills add blader/humanizer --global --agent claude-code. For Claude.ai and Claude Desktop there is no command: download the repository as a ZIP and upload it as a skill in Settings.
How do I use the humanizer skill in Claude?
Once installed, the skill answers to /humanizer, and the plugin form answers to /humanizer:humanizer. Paste your text after the command, or ask in plain language such as "Please humanize this text". You can also give it a file path, for example asking it to humanize the prose in docs/launch-post.md.
Does Humanizer AI get detected?
The README states that getting past AI detectors is not a goal and that detectors still flag most of Humanizer's output. The project describes its purpose as editing for human readers rather than defeating detection.
How do I humanize my text with blader/humanizer?
Call /humanizer and paste the text, or point the skill at a file and it changes only the prose, leaving code, data, frontmatter and link targets alone. When you paste text, the README says you get a first rewrite, a short critique, and a final version. Including two or three paragraphs of your own writing as a sample makes the rewrite follow your rhythm and word choice.
Can I use Humanizer in Grammarly or ChatGPT?
The README does not describe a Grammarly or ChatGPT integration. Humanizer is plain Markdown and the README lists Claude Code, Codex, Claude.ai, Claude Desktop, and agents the Skills CLI supports such as Gemini CLI, GitHub Copilot and Windsurf. For an agent the Skills CLI does not know, the README says to copy SKILL.md into its skill folder.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/blader-humanizer)
Community notes