STE80 Humanizer: Two Passes for Clearer AI-Written Text

STE80 Humanizer is worth testing when AI-written text needs to be easier to read without changing its facts—but its small evaluation is not enough to justify treating it as a production-ready default. The useful detail is its two-pass design: remove familiar AI-writing patterns, then reshape the text with controlled-English rules.

What the STE80 Humanizer’s Two Passes Change

The first pass targets 26 AI-writing tells. The second applies 15 STE80 structure rules, based on ASD-STE100’s controlled-English approach but softened for this use. The stated limits are 20 words per instruction and 25 per description; the source also reports about 900 approved words.

That makes this more than a prompt that says “sound human.” It gives an agent a defined editing procedure and a constrained vocabulary and structure to work with. The skill can be installed for several coding agents or uploaded to Claude.ai and Claude Desktop, so there are multiple ways to try it in an existing workflow.

My read: the two-pass split is the part worth examining in a real integration. Removing recognizable patterns and improving sentence structure are different editing jobs. Keeping them separate may make it easier to inspect what the skill changes, though the source does not establish that the passes always behave independently or predictably.

Fidelity Matters More Than Detector Scores

The stated priority is fidelity: preserve source facts and flag contradictions rather than inventing information. The article is explicit that getting past AI detectors is not the goal. That is a sensible boundary for a writing tool; detector evasion would be a poor proxy for whether a rewrite is accurate or useful to a reader.

For implementation, the practical question is whether “preserve” holds when the input is messy: ambiguous wording, conflicting claims, or details that depend on context. The source describes how the skill intends to handle contradictions, but it does not provide enough evidence here to know how reliably it catches them. I would still keep the original text available and review edits that affect claims, instructions, or technical terminology.

Four Cases Are a Starting Point, Not a Benchmark

The source reports four small evaluation cases and cautions that the results are a hint, not proof. That is enough to motivate a hands-on trial, not enough to infer consistent gains across different writing tasks or longer documents. The release details also do not establish how the skill behaves at scale, or how much review its output needs.

I would test it against a small set of representative text from the workflow where it might be used, then compare readability and factual fidelity—not just whether the output sounds less machine-like. Track changes that introduce meaning shifts, flatten necessary technical language, or fail to flag contradictions. If those checks look good, the skill may be useful as a controlled editing step. If not, the two-pass structure still offers a concrete model to inspect, but not a reason to trust the output unattended.