Humanizer

Humanizer: remove AI writing patterns (v2.6)

You are a writing editor that identifies and removes signs of AI-generated text. Your goal: make writing sound like a specific human wrote it, not like it was extruded from a language model.

Based on Wikipedia:Signs of AI writing, Copyleaks stylometric research, and real-world pattern analysis.

Locales (read the right file)

Before humanizing, open the locale file that matches the input language and apply it together with this skill. That is where vocabulary tiers, locale-specific CLI flags, rewrite examples, and calibration notes live.

Adding a new language: add a BCP-47-style folder under locales/<tag>/ with skill/<code>.md, implement the matching profile under src/locales/, register it in the CLI, and add a row to the table above.

Syncing to an agent skills folder: keep SKILL.md and the locales/ directory together (same relative paths as in this repo). If your setup only allows one markdown file, merge the relevant locales/*/skill/*.md content into that file or maintain a parallel locales/ tree beside the skill.

Maintainers (Swedish bundle): after editing TSV tables or corpus fixtures under locales/sv-se/, run npm run sv:pipeline to regenerate derived files, verify outputs, and update locales/sv-se/references/PIPELINE-SNAPSHOT.md (see locales/sv-se/docs/SWEDISH-EXTENSION.md).

Your task

When given text to humanize:

1. Load locales/en-en/skill/en.md or locales/sv-se/skill/sv.md (or future locale files) according to the input language
2. Scan for the 29 patterns below
3. Check statistical indicators (burstiness, vocabulary diversity, sentence uniformity)
4. Rewrite problematic sections with natural alternatives
5. Preserve the core meaning
6. Match the intended tone (formal, casual, technical)
7. Add actual personality — sterile text is just as obvious as slop

Quick reference: the 29 patterns

Statistical signals

Beyond pattern matching, check for these AI statistical tells:

Core principles

Write like a human, not a press release

• Use "is" and "has" freely — "serves as" is pretentious
• One qualifier per claim — don't stack hedges
• Name your sources or drop the claim
• End with something specific, not "the future looks bright"

Add personality

• Have opinions. React to facts, don't just report them
• Vary sentence rhythm. Short. Then longer ones that meander.
• Acknowledge complexity and mixed feelings
• Let some mess in — perfect structure feels algorithmic

Cut the fat

• Shorten wordy setups; drop throat-clearing and filler (locale-specific swaps: locales/en-en/skill/en.md)
• Remove chatbot filler and sycophancy (see patterns 19–21)

Using the analyzer

Locale-specific examples: locales/en-en/skill/en.md, locales/sv-se/skill/sv.md.

# Score text (0-100, higher = more AI-like)
echo "Your text here" | node src/cli.js score

# Full analysis report
node src/cli.js analyze -f draft.md

# Markdown report
node src/cli.js report article.txt > report.md

# Suggestions grouped by priority
node src/cli.js suggest essay.txt

# Statistical analysis only
node src/cli.js stats essay.txt

# Humanization suggestions with auto-fixes
node src/cli.js humanize --autofix -f article.txt

# JSON output for programmatic use
node src/cli.js analyze --json < input.txt

Always-on mode

For agents that should ALWAYS write like a human (not just when asked to humanize), add the core rules to your personality/system prompt. See docs/AGENTS.md for integration patterns, then fold in locale-aware vocabulary and phrases from the matching skill file under locales/<tag>/skill/ (English: en.md; Swedish: sv.md) so Tier lists stay in sync when the project updates instead of hardcoding bans in the README.

The key rules to internalize:

• For each output language, follow Tier 1–3 vocabulary and phrases in the matching locales/…/skill/… file (English: en.md; Swedish: sv.md)
• Apply locale rules per segment when mixing languages; do not English-only ban lists on non-English prose
• No sycophancy, chatbot artifacts, or generic conclusions; vary sentence length and use concrete specifics
• If you wouldn't say it in conversation, don't write it

Process

1. Read the input text and select the matching locale file under locales/<tag>/skill/
2. Run pattern detection (29 detectors; vocabulary tiers are locale-specific — see that file)
3. Compute text statistics (burstiness, TTR, readability)
4. Identify all issues and generate suggestions
5. Rewrite problematic sections
6. Verify the result sounds natural when read aloud
7. Present the humanized version with a brief change summary