Humanizer Skill 3.0: can a 2B local model rewrite docs?

Humanizer Skill 3.0 is a free, open-source prompt-based tool that rewrites machine-sounding prose while leaving code blocks, terminal commands and URLs untouched. You install the skill instructions into a coding agent, point that agent or a local Ollama model at a Markdown file, and get back plainer text. The rewriting itself is done by whichever language model you supply.

What Humanizer Skill 3.0 actually is

Humanizer Skill 3.0 is a free, open-source skill file that instructs an AI model to rewrite machine-sounding prose in a plainer voice while leaving code, commands and links alone. It ships no model of its own: the rewriting is performed by whichever assistant or local model you point at it.

A skill file is a Markdown document of instructions that a coding agent loads into its context. In this case the instructions describe tone targets, banned patterns and a rule that technical elements must be shielded before any rewriting occurs. That architecture is the whole product. Quality depends on the model reading the file.

The transcript presents the tool as its third major release, updated in mid-September 2026, with a reworked core engine that reads document structure before touching a word. Treat release numbering as a first-party statement in a video walkthrough, not a verified version tag. Check the Humanizer Skill repository for the current tag and changelog before relying on any version number.

How Humanizer Skill 3.0 shields your code blocks

Humanizer Skill 3.0 separates technical elements from ordinary paragraphs before rewriting begins. Code fences, inline code, terminal commands and URLs are isolated so that only plain prose reaches the rewriting step, which is why a rewritten README usually keeps its syntax intact.

The speaker describes this as a protective barrier where the actual logic is bypassed by the text parser. That is a design claim about ordering: protection happens first, rewriting second. It is not a parser guarantee from a formal specification, so test it on a file with unusual Markdown before trusting it on a release branch.

The four-step pipeline described in the video runs like this:

1. Load the source from a Markdown file or piped terminal text.
2. Split ordinary paragraphs from technical elements and lock the technical parts.
3. Rewrite only the prose, replacing common machine-writing habits with plain sentences.
4. Emit a polished Markdown file ready to publish.

The rewrite step works from the model's own instructions, so a small model can still miss a step. The protection claim rests on instruction-following, not on a deterministic compiler.

The 25 machine-writing patterns it targets

Humanizer Skill 3.0 targets a fixed list of 25 machine-writing habits and rewrites the phrases it recognizes. The list, as described in the walkthrough, covers openings, pacing, vocabulary, visuals and disclaimers rather than a general style pass.

The categories the video names are broad rather than precise. No published list of all 25 patterns appears in the transcript, so the groupings below are the speaker's description, not an official taxonomy.

• Openers and clichés. Phrases such as an invitation to dive in, and constructions built as a contrast between two things.
• Pacing. Walls of bullet points and even, mechanical sentence rhythm broken up into ordinary sentences with commas and full stops.
• Vocabulary. Stiff words replaced with everyday alternatives.
• Visual clutter. Emoji and similar decoration removed.
• Chatbot disclaimers. Boilerplate notices stripped from the output.

That last item deserves a caution. Removing a disclaimer from published text is an editorial decision, and in some contexts a disclaimer carries legal weight. Audit the output before publishing anything that came from a compliance or health-related source.

Installing it in a coding agent or with a local Ollama model

Humanizer Skill 3.0 can be installed in three ways: through an agent CLI command, by downloading the skill Markdown file directly, or by adding it as a plugin from a marketplace inside a compatible CLI. The video uses the manual file route to keep everything local.

For a fully local setup, the skill file is combined with a source document and a prompt, then sent to an Ollama endpoint running on the same machine. Ollama is a local model server that exposes an HTTP API. The Python script in the walkthrough reads the skill file, builds one combined prompt, posts it to the local endpoint and writes the response to an output path.

Route	How it works	Model used
Agent CLI command	Skill installed globally in the agent	Your agent's model
Skill Markdown file	Download and reuse in any local or cloud agent	Any model you configure
CLI marketplace plugin	Added as a plugin inside a compatible CLI	Your agent's model
Local Ollama script	Skill file sent to a local endpoint via API	Local open model such as Gemma or Llama

The speaker's own run used a 2B parameter model on 4 GB of VRAM and reported a 26-second generation time. That figure is one person's experience on one small task. It does not predict latency on a long README or on different hardware, and model families in this range change frequently.

Do the claimed benchmark numbers hold up

The readability and hallucination figures in the walkthrough are attributed to official benchmark numbers, but no benchmark document, test set or evaluation method is shown. Treat them as vendor-style claims until the project publishes a reproducible evaluation.

Specifically, the video reports a readability score of 84 for rewritten output against raw AI text, described as a 62% improvement, plus zero detected tells across 500 words where the raw text had 14, and a 0% hallucination rate. None of this comes with a sample size, a scoring tool, a model list or an independent reviewer. A readability enhancement of that size on a single document says little about how the skill behaves across genres.

These claims also belong to the skill project, not to any model vendor. If a benchmark report is eventually published, read which model produced the text, how the tells were counted and who ran the evaluation before repeating a percentage.

The honest summary is narrower: a rule-based instruction file can reliably remove specific named clichés, because it is told to. Whether that makes writing sound human, by some external measure, is a separate question.

Where a local AI rewrite helps and where it fails

A local AI rewrite helps most on internal documentation, draft notes and repetitive release text, where plain phrasing saves reader time and the source material is already accurate. It helps least where the source is subtle, legal or already well written.

Running the model locally keeps the drafting loop on your machine, with no per-token API bill and no document upload to a third party. That is a real practical benefit for internal notes. Local inference alone does not create compliance, tenant isolation or regulatory clearance; those controls belong to the surrounding system and the organization.

The bigger risk is silent damage on long documents. Small models drop sections, merge headings or invent a plausible sentence when context runs long. Hallucination in this workflow is a general property of the model, so a claim of zero invented details should be read as a design intention, with a diff review after every run.

A skill file's quality also depends on the model's ability to follow multi-step instructions. A 2B model can handle a short conversation task and still stumble on a 300-line technical document. Keep the input chunked and review the output against the source.

A responsible workflow with Dev doido

Dev doido is a community nickname attached to independent developer tooling coverage, and it belongs in this article only as a reminder that walkthrough videos are demonstrations, not audits. The same applies to Crazystack typescript, a TypeScript-focused starter kit from the Brazilian Crazystack project. Neither one validates a benchmark.

If you want to evaluate Humanizer Skill 3.0 for your own docs, treat it as an editorial pass rather than an automated publish step. The workflow below keeps the checkable parts checkable.

1. Keep the source file in version control and commit before any rewrite.
2. Run the skill on a short section first, not the whole repository.
3. Diff the output against the input and confirm every code fence and URL survived.
4. Read for factual drift, since a rewrite can alter a number without flagging it.
5. Run a second pass with your own writing samples if tone matching matters.
6. Publish only after a human reads the final text.

Crazystack is a real project and a useful example of a TypeScript starter, but it plays no role in how the humanizer works. Naming tools next to each other does not connect them.

FAQ

• Is Humanizer Skill 3.0 free to use? The transcript describes it as free and open source under an MIT-style licence, with no paywall for commercial pipelines. Check the repository licence file before redistributing the skill file inside a product.

• Does it need an API key? No, not for the local route. The skill file is plain instructions, and a local model served by Ollama needs no cloud key. Agent-installed routes do use whatever model your agent is configured with, which may be a paid Claude Code.

• Can it really avoid hallucinating? No tool in this class can promise that. The design aims to rewrite only what exists, but a language model can still drift on long inputs. Compare the output line by line with the source before publishing.

• Which model should I use locally? The demo used a 2B model on 4 GB of VRAM. Larger instruction-tuned models generally follow multi-step skill files better, if your hardware allows. Test one section and compare the diff before committing to a model.

• Will it keep my code and commands intact? The protection step is designed to lock code, commands and URLs before rewriting. Verify this yourself on a file with nested fences and unusual syntax, because instruction-following is not a formal parser guarantee.

• Does it bypass AI detectors? The project is described as a style rewriter, and the video makes no detector-bypass claim. Detector scores are unreliable in any case, and writing for a detector is a poor editorial goal.

• How was the 62% readability boost measured? The video gives no scoring tool, sample or method. Treat the figure as a project claim until a reproducible evaluation is published with the model, dataset and reviewer named.

• Can I use it on legal or medical text? The skill removes chatbot-style disclaimers, which is risky in regulated writing. Use it for drafting only, and keep required notices under human control.

• How does it compare with just prompting an assistant? A skill file standardises the instruction so every run follows the same rules. A plain prompt works too, but it drifts between sessions and carries no shared checklist.

• What about Skala blog? Skala blog is the publishing side of this workflow, where written drafts get reviewed before they go out. The rewrite is one stage; a person still decides what gets published.

Turning a spoken walkthrough into a written draft

A nine-minute video carries a working setup, three install routes, a demo run and a set of claims that need checking. The gap between that and a publishable article is the checking, not the transcription.

If you have built something on camera, or explained a tool in a long interview, the same content can become a structured draft with headings, a table and an FAQ, provided a reviewer adds the sources and corrections the recording did not. Skala Blog turns a YouTube link into a transcribed draft you can edit before it goes anywhere.

Source video