Humanizer
Skill bhushanasati25/humanizer
Strip AI writing tells out of prose so it reads like a person wrote it. Use this whenever writing or revising anything a human will read as the user's own words — emails, resumes, cover letters, blog posts, documentation, README files, LinkedIn posts, essays, PR descriptions, Slack messages, project write-ups. Also use when the user says text "sounds like AI," "sounds robotic," "sounds generic," asks to humanize or de-slop something, or asks for an edit pass on their draft. Apply it silently by default rather than announcing it. Do not apply to code, config files, or structured data.From its SKILL.md
npx -y skills add bhushanasati25/humanizerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 22 days oldThe repository was created 22 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
8.0 KB, ~1.7k tokens by cl100k_base, as published. Nobody here has run it
Humanizer
Two things make text read as machine-written. The surface layer is a set of recognizable verbal habits. The deeper layer is content that could have been written about anything. Fixing only the surface produces prose that dodges the checklist and still reads hollow, so work the layers in order: substance first, then surface.
Pass order
Run these in sequence. Do not skip to step 3.
1. Cut what isn't load-bearing. Delete every sentence that would still be true if the subject were something else. "This approach offers significant benefits for teams of all sizes" survives any substitution, so it dies. Aim to lose 20-30% of a first draft here. Most AI text is not badly written, it is over-written.
2. Replace vagueness with specifics. A number, a name, a date, a version, a real consequence. "Improved performance considerably" becomes "cut p99 latency from 800ms to 120ms." If the specific isn't known, say less rather than padding with an abstraction. Never invent a specific to fill the gap — a fabricated number is a worse failure than a vague sentence.
3. Fix the surface tells. The high-signal ones are below; the full catalog is in references/tells.md.
4. Vary the rhythm. Read the result and check sentence lengths. If they cluster around the same count, the prose has a metronome quality that reads as generated. Break it with a short sentence. Then let a longer one run.
5. Check the openings. If three consecutive paragraphs start with the same grammatical move (subject-verb, participle, "When you..."), rewrite one.
The tells worth memorizing
These come from Wikipedia's "Signs of AI writing" field guide, maintained by WikiProject AI Cleanup, plus its talk-page discussion of which signals still hold in 2026.
Negative parallelism. "It's not X, it's Y." "Not only X but also Y." The loudest tell currently in circulation. Also its newer triplet form: "No X. No Y. Just Z." State the positive claim and stop.
Rule of three. Three adjectives, three clauses, three examples, reflexively. The guide's insight is that LLMs reach for triplets to make thin analysis look comprehensive. Use two. Use four. Use one, if one is what's true.
Puffery. Pivotal, vital, crucial, groundbreaking, transformative, seamless, robust, rich, vibrant, comprehensive. Also the significance tails: "underscoring its importance," "highlighting the shift," "reflecting the continued relevance of," "serving as a testament to." These attach to the end of a sentence and add nothing. Cut them whole.
Weasel attribution. "Studies show," "experts say," "it has been described as," "some critics argue," "observers have noted." Name the source or drop the claim.
Editorial throat-clearing. "It's important to note that," "it's worth remembering that," "no discussion would be complete without." Delete the phrase and keep the sentence.
Filler transitions. Moreover, furthermore, additionally, in conclusion, in summary, overall. Real transitions carry logical weight; these are spacers.
Closing summaries. A final paragraph that restates the piece without adding anything. End on the last real point instead.
Copula inflation. "Serves as a," "stands as a," "marks a" where "is" would do.
False ranges. "Everything from strategic planning to implementation." "A range of meats from beef to chicken." Sounds specific, isn't.
Participle tails. Sentences ending in "-ing" clauses that restate the sentence: "...which reduced costs, highlighting the efficiency of the new system."
Formatting habits. Bulleted lists where each bullet leads with a bolded label followed by a sentence that just restates the label. Heavy bold in running prose. Title Case Headings. Emoji in headers. Curly quotes mixed with straight ones. Section scaffolding named "Challenges," "Key Takeaways," "Future Prospects."
Em dashes. Reduce but don't eliminate. The Wikipedia editors themselves now say this signal has decayed to near-uselessness, and hunting every one produces stilted commas. One or two in a long piece is fine.
Leftovers. "I hope this helps," "let me know if you need anything else," unfilled brackets, "As an AI language model."
Do not overcorrect
Humanizing has its own failure mode, and it is loud. The result reads as someone performing casualness.
Avoid: sentence fragments used for punch, three in a row. Opening with "Look," or "Here's the thing." Rhetorical questions inserted for texture. Forced contractions in a formal document. Deliberate typos. Slang that doesn't match the writer's register. Self-deprecating asides. Starting sentences with "And" or "But" more than occasionally.
A precise, formal, well-organized paragraph is not an AI tell. Plenty of humans write that way. The goal is prose that carries specific information in a consistent voice, not prose that sounds like it was written on a phone.
Match the register
The correct output depends on what the document is.
- Resume, cover letter, formal report: keep it tight and professional. Fix puffery and vagueness, leave the formality alone. Contractions usually stay out. This is the case where overcorrection does the most damage.
- Email, Slack, PR description: contractions in, shorter sentences, drop the scaffolding.
- Blog post, essay, personal writing: the most room for rhythm variation and voice. Opinions can be stated flatly without hedging.
- Technical documentation: specificity matters more than voice. Formulaic structure is a feature here, not a tell.
When editing text the user wrote, preserve their voice rather than substituting a generic "human" one. Their word choices, their sentence habits, their level of formality. Fix the tells, keep the person.
Before delivering
Reread the output once and ask three things. Would this sentence survive if the topic were swapped? Does any paragraph exist only to summarize another? Did the sentence lengths flatten out?
If the user asked for a revision, note briefly what changed and why. If they asked for original writing, just hand over the writing — no commentary about the technique, no meta-discussion of AI tells.
Scope
This is a style tool. It makes writing read better; it does not make claims true. When editing a resume, application, or anything else that will be verified, do not let tighter phrasing turn an unverifiable claim into a confident one. Flag those instead.
Optional mechanical check
If the text is in a file and a Python interpreter is available, scripts/tell_check.py catches the leftovers that survive a manual read:
python scripts/tell_check.py draft.md
It flags phrase-level tells with line numbers, plus three things that are hard to notice by eye: sentence-length variance, repeated paragraph openers, and em-dash density. Stdlib only, no install.
Treat the output as candidates. Every rule in it has legitimate uses, and obeying a regex without judgment produces worse writing than ignoring it. The linter cannot tell that a phrase is being quoted as an example rather than used, so it will flag this file and references/tells.md heavily. That is expected.
A clean run does not mean the writing is good. It means the surface is clean, which is step 3 of 5.
Full catalog
references/tells.md has the exhaustive list organized by category, with before-and-after rewrites and the overused-vocabulary inventory. Read it when doing a thorough edit pass, when the user asks for the complete list, or when a piece of text feels off and the specific pattern isn't obvious.
What ships with it: 8 files
34.7 KB alongside SKILL.md, 2 of them executable
references/
- tells.md8.4 KB
scripts/
- tell_check.pyruns11.5 KB
- test_tell_check.pyruns4.7 KB
- .gitignore46 B
- LICENSE1.0 KB
- .pre-commit-hooks.yaml201 B
- PROMPT.md1.9 KB
- README.md6.9 KB