How to Use Humanizer to Match a Specific Writer's Voice

To use Humanizer to match a specific writer's voice, provide a 2–3 paragraph writing sample from the target author before the text you want rewritten; the skill analyzes stylistic patterns and applies them while removing AI-generated artifacts.

Humanizer is a Markdown-only skill in the blader/humanizer repository that transforms AI-generated prose into human-sounding text. When you need the output to mirror a particular author's unique style rather than generic humanization, you leverage the voice-matching capability defined in the project's SKILL.md.

Using Humanizer to Match a Specific Writer's Voice

The voice matching system operates entirely within the skill's prompt metadata, requiring no additional configuration files or code changes.

The Voice Analysis Pipeline

According to SKILL.md (lines 30–36), Humanizer processes your request through a specific four-step pipeline when it detects a writing sample:

1. Read the sample first. The skill inspects sentence length, word choice, paragraph openings, punctuation habits, repeated phrases, and transition patterns.
2. Extract stylistic habits. It records rhythm (short versus long sentences), preferred vocabulary, dash usage (em-dash and en-dash frequency), and deliberate quirks like idiosyncratic capitalization.
3. Prioritize the sample over default rules. If your sample contains em dashes, Humanizer maintains them at roughly the same rate; otherwise, the generic dash-removal rule defined in SKILL.md §14 applies.
4. Apply the extracted style to the target text. The rewrite mirrors the sample's rhythm, word choice, and punctuation while still performing the 35 AI-pattern clean-ups.

Providing Writing Samples for Voice Matching

The key to successful voice matching lies in structuring your request so the sample precedes the target text.

Request Structure

According to the repository's README.md (section "Match your voice"), place your writing sample first, followed by the AI-generated content:

/humanizer

Here's a sample of my writing for voice matching:
I usually start my sentences with a punch, then let the story drift.  
When I’m excited, I throw in an exclamation—just enough to keep the reader on edge.

Now humanize this text:
The AI model often produces overly smooth prose that sounds like a generic blog post.

This command triggers the skill to analyze the first two lines for energetic pacing, informal tone, and em-dash usage, then rewrite the AI-generated paragraph using that extracted voice.

Alternative Invocation Style

You can also use plain language formatting:

Please humanize this text, using the following sample for voice matching:

[I love snapping pictures at sunrise—there’s something magical about the first light.]

[Paste AI-generated text here]

Both approaches invoke the same internal workflow documented in SKILL.md.

Technical Implementation Details

Because Humanizer operates as a plain-text skill, the voice analysis happens dynamically during each invocation through prompt logic rather than external configuration.

Key Source Files

• SKILL.md (lines 30–36): Contains the "Match the writer's voice" prompt instructions that trigger the four-step analysis pipeline.
• SKILL.md (section 14): Defines the dash-handling rules and the logic that prioritizes sample-specific punctuation over generic removal rules.
• README.md (section "Match your voice"): Provides user-facing usage examples for structuring voice-matching requests.

The skill compares detected patterns against the 35 standard AI-pattern clean-ups, ensuring the final output sounds like the specific writer while preserving every factual claim from the original text.

Summary

• Supply a writing sample first: Place 2–3 paragraphs of the target author's work before the text to be humanized to use Humanizer to match a specific writer's voice effectively.
• Structure matters: Always position the sample ahead of the AI-generated content for proper analysis.
• Style extraction is automatic: Humanizer detects rhythm, punctuation preferences, vocabulary choices, and sentence structure without manual configuration.
• Default rules yield to samples: Specific quirks found in your sample (like em-dash usage) override generic clean-up rules defined in the skill.
• No code required: Voice matching functions through prompt metadata in SKILL.md, not external configuration files or agent modifications.

Frequently Asked Questions

How long should the writing sample be?

Provide 2–3 paragraphs of the target author's work. This length provides sufficient data for Humanizer to detect sentence rhythm, punctuation patterns, and vocabulary preferences while keeping the request concise enough for the context window.

Does Humanizer require configuration files to match voices?

No. Voice matching operates entirely within the skill's prompt logic as defined in SKILL.md. You do not need to modify AGENTS.md or create separate configuration files; simply include the writing sample in your request metadata.

What stylistic elements does Humanizer extract from samples?

The skill analyzes sentence length variation, word choice patterns, paragraph opening styles, punctuation habits (including em-dash and en-dash frequency), repeated phrases, transition patterns, and deliberate quirks such as idiosyncratic capitalization, prioritizing these over default humanization rules.

Can I use multiple writing samples at once?

The repository documentation references analyzing "a writing sample" (singular) in the voice matching workflow defined in SKILL.md lines 30–36. For best results, provide a single cohesive sample that best represents the voice you want to match, rather than fragmented excerpts from different texts.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}