← Browse notes

Writing

humanizer: Naming the Traces of AI Writing First

Breaking down blader/humanizer: a set of English writing review rules designed for AI.

Many people say “remove the AI flavor,” but in the end, there is really only one request: be more natural.

This request is too broad. After hearing it, AI usually shortens sentences a bit, deletes some connectors, and adds a bit of colloquial feel. It does read less formal, but not necessarily more human-like. Often, it just swaps one template for another.

I want to break down humanizer because it doesn’t stop at just “be more natural.” It first breaks down AI writing traces into specific types, then lets AI check, rewrite, and review according to those types.

This article doesn’t treat it as a detector or a Python tool. It’s a standard Skill, essentially a set of review rules written for AI.

1. Clarify the Source First

The repository is here:

https://github.com/blader/humanizer

The core file is:

SKILL.md

The repo also contains README.md, AGENTS.md, and Claude Code plugin related configurations. What really makes this Skill work is the set of instructions in SKILL.md.

AGENTS.md also clearly states: this repo is a portable agent skill, and the runtime artifact is SKILL.md. There is no build step and no code to run.

This needs to be clarified first to avoid misunderstandings.

Its usage is closer to “giving a set of review rules to AI” and letting AI edit according to those rules.

How humanizer works: first naming AI writing patterns, then preserving original meaning, and finally rewriting to match the original voice

2. Its Implementation Is Very Simple

SKILL.md starts with a frontmatter section.

It states a few things:

name: humanizer
version: 2.8.2
license: MIT
compatibility: any-agent
allowed-tools: Read / Write / Edit / Grep / Glob / AskUserQuestion

These details tell different agents: the Skill’s name, current version, and which tools are allowed.

The real rules come after the frontmatter.

It first sets a task sequence for AI:

1. Identify AI patterns
2. Rewrite, but don’t just delete
3. Preserve original meaning
4. Match the original voice

This sequence is much more specific than “help me polish this.”

It requires AI to review first, then edit. First see which patterns appear in the text, then decide how to revise. When revising, it must cover the original information and not thin out the content just to remove the AI flavor.

This boundary is especially important for long texts. Many AI flavor removal tools clean up the article so much that they also delete the author’s original pauses, hesitations, and details. humanizer at least sets a boundary: rewrite, don’t delete.

3. It Calibrates the Author’s Voice First

humanizer has a section called Voice Calibration.

If the user provides their own writing samples, it first reads those, then looks at several things:

  • Are sentences short and crisp, or rather long?
  • Is the word choice casual or formal?
  • How do paragraphs usually start?
  • What punctuation habits are there?
  • Are there any fixed catchphrases?
  • Are transitions made with connectors or by jumping directly to the next point?

This part is very practical.

Because the biggest fear in removing AI flavor is turning everyone into the same kind of “natural.” A technical author’s natural style is not the same as a travel blogger’s. The same goes for public account articles—some can have more casual talk, others suit being straightforward.

So humanizer doesn’t just delete AI words; it tries to answer a deeper question: who should this text sound like?

If no sample is given, it falls back to a default style: natural, with varied rhythm, and appropriate viewpoints.

4. It Divides Issues into 33 Categories

The heaviest part of humanizer is the 33 AI writing patterns.

The README divides them into 5 groups. Seeing them this way makes it much clearer:

Content patterns: 6 types
Language and grammar patterns: 7 types
Style patterns: 14 types
Chatbot leftovers: 3 types
Filler and hesitation: 3 types

Expanded roughly into this table:

Group Main Focus
Content patterns Inflated significance, media endorsement, -ing empty analysis, advertising tone, vague attribution, formulaic challenge paragraphs
Language and grammar patterns AI high-frequency words, avoiding is/are, negative parallelism, rule of three, synonym rotation, fake scope, passive voice
Style patterns Em dash, overuse of bold, title case in headings, emoji, curly quotes, hyphenated phrases, aphoristic tone, empty transitions, fragmented dramatic sentences
Chatbot leftovers Phrases like “I hope this helps,” “Would you like…”, “Great question!”—dialogue tone
Filler and hesitation Phrases like “In order to,” “could potentially possibly,” generic positive endings

humanizer divides 33 AI writing patterns into content, language, style, chatbot leftovers, and filler/hesitation groups

The first group is content-level inflation.

For example, significance inflation. Common phrases include:

stands as
serves as
marks a pivotal moment
broader landscape

The problem is it elevates ordinary facts into “important milestones” or “broad landscapes.” Many AI texts look grand just because of this.

The second group is language and grammar inertia.

For example, not only...but..., rule of three, synonym rotation, stacking passive voice. AI loves to write content symmetrically, completely, and smoothly, but reading too much of this smoothness feels fake.

The third group is style traces.

For example, overusing bold, title case in headings, emoji, inline-header lists, and em dash. humanizer is strict about em dash, requiring the final draft to have no em dash or en dash, replacing them with periods, commas, colons, parentheses, or rewriting the sentence.

The fourth group is chatbot leftovers.

For example:

I hope this helps
Would you like...
Let me know if...
Great question!

These are polite phrases in conversations but look awkward in article text.

The fifth group is endings and tone.

For example, generic positive conclusions, persuasive authority tropes, signposting announcements, manufactured punchlines. Simply put, the article insists on being positive at the end or every paragraph acts like “I see through the essence.”

The value of these categories is that AI flavor is no longer just a vague feeling but a checklist of issues.

5. How It Revises: Not a One-Pass Draft

humanizer’s Process and Output are worth noting.

It requires AI to first read the input and mark the patterns above. Then write a draft rewrite.

After the first draft, it asks itself:

What makes the below so obviously AI generated?

In other words: why does this version still look obviously AI?

This step is crucial.

Many rewriting tools deliver after the first draft. humanizer requires another check for leftover AI flavor—whether sentence structures are too uniform, tone too promotional, endings too aphoristic, or em dashes not cleaned up.

Only then does it produce the final rewrite.

So its workflow is not:

Original -> Rewrite

But:

Original -> Mark issues -> First rewrite -> Question leftover AI flavor -> Final draft

This step makes it more stable than ordinary prompts.

6. It Also Defines False Positive Boundaries

One part I like about humanizer is Detection Guidance.

It reminds AI: don’t jump to conclusions just because you see a feature.

For example, perfect grammar doesn’t equal AI. Formal vocabulary doesn’t equal AI. One em dash doesn’t equal AI. Many professional authors write very cleanly, and many editors automatically replace quotes and punctuation.

It also lists some “human writing traces” that should be preserved:

  • Specific yet quirky details.
  • Unresolved contradictions.
  • First-person choices the author can explain.
  • Natural variation in sentence length.
  • Parentheticals, self-corrections, and real pauses.

Removing AI flavor shouldn’t flatten the article. The real danger is AI treating all “imperfections” as flaws and producing a clean but soulless draft.

humanizer at least knows to keep these imperfect places.

7. Its Limitations for Chinese

humanizer’s basic context is still English.

It’s useful for catching English traces like em dash, not only but also, rule of three, -ing analysis, Title Case. These can’t be directly applied to Chinese.

Here you can also check out the Chinese version Humanizer-zh.

The repo is here:

https://github.com/op7418/Humanizer-zh

Its SKILL.md clearly states: core content is translated from blader/humanizer, and practical tools partly reference hardikpandya/stop-slop.

So it’s not reinventing a Chinese rule set but translating the English humanizer problem categories into Chinese, adding Chinese examples and some checklist-like rules.

Its task sequence is similar:

1. Identify AI patterns
2. Rewrite problematic segments
3. Preserve meaning
4. Maintain tone
5. Inject genuine personality

Compared to the English version, Humanizer-zh currently organizes 24 patterns into 4 groups:

Group Count Examples
Content patterns 6 Overemphasizing significance, advertising tone, vague attribution
Language and grammar patterns 6 AI high-frequency words, negative parallelism, rule of three
Style patterns 6 Em dash, bold, emoji, curly quotes
Communication patterns and fillers 6 Collaborative traces, knowledge cutoff dates, flattering tone, filler phrases

For example, the English version catches serves as, vibrant, not only...but...; the Chinese version corresponds to:

作为/充当
充满活力的
不仅……而且……
行业报告显示
此外
至关重要

This step is useful for Chinese users. You don’t need to first understand the English AI writing critique terms; you can directly see Chinese examples to know what it’s catching.

But it also has a boundary: it’s more like a “Chinese adaptation of the English humanizer,” not yet a set of rules specifically tailored for Chinese public account writing.

More common Chinese issues include:

在 AI 浪潮下
真正重要的不是……而是……
这不仅是工具,更是一种能力
形成闭环
持续赋能

And a recent trend: stacking short sentences, each line pressing a judgment.

So I wouldn’t treat humanizer or Humanizer-zh as the final answer for Chinese. They’re better as a first layer: helping you learn to name problems.

Chinese rewriting still needs its own scenario rules. For example, public account intros should quickly get to the point, with less background; technical explanations should keep terminology and not distort implementation for colloquialism; long text rewrites should preserve rhythm and not delete all pauses.

8. Inspirations for Writing Your Own Skill

The most valuable thing to learn from humanizer is how it turns “review preferences” into executable rules.

If you want to write a public account style Skill, don’t just write:

Write more naturally.
Don’t have AI flavor.

These are too vague, and AI can only guess.

You can learn from humanizer’s approach by breaking down the rules:

  • First protect facts, terminology, filenames, and citations.
  • Then list common issues like empty background, mechanical transitions, inflated value, short sentence stacking.
  • Provide Before and After examples for each category.
  • Allow normal sentences to exist; don’t require every paragraph to sound like a conclusion.
  • Finally, add a round of leftover flavor self-check.

A Skill written this way has a chance to be reliably reusable.

9. My Judgment

humanizer is not a universal flavor remover.

Its strength is organizing English AI writing traces into a clear review process. It has no scripts, no models, and no automatic detection interface. It relies on a detailed SKILL.md: first naming problems, then giving examples, then specifying rewriting steps, and finally reminding AI not to falsely flag human writing traces.

For Chinese public account authors, it’s best used as a “problem naming course.” First learn to see the problems, then talk about rewriting.

Just telling AI to “write more naturally” will most likely end up with templates. Clearly naming problems gives AI a real chance to help you revise.