Unslop: remove AI writing patterns from text

Use this when

You need to edit prose such as documentation, README text, release notes, pull request descriptions, or user-facing copy so that it stops reading as machine-generated. The meaning, facts, and intended tone must stay the same.

Do not use this runbook to add content, change claims, or shift the tone away from what the author intended. If a sentence’s meaning is unclear, ask the author before rewriting it.

Steps

1. Read the whole text before editing. Note the intended audience and tone, and keep both.
2. Scan the text against the patterns below. Flag each match, then decide on a fix.
3. Rewrite each flagged passage. Delete a sentence when it adds nothing. Replace a vague claim with a named source or a specific, checkable fact. If neither is available, delete the claim.
4. Keep facts, numbers, names, identifiers, and code unchanged. If a rewrite would require a new fact, stop and report the gap instead.
5. Read the revised text again for the patterns. Confirm that every remaining sentence still says what the original said.
6. Report any edit that changes meaning, and list any claims you removed because they could not be supported.

Patterns to detect and fix

Content

• Superficial -ing phrases. Phrases such as “highlighting…”, “ensuring…”, “reflecting…”, “showcasing…”, and “fostering…” tacked onto a sentence. Delete them, or expand them with a real, sourced detail.
• Vague attributions. Phrases such as “experts believe”, “industry reports suggest”, and “some critics argue”. Name the source or delete the claim.

Vocabulary

• AI vocabulary. Words such as additionally, crucial, delve, enduring, enhance, fostering, garner, interplay, intricate, landscape (in the abstract sense), pivotal, showcase, tapestry (in the abstract sense), testament, underscore, and vibrant. Replace them with plain words.
• Inflated verbs for “is”. “Serves as”, “stands as”, “boasts”, and “features”. Write “is” or “has”.
• “Not just X, but Y.” State the point directly.
• Forced groups of three. Use the number of items that actually exist.
• Synonym cycling. Do not rotate between “protagonist”, “main character”, and “hero” for one thing. Pick one term and repeat it.
• False ranges. “From X to Y” when X and Y are not points on one scale. List the items directly.

Style

• Em dashes. Remove them. Use periods or commas. Do not substitute parentheses, en dashes, or hyphens.
• Colons as connectors. Keep colons before a list or an example. Do not use them mid-sentence to set up a comparison. Rewrite the sentence so the point stands on its own.
• Bold overuse. Do not bold every proper noun or acronym.
• Inline-header lists. A bold label followed by a colon that restates the line, such as “Performance: Performance improved…”. Convert it to prose. A bold lead-in that ends in a period and introduces new detail is fine.
• Title case headings. Use sentence case.
• Decorative emoji. Remove them from headings and bullets.
• Curly quotes. Use straight quotes.

Communication artifacts

• Chatbot phrases. Phrases such as “I hope this helps!”, “Let me know if…”, “Of course!”, and “Certainly!”. Remove them.
• Sycophancy. Phrases such as “Great question!” or “You’re absolutely right!”. Respond to the substance directly.

Filler

• Wordy phrases. “In order to” becomes “to”. “Due to the fact that” becomes “because”. Delete “it is important to note that”.
• Stacked hedges. “Could potentially possibly be argued that it might” becomes “may”.
• Generic conclusions. “The future looks bright.” Replace it with a specific plan or fact, or cut it.

Jargon

• Abstract metaphor nouns. Words such as substrate, wedge, vector (meaning “way”), locus, vantage, nexus, bedrock, scaffolding (as a metaphor), modality, paradigm, gold-plating (more than the task needs), north star, flywheel, and endgame (meaning the last phase). Use the concrete word, such as “base”, “add”, “method”, or “last phase”.
• Other jargon metaphors. “Harness” as a metaphor, “API surface”, “ratchet” as a metaphor (use the mechanism’s real name, or describe the limit that only tightens), and “evacuate” for moving code (use “move out”).

Plain speech

• Feelings instead of facts. Sentences such as “the database stays close at hand” or “SQL you can read” name a feeling. Replace the sentence with the mechanism or a number. For example, “.toSQL() returns the exact string sent to the database.” If you cannot restate the sentence as a concrete instruction, fact, or number, cut it. A sentence that could appear unchanged in another project’s docs says nothing about this one.
• Dense sentences. If a reader has to backtrack to parse a sentence, split it or drop clauses. Keep one idea per sentence.
• Passive voice. Name the actor when it is known. For example, “the compiler validates queries” is better than “queries are validated”. Passive voice is fine when the actor is unknown or does not matter.
• Adverbs propping up weak verbs. Replace “runs quickly” with “is fast” or the measured number. Replace “significantly improves” with the measured change.
• Fancy words. “Utilize” and “leverage” become “use”. “Facilitate” becomes “help”. “Numerous” becomes “many”. “In the event that” becomes “if”.
• Mannered prose. Metaphors, rhetorical fragments, personified code, figurative verbs, and stock framing phrases where a literal phrase exists. Say what you mean.
• Over-compression. Dropped articles, verbless fragments, arrows, and abbreviations that make the reader decode the text. Write whole sentences and spell out abbreviations. For example, “Parser rejects bad date → exit 2, no write” becomes “The parser rejects a bad date, exits with code 2, and writes nothing.”

Done when

• Every pattern above was checked against the full text.
• Each flagged sentence was rewritten or cut, and no vague claim remains without a named source.
• Facts, numbers, names, and code match the original, and any meaning change is reported.
• The final text has no em dashes, curly quotes, title-case headings, or decorative emoji.
• The intended audience and tone are still clear.