It edits Chinese prose; it does not detect who wrote it
Humanizer-zh is a set of instructions for an AI agent. You paste Chinese text or point the agent at a file, and the skill asks it to remove filler, repetition, canned phrasing, and other habits associated with machine-written prose. The useful part is the boundary around that editing: preserve facts, uncertainty, attribution, timing, the author's position, and text that is already clear. The repository explicitly says it cannot prove authorship or guarantee passage through an AI detector.
The project is tiny: our scan found 9 files, roughly 37 source lines, and a checkout that rounded to 0 MB. The primary README, SKILL.md, changelog, examples, and checking instructions are in Chinese. No English documentation file appears at the repository root. That focus makes sense for Chinese editing, where four-character phrases, long modifiers, passive constructions, and formulaic background sentences need language-specific judgment rather than a translated English blacklist.
The preservation rules are more useful than the blacklist
Many writing cleaners fail by treating every repeated pattern as evidence of bad prose. Humanizer-zh tells the agent to keep a real list even when it happens to contain 3 items, retain a passive sentence when the actor is unknown, and leave a clear instruction alone. It also says not to turn a possibility into a conclusion or a future plan into completed work. Those constraints matter more than swapping fashionable words, because a smoother sentence is a failure if it changes the claim.
The current material organizes 31 checks into groups covering staged openings, formulaic rhythm, inflated claims, decorative formatting, chatbot residue, and Chinese-specific habits. File mode protects code blocks, YAML, data, headings, link targets, and anchors unless the user authorizes structural changes. That is a practical editing contract. It lets a developer ask for prose work on a Markdown document without silently granting permission to rewrite the commands or move referenced sections.
What happened when we ran it
Our sandbox installation succeeded in 9 seconds, adding 35 packages and occupying 37 MB. The build completed in 1 second. Pip-audit found 0 known vulnerabilities. We used commit f4518a8 in a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. These numbers describe the environment created by the lab pipeline, not the cost of invoking a language model to perform an edit.
Pytest exited with code 5 after 2 seconds. It reported 0 passed, 0 failed, and no tests collected. The log simply says no tests ran in 0.00s; there is no deeper exception to diagnose. The repository does contain a tests directory, but its README describes prompt cases for manual comparison and a Python script that checks whether protected Markdown structure survives. Pytest does not discover that process as an automated suite.
Installation is easy; evaluation stays manual
The recommended command uses npx skills add with the GitHub URL. Manual installation copies the folder into Claude Code's skills directory, and /humanizer-zh checks whether it loads. There is no API token, server, database, or model bundled with the repository. The agent host supplies the model and context. That keeps setup simple, but it also means two model configurations can follow the same instruction differently.
The checking guide asks a reviewer to compare each output with its input: look for invented facts, missing conditions, changed attribution, stronger certainty, altered tone, or damaged structure. A separate script compares protected parts of a Markdown sample. The maintainers also say that a single run, shorter output, or a model's self-score does not prove quality. That is the right standard. Use the skill as an editing brief, then review the result like any other copy edit.
Detector promises are outside the product
One open issue says the output did not pass a named AI detector. The README already answers the larger expectation: Humanizer-zh is not a detector-evasion guarantee. Issue 37 challenged contradictions in the project's own writing, and the September 23, 2026 update rewrote the rules and examples around preserving meaning. Those discussions are relevant because they show users testing the stated purpose, not merely requesting more installation options.
GitHub recorded 18,356 stars, 31 combined open issues and pull requests, and 16 open issues when searched separately. The last push was September 23, 2026, the same date named in the README's update note. There is no GitHub release. Current activity is stronger evidence of maintenance than a missing release tag, though teams should pin a commit if edits must remain governed by one exact rule set.
Use it as a house editing brief
Humanizer-zh works best when a writer can explain the intended voice and inspect the final diff. Give it a sample written by the same author, state whether you want a rewrite or comments only, and keep the source beside the output. For file edits, run the structure checker and review every factual sentence. The skill's MIT license and small size make local adaptation easy if your publication has its own banned phrases or punctuation rules.
Do not buy the premise that one pass makes text human. The repository itself rejects that promise. Its useful contribution is narrower: a Chinese editing checklist that tells an agent what it must not damage. Our 0-test pytest result means trust comes from source comparison and editorial review, not a green test badge.

