A "Humanizer" Should Not Become a House Style Manual

A developer I work with sent this skill over recently, asking whether it was worth adopting across the agency's client projects (an additional pass before publication under a client's name). That's a fair question to ask before rolling something out across multiple sites, so I read the source rather than taking the pitch at face value.

The Humanizer skill (blader/humanizer) is MIT-licensed and distributed as a portable agent skill for Claude Code and other compatible agent harnesses. As of commit 523374d ("Improve skill packaging and portability," v2.9.1), it catalogues thirty-three patterns commonly associated with AI-generated prose: inflated claims of significance, promotional filler, vague "experts say" attribution, rule-of-three padding, synthetic upbeat conclusions, and the habit of replacing a plain verb with an elaborate one. Editors run into most of these every week, regardless of whether the draft came from a language model, a press office, or a writer trying too hard.

The trouble starts where the skill stops describing AI habits and starts prescribing a single house style.

Editing for consistency is not the same as recovering a voice

Every publication needs conventions: how headlines are capitalised, how ranges are punctuated, how quotations are formatted, how compound modifiers are hyphenated. Without them, a publication reads as though every article arrived from a different decade and a different keyboard.

I use versions of many of this skill's underlying instincts in my own editorial work at The DropTimes. I cut vague claims, question passive constructions that hide who did what, and remove formulaic openings and closings, with or without AI in the loop. These are newsroom disciplines. They are not, by themselves, tests of whether a sentence was written by a human.

A house style deliberately narrows individual variation. That is often the point of a house style: it makes many writers read as one publication. A novelist, essayist, or memoirist may want the opposite: private rhythm, recurring punctuation quirks, deliberate repetition, uneven sentences. A tool built to strip "AI tells" out of prose needs to tell the difference between erasing a machine's habits and overwriting an author's.

The dash rule, read closely, still treats two different marks as one problem

I checked the skill's source directly rather than relying on secondhand description of it. In v2.9.1 (commit 523374d), Section 14 states that the final rewrite must contain no em dashes or en dashes, calling this "a hard constraint, not a 'use sparingly' preference," and closes with a self-check: scan the finished draft for either character, and if either appears, the draft isn't done. It does carry one named exception: a user-supplied writing sample that uses em dashes "overrides this rule," matching the sample's frequency instead of banning them outright.

That exception is worth reading carefully, because of what it doesn't say. It's scoped to em dashes. Nothing in the clause extends the same relief to en dashes. A writer whose sample habitually punctuates ranges as "2023–2026" or "pages 10–15" hasn't been shown, in the rule's own wording, to have earned an exemption for that mark—only for the em dash. Two typographically distinct marks, doing two different jobs, are bundled under one rule heading, and the one carve-out that exists only reaches half of it.

That distinction matters because the two marks aren't interchangeable, and treating them as if they were makes the rewrite less accurate, not more human. An em dash marking a genuine interruption or contrast and an en dash marking a date range or a page span do different work. Absent a supplied sample (the default case for most text run through this skill), both still get removed regardless of whether either was ever part of a real AI-writing pattern in that specific document, or just an ordinary punctuation choice a person happened to make.

For reference, here is how I handle the same marks in the editorial guidelines I wrote for The DropTimes, not as a claim that this is the only correct system, but as a working example of rules built around function rather than character-avoidance.

A colon announces; it doesn't decorate. It introduces a list, an explanation, a quotation, or a formal result, and if the sentence reads cleanly with a comma in its place, the colon doesn't belong there.

A semicolon links two independent but closely related thoughts, or separates list items that already contain commas internally. It is a structural bridge, not a flourish: if "and" or "but" would be clearer, use those instead.

An em dash is reserved for deliberate interruption, definition, or contrast, treated as the strongest and least frequent of the three options, not a default. Used for definition, it can carry real information cleanly:

Drupal recipes—packages that automate module installation and configuration—are now available in core.

A comma version of that sentence would be weaker and more ambiguous; the dash is doing actual work there, not decorating. (The definition here is broader than "configuration bundles," since Drupal recipes can install modules and themes as well as apply configuration.)

TDT Editorial Style Guide

An en dash marks a range or a connection (pages 10–15, 2023–2026), a distinct typographic function from the em dash's job of interruption. Collapsing "2023–2026" into "2023-2026" doesn't make a sentence sound more human. It just makes the typography less precise.

None of these rules exists to make prose sound more "human." They exist because each mark does a specific job, and a text that uses the wrong one is harder to read accurately, not just less stylish.

Title case is a house-style decision wearing an AI-detection label

The skill also lists title-case headings as pattern #17 and instructs converting them to sentence case. It doesn't claim title case alone proves AI authorship; it presents it as a pattern worth rewriting, same as its other entries, but treats sentence case as the corrective action regardless. Sentence case is a legitimate editorial default. So is title case. The DropTimes uses Bluebook-style title case for its main headlines; plenty of well-edited, entirely human-written publications do the same. A model may overproduce title case because it absorbed the habit from documentation and marketing pages, which makes title case a plausible contextual clue in some settings. It doesn't make title case a defect in every setting. Overriding an organisation's approved headline style in the name of "humanising" a text is just one style guide overwriting another, dressed up as detection. The skill's own false-positive guidance is more careful than its rewrite command: it recognises that no single trait is conclusive on its own and that patterns matter more in clusters. That restraint doesn't carry through to the rewrite instructions, which still prescribe a categorical correction regardless of context.

The same tension shows up again with quotation marks. Pattern 19 converts curly quotation marks to straight ones. But the skill's own false-positive guidance, a few sections later, concedes that "macOS, Word, Google Docs, and most CMSes auto-curl by default" and that curly quotes "only count when stacked with other tells." The rewrite instruction doesn't carry that caveat with it; it still converts every curly quote in the final draft, on a platform where that punctuation is frequently just the operating system's default typography, not a tell at all.

The hyphenation rule doesn't survive contact with the rest of the document

Pattern 26 targets what it calls hyphenated word-pair overuse: "third-party," "cross-functional," "high-quality," and similar compounds. Its instruction is precise: keep the hyphen when the compound sits before the noun it modifies (a high-quality report), drop it when the compound follows the noun instead (the report is high quality).

That's a real, defensible editorial distinction, and it's one I use too. My own guidelines for The DropTimes hyphenate compound modifiers the same way: decision-making process, long-term plan, open-source community.

The document doesn't apply its own rule consistently to itself. In its detection-guidance section, it writes that certain transition words "are AI-coded only when piled up": a hyphenated compound sitting in exactly the predicate position (after "are") that pattern 26 says should drop the hyphen. A few sections later, describing when a changelog-style document is exempt from another rule, it writes that the document "is inherently version-scoped": again predicate position, again hyphenated, again the construction the skill tells editors to unhyphenate elsewhere in the same file. By its own stated rule, a rewrite pass should turn these into "AI coded" and "version scoped." It doesn't, because a person wrote this document the way people actually write: applying the convention where it feels right, not running every sentence through the rule mechanically. Which is rather the whole argument this piece is making.

Many "AI patterns" are ordinary bad writing

The skill is at its strongest where it stays descriptive: promotional adjectives, ungrounded "experts say" claims, hollow "challenges and future outlook" sections, generic upbeat closers. These show up constantly in corporate copy, inexperienced journalism, grant applications, and plenty of human-written marketing, with or without a model involved. The goal of editing this out shouldn't be to defeat an AI detector. It should be to make the writing say something. A sentence that makes a grand claim without supplying information is weak whether a model wrote it, an executive dictated it, or an intern typed it at 1 a.m.

What a genre-aware version would look like

The skill already partly acknowledges this: its voice-calibration option asks for a writing sample and says to match punctuation habits, sentence rhythm, and recurring phrases against it, and Section 14 does let a sample's em dash usage override the ban on that mark specifically. That's the right instinct, applied unevenly. It doesn't extend to en dashes, and it doesn't apply at all when no sample is supplied, which is the default, most common way the skill gets used.

A more defensible version would separate its guidance by mode and be explicit about which kind of rule each pattern actually is:

• a pattern that is frequently AI-associated and worth flagging as a possible tell
• a general editorial weakness independent of authorship
• a house-style preference that one publication or author has chosen, and which another may reasonably reject

Title case, en dashes, semicolon frequency, and predicate-position hyphenation belong in the third category. Fabricated attribution and empty promotional padding belong in the first two. Treating all of them as equivalent evidence of "not sounding human" is the actual design flaw here.

A writing sample is the right calibration tool when the goal is preserving one author's voice. It's the wrong one for anonymous or institutional copy, where a project style guide does the same job more reliably. Either way, the skill needs to be told what authority governs the text before it starts rewriting punctuation and heading case—not left to fall back on its own defaults by default.

Human writing is not a style preset

The skill's underlying editorial advice is mostly sound. Its mistake is narrower than that: it sometimes confuses uniformity with humanity. Prose doesn't read as human because it avoids a Unicode character or a capitalisation pattern. It reads as human because of intention, context, and the writer's own defensible choices about rhythm and emphasis.

A newsroom is entitled to enforce a strict style so that many writers read as one publication (I've written and enforced exactly that kind of rulebook myself). But a style guide should say plainly that it's a style guide. It shouldn't present one publication's preferences as a universal test for whether a sentence was written by a person.

So, is it worth adopting?

For the question that started this: partially, and not as a drop-in default. The content-level patterns (vague attribution, hollow "challenges ahead" sections, promotional padding, generic upbeat closers) are worth running any AI-assisted draft through, regardless of which project it's for. Those catches are sound and will save real editing time.

The style-level rules are where it needs a human decision before switching it on for any given site. For a named author's voice, don't run it without supplying a representative writing sample. For anonymous or institutional copy, give it a project style guide instead (same purpose, different tool). Either way, check its heading-case and dash conventions against whatever house style that particular project already follows, rather than letting the skill's defaults quietly overwrite an existing one. Treat it as a first-pass filter that still needs an editor's sign-off, not a settings toggle you turn on once per client.