Humanize Pro

Humanize Pro

Two jobs, in this order: remove the statistical residue of a language model, then make the text fit the channel it ships in. Most humanizer skills only do the first, which produces clean prose that still lands wrong because a LinkedIn post is not a memo and a Slack reply is not an essay.

A third job sits underneath both: sound like this writer, not like a generically de-slopped one. That is what the voice profile is for.

When to trigger

Use this skill when:

• The user asks to humanize, unslop, de-slop, de-AI, clean up, or tighten text, or to make it sound human or natural.
• The user says something reads like AI or like ChatGPT.
• The user asks whether text matches their voice, style guide, or voice profile, or wants a profile built or updated.
• You are drafting or rewriting outbound human communication, even if nobody said "humanize": LinkedIn posts and comments, X posts and replies, cold or warm email, internal email, exec memo, Slack, blog, landing page, help content, press or public statements.
• Prose is going inside a deliverable: a document, deck, artifact, or generated file. The rules apply to the payload, not only the chat reply.

Do not trigger for:

• Code, commit messages, PR descriptions, or changelogs.
• Legal or regulated text.
• SEO structural elements (title tags, meta descriptions, keywords), unless the user explicitly asks to humanize those.

Modes

Pick one. If unclear, ask in a single line.

• Rewrite (default): user pastes text, you return the fixed version.
• Draft: user gives raw notes or a brief, you write it clean the first time.
• Audit: user wants the tells named, not fixed. Return a numbered list of what would flag, with the line quoted and a one-line fix each. No rewrite.
• Profile: user wants their voice profile built or updated from samples and past corrections. See "Voice profile" below.

Precedence

Requirements outrank style. In order:

1. The no-fabrication rule.
2. Named external requirements: legal and regulated language, brand guidelines, SEO structure (title tags, meta descriptions, keyword placement, internal links).
3. The user's standing constraints (see below).
4. The user's voice profile or writing sample.
5. Every style rule in this skill.

When a rule collides with something above it, keep the higher item and flag the conflict in one line after the text. Never resolve it silently.

Standing constraints

A standing constraint is a rule the user has stated once and expects to hold forever, in every output, without being restated. Typical examples: a banned punctuation mark, a banned word, a forbidden greeting, a required sign-off, a length ceiling.

Three things make constraints different from style preferences:

• They are absolute, not weighted. A single violation is a failure even if the rest is excellent.
• They apply to every surface. Chat prose, generated documents, artifacts, file contents, headings, image captions, table cells, code comments in user-facing snippets. A constraint violated inside a deliverable is the most common failure mode, because the model applies the rule to its reply and forgets the payload.
• They survive tool boundaries. Text written to a file, passed to another skill, or produced inside an artifact is still the user's text.

Record standing constraints at the top of the voice profile. Before delivering anything, run the constraint list as a literal scan of the output, including every file you wrote this turn. Do not rely on having intended to comply.

Voice profile

The voice profile is a versioned file describing how one specific person writes. It is not part of this skill; it belongs to the user. Look for it in this order:

1. A path the user names.
2. A personal brand or voice skill already loaded in the session.
3. references/voice-profile.md inside a private fork of this skill.
4. Persistent memory, if the surface has it.

If none exists and the user wants one, offer to build it. Do not build it silently.

Format

# Voice profile: <name>
Version <n>, updated <date>

## Standing constraints        (absolute, never violated)
## Register                    (who they sound like, to whom)
## Sentence and paragraph shape
## Vocabulary: use / avoid
## Structural habits           (openers, closers, lists vs prose)
## Channel deltas              (how the voice shifts by surface)
## Open questions              (unresolved, needs more evidence)
## Changelog                   (what changed, what triggered it)

Every line carries a confidence marker:

• stated: the user said it directly. Treat as binding.
• observed: inferred from three or more independent samples of their own writing. Strong default, overridable.
• provisional: inferred from one or two samples, or from a single edit. Apply, but flag when it drives a visible choice.

Never promote a provisional line to stated. Only the user promotes.

Building one

Sources, in descending value: text the user wrote themselves; text the user edited and shipped; text the user approved unchanged; text the user rejected, with the reason. Chat messages count, and are often the most honest sample, because nobody performs in a chat message.

Aim for one page. A voice profile that runs long stops being read.

Capture corrections

The profile is worth having only if it stays current, and the raw material arrives constantly: every edit the user makes to your draft is a labeled training example.

When the user returns an edited version, rejects a draft, or says a line is wrong:

1. Diff intent, not tokens. Ask what class of change it is: a constraint violation, a register mismatch, a structural habit, a vocabulary preference, or a one-off factual fix. One-off fixes do not belong in the profile.
2. Write the rule in their words where possible. "Cut the setup sentence, start on the claim" beats "reduce preamble."
3. Check for contradiction. If the new correction contradicts an existing line, do not overwrite. Surface both and ask which holds. Contradictions are usually context-dependent rules that need a channel delta, not a replacement.
4. Log it. Add a changelog entry with the date and the triggering example. The changelog is what lets the user audit whether the profile is drifting.
5. Update in the same turn. A correction noted but not written is lost.

Two failure modes to watch. Over-fitting: one heavy edit becomes a permanent rule and the voice narrows. Require three instances before a provisional line becomes observed. Sycophantic drift: the profile fills with rules that make outputs more agreeable rather than more accurate. If a proposed line would suppress disagreement, a caveat, or an unwelcome finding, it is not a voice rule. Leave it out.

Workflow

1. Establish channel and audience

Before writing anything, fix these three:

• Channel: LinkedIn post, LinkedIn comment or reply, X post, X reply, cold email, internal email, exec memo, Slack, blog, landing page, product docs, press or analyst, board. A comment is its own channel, not a short post: it answers a person.
• Direction: internal or external. This governs candor, hedging, jargon tolerance, and how much context you restate.
• Relationship: cold, warm, peer, report, manager, exec, customer, public.

Infer from the text when it is obvious. Ask one short question when it is not. Do not ask three. If no answer is possible (non-interactive run, pipeline, subagent), assume rewrite mode and external direction, and flag the assumption in one line after the text.

Then load the matching section of references/channels.md. Load only what applies.

2. Calibrate voice

Load the voice profile if one exists. Otherwise, if the user has supplied a writing sample, a brand or voice skill, or prior approved work, read it and match sentence rhythm, vocabulary, and quirks. A voice profile or sample outranks every style rule in this skill except the no-fabrication rule, the em dash ban, and the user's standing constraints. If it uses one-line paragraphs, keep them. If it uses em dashes, the ban still holds: only an explicit user instruction restores them, never an inference from samples.

With no sample, aim for competent-professional-with-a-pulse: plain words, varied sentence length, an opinion where an opinion belongs.

3. Universal pass

The checklist below covers most short texts. For long-form work (blog, memo, landing page), or when the audit pass flags something you cannot name, read references/ai-tells.md in full.

Every tell below is a rhetorical move, listed by its most common wording so it can be scanned for. Rewording the move is not a fix. "It's not X, it's Y" spread across two sentences is still the contrast move; a five-word closing sentence is still the kicker. When you catch a string, ask what the sentence is doing, and remove the move.

In priority order:

1. Cut the opener. Delete throat-clearing, context-setting first sentences, and any signposting ("Let's dive in", "Here's the thing", "In today's landscape"). Start with the claim.
2. Cut the closer. Delete summary paragraphs that restate what was just said, "The future looks bright" style endings, "I hope this helps", and offers to continue.
3. Break the shape. AI text has uniform paragraph length, uniform bullet length, and triads everywhere. Vary paragraph length deliberately. If you wrote three items, check whether there are actually two or four.
4. Kill the vocabulary. No delve, leverage, landscape, tapestry, testament, pivotal, seamless, robust, journey, unlock, elevate, navigate, realm, crucial, vital, comprehensive, holistic. See the full list in references. The list is a frequency heuristic, not a blocklist: a listed word stays when it is the plain, precise choice and no simpler word does the same job.
5. Kill the constructions. No "It's not just X, it's Y." No "This isn't about A. It's about B." No copula avoidance (serves as, stands as, boasts, features). No superficial -ing analysis (highlighting, underscoring, reflecting, showcasing).
6. Kill redundant negation. A clause asserted, then restated as its own negative: "to fit in and not feel excluded", "fast setup, no configuration needed". Delete the negative half. One exception: when the alternative being ruled out is genuinely what the reader would otherwise assume ("due to layoffs, not performance" on a resume gap), the clause carries information and stays. Apply the deletion test in references/ai-tells.md. Do not strip these mechanically.
7. Kill the punctuation tells. No em dashes. Hard rule, every use: not as a clause separator, not as a parenthetical pair, not before an attribution. Use periods, commas, colons, parentheses. A voice sample does not override this; only an explicit user instruction does. En dashes in numeric ranges (pages 3–5, 2019–2024) are a different character, correct typography, and stay unless a standing constraint says otherwise. No curly quotes outside typeset surfaces. No ellipsis for drama.
8. Kill formatting slop. No bold on random nouns. No "Label: sentence" bullets when prose works. No title case headings. No emoji unless the channel norm says otherwise. No markdown in a channel that does not render it.
9. Fix bullets that are sentences. A bullet past roughly fifteen words, or carrying a subordinate clause, is prose in disguise. If the bullets only make sense read in order, they are an argument: convert to paragraphs. Otherwise compress to parallel fragments.
10. Cut announced honesty. No "the honest answer", "real talk", "I'll be blunt", "not the polite version". Honest writing does not flag itself, and the frame implies everything around it was less honest. Deliver the content instead.
11. Make titles name their payload. No "The X, and the Y sitting inside it". No concealment metaphors (lurking beneath, hiding in plain sight, what nobody tells you). No "Topic: a deeper look". State the claim. Sentence case.
12. Cut hedge stacks. "may potentially help" becomes "may help". Keep a hedge only when the claim actually is uncertain.
13. Name the source or cut the claim. No "experts say", "studies show", "many companies find".
14. Kill the moves that survive string bans. Contrast-then-mirror in any grammar: "never gets settled by a RACI. It gets settled the first time...". Crux nomination: crowning one item as "the one that decides", "the hard case", "where half the value is", usually followed by dismissing the rest. The kicker in any form: if the last sentence is the shortest and the most quotable, it is a kicker, fragment or not. Gnomic generalization: a category subject in the present tense with never or always ("The tool never decides which", "These fights never get settled"). One gnomic sentence per short text at most, and it is the first sentence to cut.
15. Cut candor adverbs. "actually", "really", "genuinely", "truly", "finally" when nothing in the text contradicts them. Delete the word; if the sentence means the same, it was a candor flag, the residue of announced honesty after the frame was removed.
16. Restore normal word order. No fronted objects for punch ("Technical, creative, and broad you can screen for in an afternoon", "That last one I've never seen"). No dropped subjects and articles to sound clipped ("Most useful artifact a PMM owns, and..."). Performed terseness reads as performance.

4. Add texture

Removing tells produces text that is clean and dead. A human wrote this, so something in it should only be true for that human.

• Concrete specifics where the source has them: a number, a name, a date, a place, a version, a cost. A full paragraph with none is a flag to check the source again, not a quota to fill.
• An opinion where an opinion is appropriate, including the unflattering one.
• Admitted uncertainty when uncertainty is real ("I don't know why this worked" beats a manufactured explanation).
• Varied sentence length. Vary it where the argument varies, not as a formula: the long-sentence-then-short-one pattern applied everywhere is itself becoming a recognizable humanizer tell.

When the source has no specific, go smaller, not bigger. The failure mode is compensating for a missing number or story with a universal claim or a typical scene: "the first time a launch goes badly and somebody finally says out loud who makes the call". A vivid hypothetical with "somebody" as its protagonist is a fabricated anecdote with the names removed, and it reads as one. Number-shaped idioms ("year two", "half the value", "in an afternoon") are the same dodge. With no specific to hand: refer to the input, ask a real question, or say less. If the writer has a real instance, put it in the past tense and first person; a generalization owned as "I watched X happen at Y" is texture, the same claim in the gnomic present is a fortune cookie.

No-fabrication rule, absolute: specificity comes from the source text or the user, never from you. If a rewrite needs a number, a name, a date, or an anecdote that is not in the input, stop and ask for it or leave the sentence general. Never invent a statistic, a quote, a customer, or a personal experience. This rule outranks every instruction above.

5. Channel fit pass

Now apply the channel section from references/channels.md. This is where length, structure, opening convention, formatting, and sign-off get set. Text that survives step 3 and fails step 5 still reads wrong.

6. Audit pass

Two gates, in order. The first is mechanical and has no judgment in it.

Gate A, literal scan. Scan the actual characters of every output produced this turn, files included:

• Each standing constraint from the voice profile.
• Any em dash character, in any use. (En dashes in numeric ranges pass.)
• Banned vocabulary from step 3, and the candor adverbs from step 3 item 15.
• The constructions from step 5, and redundant negation from step 6.
• Bullets over roughly fifteen words. Announced honesty. Titles that promise instead of name.
• Triads: three bullets, three clauses, three examples in a row.

Failing Gate A is not a matter of degree. Fix and rescan.

Gate B, read it cold. Answer: would a reader assume a model wrote this? Check for uniform rhythm, a tidy summary you re-added, bullets where prose belongs, paragraphs of equal length, a resurfaced banned word.

Those checks only fire on paragraphs. For anything under about 80 words (a comment, a reply, a Slack line, a short email), run these instead:

• Quote-card test. Is the last sentence the shortest and the most quotable? Then it is a kicker. End on the content instead.
• Standalone test. For a comment or reply: could it be posted on its own with nothing lost? Then it is a post, not a reply. It should need the thread to make sense.
• Thesis count. How many sentences are general claims with a category subject? More than one means the text is dispensing wisdom, not talking. Convert one to an owned instance, a reference to the input, or a question, and cut the rest.
• Move scan. Crux nomination in the first sentence, contrast-then-mirror anywhere, a credential pivot into a generalization, a closing menu question.

If yes on any, rewrite once. First drafts of a humanized rewrite reliably keep tells the second pass catches. Both gates happen silently: catch a tell, fix it, show only the fixed text. No trace of the correction appears in the deliverable.

7. Deliver

Return the text and nothing else, unless the user asked for reasoning. No preamble about what you changed, no narration of the audit pass or mid-draft corrections. If you had to leave a gap because of the no-fabrication rule, flag it in one line after the text.

If this turn produced a correction worth keeping, update the voice profile now. Say what you added in one line. Do not narrate anything else.

Do not humanize

Leave alone: direct quotes, legal and compliance language, regulated claims, security disclosures, contract terms, safety instructions, and anything where a stripped qualifier changes accuracy. In regulated or external formal contexts, a hedge is often the substance and not a tell. When a caveat carries legal weight, keep it and say so.

Do not apply personality guidance to text where voice is not wanted: status reports, runbooks, API docs, incident timelines.

False positives

Some patterns are legitimate. Do not strip them mechanically:

• A rule of three that is the actual number of items.
• Parallel structure in a board deck or a spec, where convention demands it.
• The word "leverage" when it means financial leverage.
• Formal register in a legal letter or an analyst briefing.
• Repetition of a term for clarity. Synonym cycling is the tell, not repetition.

References

• references/ai-tells.md: full banned vocabulary, phrases, openers, structural patterns, punctuation and formatting tells, with before and after examples. Read for long-form work or when the audit pass flags a tell you cannot name; the step 3 checklist covers most short texts.
• references/channels.md: per-channel specs for length, structure, opening, formatting, sign-off, and the tells unique to that channel. Read only the sections that apply.
• references/voice-profile-template.md: blank template for building a personal voice profile, plus the maintenance protocol.

Pattern taxonomy draws on Wikipedia's "Signs of AI writing" (WikiProject AI Cleanup) and the open-source humanizer skill lineage that built on it.