harmony/.opencode/skills/humanizer/SKILL.md

---
name: humanizer
description: Use when editing or reviewing prose to remove common AI-writing patterns while preserving facts, scope, technical meaning, and the author's voice.
license: MIT
compatibility: any-agent
metadata:
  source: https://github.com/blader/humanizer/blob/main/SKILL.md
  upstream-version: "2.8.2"
---

# Humanizer

Edit prose so it sounds like a person wrote it for a specific reader. Preserve
the information. Remove the statistical habits that make generated text broad,
inflated, repetitive, or oddly polished.

This project copy is adapted from Humanizer 2.8.2. The upstream skill is based
on Wikipedia's "Signs of AI writing" guide.

## Task

1. Read the whole text before changing it.
2. Identify patterns in clusters. One formal word or long sentence is not
   evidence by itself.
3. Rewrite rather than delete. Keep every fact, constraint, warning, and
   unresolved question.
4. Match the document's audience and existing voice. Technical reference text
   should remain plain and neutral.
5. Audit the rewrite by asking: "What still makes this sound generated?"
6. Revise once more and return or save the final text.

When editing files, save only the final version. Do not add a change summary to
the document unless that document is a changelog or review.

## Preserve

- code identifiers, commands, paths, versions, dates, measurements, and links;
- uncertainty where the source is uncertain;
- specific examples and operational detail;
- established project terminology;
- the author's actual opinion when the document is argumentative;
- quotations and titles, even when they contain a watched pattern.

Do not make prose friendlier by making it less precise.

## Patterns to remove

### Inflated importance

Cut claims that ordinary details are pivotal, profound, enduring, a testament,
or part of a broader shift. State what happened and why it matters here.

### Promotional language

Replace words such as vibrant, groundbreaking, seamless, powerful, robust, and
best-in-class with observed behavior. Keep an adjective only when the document
supports it.

### Fake analysis

Remove trailing phrases built around "highlighting," "ensuring," "showcasing,"
or "underscoring" when they merely restate the sentence. Use a direct sentence
for a real consequence.

### Vague authority

Do not write "experts say," "industry practice," or "users prefer" without a
source. Name the source, describe the observed evidence, or remove the claim.

### AI vocabulary clusters

Watch for repeated use of additionally, align, crucial, delve, enhance,
landscape, pivotal, showcase, and underscore. These words are not forbidden;
clusters usually signal that simpler language will be clearer.

### Avoiding simple verbs

Prefer "is," "has," and "uses" over "serves as," "stands as," "boasts," or
"represents" when the simpler verb says the same thing.

### Forced symmetry

Do not force ideas into groups of three, "not only...but also" constructions,
or repeated "not X, but Y" contrasts. Let the material determine the shape.

### Synonym cycling

Repeat the correct technical noun. Do not rotate through synonyms to avoid
using the same word twice.

### False ranges

Use "from X to Y" only when X and Y form a meaningful range. Otherwise list
the covered items directly.

### Filler and hedging

Shorten phrases such as "in order to," "at this point in time," "due to the
fact that," and "has the ability to." Keep one qualifier when uncertainty is
real; remove stacked qualifiers.

### Persuasive throat-clearing

Remove "the real question," "at its core," "what really matters," "let's dive
in," and "here's what you need to know." Start with the claim.

### Manufactured drama

Avoid runs of sentence fragments, aphorisms, and quotable punchlines. One short
sentence can help. Five in a row usually perform importance instead of
explaining it.

### Generic conclusions

Do not end with vague optimism, a summary that repeats the introduction, or an
offer to continue. End on the last concrete consequence or next action.

## Structure and formatting

- Use sentence-case headings.
- Avoid mechanical bold labels at the start of every bullet.
- Prefer paragraphs when a list does not improve scanning.
- Do not add emojis to make technical prose feel friendly.
- Use straight quotes in project files unless the surrounding file requires
  typographic quotes.
- Replace em and en dashes in revised prose with punctuation or a clearer
  sentence. Preserve them inside quotations and unchanged historical text.
- Avoid a heading followed by a sentence that merely repeats it.
- Do not write permanent documentation as a narration of the latest diff.

## Communication artifacts

Remove chatbot phrases such as "Of course," "Great question," "I hope this
helps," "let me know," and "would you like me to." They do not belong in the
document.

Do not invent personal details, motives, consensus, or likely history to fill a
gap. Say that a fact is unknown when that fact matters. Otherwise omit the gap.

## Voice

For technical documentation, plain and specific is a complete voice. Do not add
personality, jokes, or first person unless the surrounding document uses them.

For essays and opinion, preserve mixed feelings, concrete details, uneven
rhythm, and defensible first-person judgments. Do not polish away the human
parts of the source.

## False positives

Do not rewrite merely because text has:

- correct grammar;
- formal vocabulary;
- one em dash or transition word;
- one short emphatic sentence;
- a dry technical tone;
- clean formatting;
- an unsourced statement that is clearly presented as project policy.

Look for repeated patterns. Overediting specific prose into generic prose
defeats this skill.

## Final audit

Read the result aloud or at normal reading speed, then check:

- Does every sentence add information?
- Are claims supported by a source, code, or clearly stated project decision?
- Did the rewrite preserve warnings and uncertainty?
- Could a simpler verb or sentence carry the same meaning?
- Do lists reflect the material rather than a template?
- Does the ending stop when the work is done?
- Did any em or en dash enter revised prose?

If the text already reads naturally and precisely, leave it alone.