Skip to content
cccskills
FreePublished on GitHub

unslop

Edit text for people to remove common AI writing patterns while keeping its meaning and intended tone. The skill checks for vague claims, formulaic phrasing, filler, and stiff language, then revises the text with more specific wording and varied rhythm.

OriginalShow the original description

Cut AI tells from text you write or edit for a human reader (commit messages, PR titles and bodies, docs, code comments, replies). Apply before committing, posting, or sending; leave prose you didn't touch alone.

michaelshimeles/rstack1,392 stars(GitHub 1,392 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Polish a commit message before committing
  • Make a PR title and body sound natural
  • Revise docs or code comments for human readers
  • Edit a reply before sending

Files included (2)

  • SKILL.md6.6 KB
  • LICENSE1.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Unslop

Edit text to remove AI patterns and add human voice.

Process

  1. Scan for the patterns below.
  2. Rewrite. Preserve meaning, match intended tone.
  3. Add soul (see next section).
  4. Self-audit: "What makes this obviously AI generated?" Fix remaining tells.

Adding soul

Removing patterns is half the job. Sterile, voiceless writing is just as obvious.

  • Have opinions. React to facts instead of neutrally listing pros and cons.
  • Vary rhythm. Short sentences. Then longer ones that take their time. Mix it up.
  • Acknowledge complexity. "Impressive but also kind of unsettling" beats "impressive."
  • Use "I" when it fits. First person isn't unprofessional.
  • Let some mess in. Perfect structure looks machine-made.
  • Be specific. Not "this is concerning" but "there's something unsettling about agents churning away at 3am."

Patterns to detect and fix

Content

  1. Puffery. "pivotal moment", "testament to", "evolving landscape", "setting the stage for", "indelible mark", "deeply rooted". Cut puffery, state what happened.
  2. Name-dropping. Listing media outlets without context. Pick one, say what was said.
  3. Superficial -ing phrases. "highlighting...", "ensuring...", "reflecting...", "showcasing...", "fostering...". Delete or expand with real sources.
  4. Promotional language. "nestled", "vibrant", "breathtaking", "groundbreaking", "renowned", "stunning", "must-visit". Use neutral descriptions.
  5. Vague attributions. "Experts believe", "Industry reports suggest", "Some critics argue". Name the source or delete.
  6. Formulaic challenges. "Despite challenges... continues to thrive." Replace with specific facts.

Language

  1. AI vocabulary. Additionally, crucial, delve, enduring, enhance, fostering, garner, interplay, intricate, landscape (abstract), pivotal, showcase, tapestry (abstract), testament, underscore, vibrant. Replace with plain words.
  2. Fancy ways to say "is". "serves as", "stands as", "boasts", "features". Just say "is" or "has".
  3. "Not just X, but Y." State the point directly instead.
  4. Rule of three. Forcing ideas into groups of three. Use the natural number.
  5. Synonym cycling. Protagonist, main character, central figure, hero all in one paragraph. Pick one, repeat it.
  6. False ranges. "from X to Y" where X and Y aren't on a meaningful scale. List topics directly.

Style

  1. Em dash overuse. Avoid em dashes entirely. Use periods or commas only (no parentheses, no en dashes, no hyphen-as-dash substitutes). Em dashes are an AI tell, and reaching for parentheses instead just trades one tell for another. If a thought needs separation, end the sentence or use a comma.
  2. Colon overuse. Colons are fine before a list or example. Not as mid-sentence connectors. "If you're coming from traditional automation: instead of registering event handlers, you describe conditions" adds nothing with the colon. Rewrite to let the point stand on its own without comparison framing. "Describing when the scheduler should fire works best as plain English." Same meaning, no crutch punctuation.
  3. Boldface overuse. Don't bold every proper noun or acronym.
  4. Inline-header lists. The tell is a bold label and colon that restates the line: "Performance: Performance improved...". Convert those to prose. A bold lead-in that ends in a period, names the item, and is followed by genuinely new detail ("Schema in TypeScript. Tables live in one file.") is fine, not a tell.
  5. Title case headings. Use sentence case.
  6. Decorative emojis. Remove from headings and bullets.
  7. Curly quotes. Replace with straight quotes.

Communication artifacts

  1. Chatbot phrases. "I hope this helps!", "Let me know if...", "Of course!", "Certainly!", "Found the smoking gun!" Remove.
  2. Cutoff disclaimers. "While specific details are limited..." Find sources or remove.
  3. Sycophantic tone. "Great question! You're absolutely right!" Respond directly.

Filler

  1. Filler phrases. "In order to" becomes "To". "Due to the fact that" becomes "Because". "It is important to note that" gets deleted.
  2. Excessive hedging. "could potentially possibly be argued that it might" becomes "may".
  3. Generic conclusions. "The future looks bright." State specific plans or facts.

Jargon

  1. Abstract metaphor nouns. Substrate, wedge, vector, locus, vantage, nexus, primitive (as noun), harness (as metaphor), surface (as in "API surface"), bedrock, scaffolding (as metaphor), modality, paradigm, gold-plating, ratchet (as metaphor), evacuate (for moving code), endgame, north star, flywheel. These read as technical but usually have a plainer concrete word. "Substrate" becomes "base". "Wedge in" becomes "add". "Vector" becomes "way" or "method". "Gold-plating" becomes "more than the job needs". "Ratchet" becomes the mechanism's real name or "a limit that only tightens". "Evacuate" becomes "move out". "Endgame" becomes "the last phase". Pick the concrete word.

Plain speech

  1. Say what it does, not how it feels. "the database stays close at hand", "SQL you can read", "types that follow your schema" name a feeling. The fix names the mechanism or a number: ".toSQL() returns the exact string sent to the database", "a column rename fails the build". Ask what the sentence tells the reader to do or know, then write that. If you can't restate it as a concrete instruction, fact, or number, cut it. One more check: if the sentence could appear unchanged in another project's docs, it says nothing about this one. Cut it.
  2. Shorten or split dense sentences. If the reader has to backtrack to parse a sentence, break it in two or drop clauses. One idea per sentence.
  3. Active voice. Prefer it. Catch "is/are/was/were + past participle" and name the actor: "queries are validated" becomes "the compiler validates queries", "the file is parsed by the loader" becomes "the loader parses the file". Passive is fine only when the actor is unknown or genuinely doesn't matter.
  4. Cut adverbs, or use a stronger verb. "runs quickly" becomes "is fast" or the number. "significantly improves" becomes the measured delta. An adverb propping up a weak verb means the verb is wrong.
  5. Prefer the plain word. "utilize" becomes "use", "leverage" becomes "use", "facilitate" becomes "help", "numerous" becomes "many", "in the event that" becomes "if". The fancier synonym is rarely clearer.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

before-and-after

FreeSummary

Capture two web pages or image files for a visual comparison. Choose a page element with a CSS selector, set a mobile, tablet, or custom viewport, and create a Markdown comparison for PRs when needed.

  • Compare UI before and after a change
  • Capture a specific page element
  • Prepare screenshot evidence for a PR
michaelshimeles/rstack1.4KUpdated Oct 26, 2026

code-structure

FreeSummary

Use this guide to decide when repeated operational code should become a shared service, while keeping product rules in the workflow actions that own them. It provides practical design principles and a gradual migration checklist to preserve existing boundaries and behavior.

  • Deciding whether duplicated workflow code should be extracted
  • Separating business rules from reusable operations
  • Planning a gradual refactor across multiple callers
michaelshimeles/rstack1.4KUpdated Oct 26, 2026

Verify changed behavior with evidence suited to the task: a live screen recording for interactive UI flows, scripted captures for headless checks, or measured outputs for non-UI changes. Create a results report and send the evidence to the requested destination when authorized.

  • Capturing a live recording of a UI test
  • Checking a UI flow in a headless environment
  • Comparing measured API or performance results
michaelshimeles/rstack1.4KUpdated Oct 26, 2026

greploop

FreeSummary

Review Greptile feedback on a pull request, merge request, or shelved changelist, then make scoped fixes and request fresh reviews within a set cycle limit. Track actionable findings and report the current score, checks, and any work left unresolved.

  • Working through Greptile feedback on a pull request
  • Fixing actionable review findings on a merge request
  • Reviewing a Perforce changelist with Greptile
michaelshimeles/rstack1.4KUpdated Oct 26, 2026

greploop-apps

FreeSummary

Run the existing `greploop` workflow with the `@greptile-apps` trigger when the usual trigger cannot handle a large pull request. This entrypoint depends on the separate `greploop` skill and adds no workflow of its own.

  • Run greploop on a large PR
  • Use the Greptile Apps trigger
  • Continue an existing greploop review
michaelshimeles/rstack1.4KUpdated Oct 26, 2026

new-feature

FreeSummary

Prepare an isolated Git worktree and branch for each feature, fix, or documentation task. Check for an existing assignment and overlapping pull requests first, so edits stay scoped to the right work and do not build on another task’s changes.

  • Starting a feature in its own worktree
  • Fixing a bug without editing the shared checkout
  • Checking for overlapping pull request changes
michaelshimeles/rstack1.4KUpdated Oct 26, 2026

See all skills by michaelshimeles

Report a problem with this skill