harshaneel/humanize: nine levers, nine scored signals, and a documented ceiling

The description says best, the benchmark runs twenty-five inputs

The repository description opens with a superlative and no evidence attached to it. That matters less than what the rest of the file contains, because the table of contents advertises a benchmark section described in the index itself as twenty-five inputs scored by two independent scorers. Twenty-five is a demonstration, not a measurement. It can show that the rules fire and that the scorers move in the expected direction; it cannot support a ranking against any competing tool, and the description makes no reference to a comparison having been run. There is also no tagged release and no versioned artefact, so nothing about the rules is pinned: the skill is whatever the current checkout contains, which for a symlink-based install means it changes whenever you pull.

The project separates the goal from the side effect

The most important paragraph in the file is a definition of what static means, and it is worth reading closely because it declines the obvious reading. There are no trained models, no API calls, and no detector in the loop. The skill is described as a rulebook the host model follows. Crucially, the detection research is framed as the measuring instrument rather than the target: it is said to show precisely where machine-written prose diverges from human prose, and closing those gaps is what makes writing read as human. That the same edits also lower scores from perplexity-based detectors is called a consequence and not the goal. The taxonomy the documentation uses separates four detector families, namely zero-shot, classifier, watermarking and hybrid, and it is that separation that makes the project's own ceiling claim coherent rather than promotional.

The contents page has an entire section group for limits

Most skill repositories index only what the tool does. This one divides its index into four groups, and the third is titled limits and what closes them. Inside it sit four entries: detector accuracy numbers taken from published research, a known-limitations section, an entry on what the rule-based approach cannot do described as the learned-classifier ceiling and why it exists, and a complementary-techniques entry naming what closes the gap, among them cross-model paraphrasing, rewriting with a different base model, and manual edits. Putting a ceiling in the index rather than in a footnote is the single most useful thing about the documentation, and it signals that the author expects the limits to be load-bearing. What is not available in the readable portion of the file is the content of those four sections, so the specific claims cannot be checked from here.

Nine levers in, nine signal categories scored

The two skills are described as mirror images of each other. The first rewrites or generates text so it reads the way a person actually writes, with natural rhythm, real specifics and a voice, by applying nine humanization levers taken from the detection literature. Its triggers are ordinary requests such as asking for something to sound less robotic. The second runs the opposite direction as forensic analysis, scoring nine signal categories, citing every flag with evidence, and returning a verdict, a confidence value and an estimate of what fraction of the text was machine-edited. The symmetry is deliberate and useful: the same nine-part structure describes what is changed and what is measured, so the second skill can be read as an audit of the first. Both are static, both are a single markdown file per skill, and neither has any runtime dependency.

Four install mechanisms, three dot-directories, and one path that quietly broke

Support for agent clients is handled with four different mechanisms across seven sets of instructions. Two agent clients take the repository as a plugin marketplace:

claude plugin marketplace add harshaneel/humanize
claude plugin install humanize@humanize

Everything else reads from disk, and a single shell script handles the directories, with an all argument that writes to three locations at once. Two hosted applications cannot read from disk at all and need the files uploaded through a settings interface, one per skill, then toggled on per conversation. Anything else needs no install: you copy the raw text of the skill file and paste it into a new conversation with a short instruction to apply it. One documented trap is worth flagging, because the failure is silent: cloning straight into the skills directory stopped working once the skills were reorganised under a plugins directory, and nothing warns you, the skill simply never loads.

Symlinks by default, copied files when you want them frozen

The install script's default is to symlink, and the reason is given: because the skills are symlinked, pulling new commits applies the update automatically. There is a flag to copy instead, described as the option for people who prefer self-contained files over symlinks. That is the right pair of choices to offer and the trade-off is real in both directions. A symlink keeps the skill in step with the checkout, which is what you want if you are following the project, but it also means deleting or moving that checkout silently breaks three agents at once, and it leaves a pointer into a directory the user may not remember. A copy is inert and survives anything, at the cost of going stale without telling you. For a tool whose whole behaviour is a set of rules that change between commits, that choice is worth making deliberately rather than by default.

Pasting rules into a hosted chat is a different trust decision

The catch-all instructions for web chat clients ask you to open the skill file, copy its raw contents, and paste them into a new conversation prefixed with a sentence telling the assistant to apply those instructions whenever you ask it to rewrite something. That is a categorically different action from installing a local file, and the documentation presents both without distinguishing them. The pasted text becomes part of a prompt in a hosted service, subject to that service's retention and training choices, and it applies to a model that can see the rest of the conversation. It also means the instructions travel as free text with no integrity check, so a modified copy would be indistinguishable from the original. For a skill whose entire payload is a rulebook, that is the main thing to think about before using the route at all.

Classified as markup, with a tests directory and no package manifest

The repository is recorded as a markup project, which is odd for a pair of markdown skills and a shell installer. The reason is a configuration file and an includes directory at the root, which are the conventions of a static site generator, so the published documentation site is what the language classification is picking up. The tree is otherwise small: the skills under a plugins directory, the installer, a tests directory, and two integration directories for agent hosts. The tests directory is the notable part, because the project's headline claim is zero runtime dependencies and a test suite implies something is being executed after all, most plausibly the installer and the skill metadata. There is no package manifest of any kind at the top level, so whatever runs those tests is not declared where you would look for it.

Editorial conclusion

Read this as a writing-quality rulebook with a measurement tool attached, not as a way to defeat detection, which is not what the project claims it is for. It fits someone who wants prose with rhythm and specificity and wants to know which of their sentences read as machine-written. The honest limit is the one the project states itself: rule-based rewriting moves perplexity-style measures and does not clear learned classifiers, so anything where that matters is out of reach without the manual and cross-model steps the documentation names. Anyone submitting work under an honour code or through an institution's integrity process should treat the tool as a drafting aid, not a solution.

Frequently asked questions

Official sources

1. harshaneel/humanize on GitHub
2. Issues
3. License: MIT
4. README