Technical Humanizer

Purpose

Rewrite technical drafts that sound machine-generated into writing that sounds like a competent person, while preserving every fact, number, and claim. The skill operates on prose, not on truth: it removes decoration, rhythm crutches, and fake energy, and it protects substance.

Scope statement, in plain words: this skill improves writing quality. It does not detect AI text, does not score "human probability", and does not claim to bypass AI detectors. Its goal is writing worth reading.

When to use this skill

• The user has a draft that "sounds AI-generated" or "too corporate"
• The user wrote with another tool and wants the output made natural
• The user's own writing has drifted into buzzword habits
• The user says "humanize this", "make this sound like me", "fix this draft", or similar

Required inputs

1. The draft text to rewrite

If the draft contains claims the skill suspects are invented (numbers, testimonials, traction), it flags them but does not fact-check them itself; it lists them as "verify before publishing".

Optional inputs

• The user's own writing sample, to match their voice (strongly recommended; the best humanizer target is the user's real voice)
• Platform (LinkedIn post, comment, About section, article)
• Which patterns bother the user most

Workflow

1. Read for meaning. Restate the draft's actual claims in one internal list: every fact, number, and commitment. This list is the protection contract; the rewrite may not shrink it.
2. Diagnose. Mark every occurrence of the patterns below.
3. Rewrite. Apply the transformation rules. Work paragraph by paragraph to avoid flattening structure.
4. Verify. Diff the claims list against the rewrite. Every claim survives, none added. Numbers unchanged. Hedged claims stay hedged; uncertain claims do not become confident ones.
5. Deliver the rewrite plus the diagnosis summary and the verification line.

Patterns to remove

1. Excessive em dashes. More than one per post is a pattern. Replace with commas, periods, or parentheses.
2. Fake vulnerability. Manufactured confession openers ("I'll be honest...", "This was harder than I expected...") that exist to sell the next sentence. Remove unless the admission carries information.
3. Fake excitement. "I'm thrilled", "I'm beyond excited", "I couldn't wait to share". Replace with the fact that justifies energy, if any exists.
4. Excessive rhetorical questions. More than one per post, or any question the author answers themselves two sentences later.
5. Repetitive three-item lists. The "X, Y, and Z" rhythm used three or more times in a post. Break the rhythm; keep lists that carry real items.
6. Corporate buzzwords. Leverage, utilize, synergy, streamline, supercharge, unlock, empower, best-in-class, world-class, cutting- edge, state-of-the-art, seamless, robust (as praise), ecosystem (as filler).
7. Unnecessary emojis. All emoji strings; any emoji carrying meaning the text does not. Keep zero by default.
8. Filler framings. "Here's the thing", "But here's the kicker", "Let that sink in", "In today's fast-paced world", "Let's dive in", "Buckle up".
9. The false contrast. "It's not just X, it's Y". Either state Y plainly or explain the actual relationship.
10. Meaningless motivational endings. "Keep building!", "The best is yet to come!", "Let's go!", "Your future self will thank you!". End with the last real sentence instead.
11. Vague intensifiers. "Incredibly", "massively", "insanely", "super" as modifiers of unmeasured claims. Either supply the measurement or drop the intensifier.
12. Symmetrical tricolon closers. The "not because of X, but because of Y" cadence when the sentence survives without it.

Transformation rules

• Delete decoration first, then restructure what remains. Most drafts are 20 percent shorter after deletion alone, with zero information loss.
• Replace adjective claims with the specific fact behind them when the user has supplied one; otherwise the claim is flagged for verification (see workflow step 1).
• Preserve the author's genuine idiosyncrasies. A real voice may keep a favorite word, a dry aside, an unusual structure. The target is natural, not sanitized.
• Keep hedging language that reflects real uncertainty. "In my test of 12 cases" is not a pattern to remove; it is a fact.
• If removal would delete information, keep the sentence and rephrase instead. Substance is never casualty.

Truth and credibility rules

• The rewrite must not change any claim's strength: hedges stay, uncertainties stay, numbers stay byte-identical.
• The rewrite must not add any claim, statistic, or example the draft did not contain.
• Suspected fabricated content is flagged in the delivery, listed under "verify before publishing", and left intact in the text. This skill does not interrogate the user, but it does not launder claims either.
• This skill makes no AI-detector claims, in either direction, in its output to the user.

Writing rules

• The output follows voice-guide.md by default; when the user supplies a writing sample, the sample wins on voice, and the guide keeps only the credibility rules.
• Preserve paragraph breaks roughly where the author put them; humanizer output should not look repaginated.
• Keep any code blocks, links, and formatting intact.

Output format

[Rewritten draft]

[What changed]
- <pattern name>: <count> instance(s), example: "<before>" -> "<after>"
- ...

[Verification]
Claims in: <N>, claims out: <N>, unchanged: yes/no
Numbers unchanged: yes/no
Verify before publishing: <list any flagged claims, or "none">

For short drafts, "What changed" may be three bullets. For long drafts, group by pattern.

Worked example

Input (the draft):

I'm thrilled to announce that I've been building something truly
game-changing over the past few months - a cutting-edge API monitoring
platform that's not just another monitoring tool, it's a complete
paradigm shift!

Here's the thing: in today's fast-paced world, downtime isn't just an
inconvenience, it's a catastrophe. That's why I leveraged modern
technologies to create a seamless, robust, world-class solution.

But here's the kicker - it catches incidents before they happen. Let
that sink in.

Keep building! 🚀🚀🚀

Output (the rewrite):

I've spent the past few months building an API monitoring tool.

The part I'm proud of: it watches response shape, not just status codes,
so it caught two incidents last week before users reported them. Both
were "200 OK" responses with empty bodies.

That's the whole pitch. Details and repo in the comments.

Delivery notes for this example: the rewrite deleted the hype patterns, kept the one real differentiator the draft gestured at, and flagged the "two incidents last week" claim for the user to confirm before publishing (the original draft did not evidence it).

Edge cases

• The draft is already clean. Say so and return it with at most two small suggestions. Do not invent changes to justify the pass.
• The user wants "undetectable" output. Restate the scope once: the skill improves writing, full stop. Then do the work.
• The draft is a resume or academic abstract. Those forms have their own conventions; apply only the pattern removals that fit, and say what was left alone.
• The draft's substance is thin. Fix the patterns and tell the user the deeper issue: no specifics to be specific with. Offer the relevant kit skill to rebuild it from real material.
• Mixed-author text (user wrote half, a tool wrote half). Rewrite the whole draft, but preserve the user-authored voice where it shows.

When NOT to use this skill

• The user needs a new post from scratch: use the appropriate creation skill first, then humanize if needed.
• The text is research communication with accuracy risks: run research-to-linkedin on it instead; humanizing claims you have not verified is worse than hype.
• The user asks to detect whether someone else's post is AI-written: out of scope, and unreliable in principle.

Shared references

• ../../references/voice-guide.md — the banned patterns list and the voice this skill writes into
• ../../references/credibility-rules.md — why claims must survive untouched

These paths assume the full repository is present. This skill works standalone: the rules above are the core, the references add depth.