Humanizer: A Markdown Skill That Strips AI Tells From Prose

What Problem Humanizer Actually Solves

Humanizer targets a specific annoyance: text that reads like a language model wrote it. The README is explicit about the cause. LLMs use statistical algorithms to guess what comes next, and the result tends toward the most statistically likely output. That produces a recognizable style, full of inflated importance, name-dropping, fake-candid openings, and forced triads. Humanizer is for people who need to remove those tells without changing what the text says. The intended user is someone already working inside an agent harness that supports skill-style instructions, because the entire skill is plain Markdown. It is not a standalone application. You paste text or point it at a file, and the skill rewrites the prose. The scope is narrow: prose only. Code, data, frontmatter, and link targets are supposed to stay untouched.

The Mechanism: 35 Patterns and a Two-Pass Rewrite

Humanizer's core is a list of 35 patterns drawn from Wikipedia's 'Signs of AI writing' page, maintained by WikiProject AI Cleanup. The README presents them in four groups: content, language and grammar, style, and chatbot patterns. Content patterns cover inflated importance, vague sources, and sales language. Language patterns target overused AI words, passive voice, and false ranges. Style patterns include em dashes, bold text, title case, emojis, and curly quotes. Chatbot patterns remove leftover assistant phrasing like 'I hope this helps' and knowledge-limit disclaimers. The rewrite process has two passes. The first pass does not treat the original structure as fixed. Then it checks the draft against the patterns and the original claims, rewriting whatever still needs work. The README also says Humanizer shows its work: when you paste text, you see the first rewrite and a short critique of anything that still sounds artificial.

Getting It Running: Commands and Config Keys

There is no installation step in the README. Because the skill is plain Markdown, you invoke it like any other skill. The direct form is a slash command: /humanizer followed by pasted text. You can also ask in plain language, for example 'Please humanize this text: [your text]'. For files, you give a path: 'Humanize the prose in docs/launch-post.md'. The README does not list any configuration keys, environment variables, or setup commands. There is no Python API exposed in the README, despite the repository's primary language being listed as Python. The skill itself is the deliverable. That simplicity is a double-edged sword: it runs anywhere, but you get no knobs to tune. The only customization is voice matching, which you trigger by including 2-3 paragraphs of your own writing in the same prompt. The skill then follows that sample's rhythm, word choice, punctuation, and deliberate quirks.

The Factual Guardrail and Its Limits

Humanizer claims it does not make things up. The README states that a name, number, date, quote, citation, or other factual detail must come from the source or the writer. If details are missing, the skill should ask instead of inventing them. That is a meaningful safeguard, but it is only as strong as the underlying model's discipline. The README gives an example where the month and neighborhood in a Lisbon travel piece need to come from the writer. If they are missing, Humanizer should ask. 'Should' is the operative word. There is no enforcement mechanism described, no verification step that checks facts against an external source. The skill relies on prompt-level instructions. A model that ignores instructions will still hallucinate. The critique pass may catch some issues, but the README does not say it catches factual errors specifically. It says it critiques anything that still sounds artificial. That is a style check, not a fact check.

Where Humanizer Is the Wrong Tool

The README says Humanizer changes only prose, leaving code, data, frontmatter, and link targets alone. That is a promise, not a guarantee. If you point it at a file with dense JSON or YAML frontmatter, the model must correctly identify what is prose and what is not. Mistakes are possible, and the README does not describe any mechanism to prevent them beyond the instruction itself. For technical documentation with heavy inline code, this is risky. A wrong rewrite could break a command example or alter a config value. The skill is also a poor fit for text that is already short and direct. The pattern list targets verbose AI style. If your source text is terse and factual, there may be little to rewrite, and the skill might introduce changes that are unnecessary. Finally, if you need to preserve a specific citation format or a particular brand voice, the default style rules may conflict. The README says technical and reference prose stays neutral and plain. That is fine for some projects, wrong for others.

A Real Alternative: Editing by Hand or a Different Tool

The obvious alternative is to do the editing yourself. Wikipedia's 'Signs of AI writing' page is the same source Humanizer uses. You can read that page and apply its patterns manually. That gives you full control over every change, which matters when factual details are at stake. The trade-off is time. Humanizer automates the first pass and the critique, which is useful for long documents. Another alternative is a general-purpose rewriting tool that does not constrain itself to Wikipedia's list. Such a tool might catch different tells, but it also risks changing meaning more aggressively. Humanizer's approach is conservative by design: it keeps the original claims and only removes style artifacts. A hand edit is slower but more precise. A broader tool is faster but less predictable. Humanizer sits in the middle, and its value depends on how well the 35 patterns match the AI tells you actually see in your writing.

Maintenance and License Considerations

The repository is active. The last push was August 2026, with releases v2.11.1, v2.11.0, and v2.9.1 within the past month. That suggests ongoing maintenance, but the README does not describe a changelog or upgrade path. You will need to track new releases manually and re-test your workflows when the pattern list changes. The license is MIT, which is permissive. You can use, modify, and redistribute the skill freely, including in commercial products. The main implication is that you can fork it and adjust the patterns to your own needs. That is a real advantage if the default 35 patterns do not cover the tells you encounter. The README does not mention any dependencies, so the maintenance burden is low: it is just Markdown. The risk is that the skill's behavior depends on the underlying model's interpretation of the patterns. A model update could change how faithfully the skill follows its instructions.

Editorial conclusion

Adopt Humanizer if you write in a skill-capable agent harness, need to de-AI long-form prose without changing facts, and can supply a writing sample for voice matching. Skip it if your text is heavy with code, data, or frontmatter that you cannot risk altering, or if you need guaranteed factual verification, since the skill relies on the writer or source for every detail. Before adopting, verify that your harness passes file paths correctly and that the skill's pattern list matches the AI tells you actually see in your output. Test it on a short piece with known factual details to see whether the rewrite preserves them, and check whether the critique pass catches what you care about.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes