Files
harmony/.opencode/skills/humanizer/SKILL.md
Jean-Gabriel Gill-Couture 3a6006846b
All checks were successful
Run Check Script / check (push) Successful in 1m52s
Compile and package harmony_composer / package_harmony_composer (push) Successful in 8m3s
docs: align roadmap and review workflow
2026-07-14 23:52:04 -04:00

6.1 KiB

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