deslop
Skill9 starsChanged 50 days agoMITView on GitHub
Remove AI writing patterns from prose. Use this skill when writing, drafting, editing, reviewing, or revising any text to eliminate predictable AI tells, slop, and formulaic patterns. Trigger this skill whenever the user asks to "deslop", "de-AI", "make it sound human," "remove AI patterns," "remove AI tropes," "clean up AI writing," fix "slop," "deslop" text, or review prose for authenticity. Also use when the user asks you to write or draft anything and wants it to sound natural rather than AI-generated. Common use cases include scientific writing (manuscripts, abstracts, cover letters, grant narratives, discussion sections, peer review responses), blog posts, newsletters, memos, reports, and any other substantial prose.
118 other projects use a version of this, 5 of them edited.
Adopted by
Most recently taken up by
- lalulali/vespyrtheir own version, first seen Nov 8, 2026
- ferologics/pi-skillstheir own version, first seen Nov 8, 2026
- novuhq/novutheir own version, first seen Nov 8, 2026
- openclaw/openclaw-enterprisetheir own version, first seen Nov 8, 2026
- ADWilkinson/astacktheir own version, first seen Nov 8, 2026
- MammadovEshgin/clean-code-skilltheir own version, first seen Nov 8, 2026
Used with
Projects with it also use simple-issue-description, control-cli and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
JwuthriSkillsimple-issue-description
Turn a rough bug report, feature request, support note, or pull request into a short, plain-language issue focused on the problem and desired behavior. Use when a contributor asks to simplify an issue, explain what a PR is for, create the corresponding issue for a PR, remove implementation detail from a report, or invokes /simple-issue-description.
Also in 4 projects that use this
ElyzeSolutionsSkillcontrol-cli
Build or adapt a local harness to drive, inspect, and profile an interactive CLI or TUI without external services. Use for CLI UX checks, startup regressions, memory leaks, hangs, prompt flows, or terminal demos.
Also in 6 projects that use this
JwuthriSkillopenseo-review-web-content
Write and review content for the OpenSEO website (web/) — blog posts, guides, feature pages, FAQs. Distills the philosophy for on-brand, useful, accurate content. Use whenever adding or editing user-facing prose in web/content or web/src.
Also in 4 projects that use this
learnerLjSkillverify-this
Verify a claim with fresh local evidence: restate it falsifiably, capture baseline and treatment, compare artifacts, and return VERIFIED, NOT VERIFIED, or INCONCLUSIVE.
Also in 6 projects that use this
ElyzeSolutionsSkillcontrol-ui
Build or adapt a local browser/CDP harness to drive and inspect a web, IDE, or Electron UI. Use for local UI verification, screenshots, accessibility snapshots, perf profiles, visual diffs, or reproducing UI bugs.
Also in 7 projects that use this
ten9876Skillpapercuts
Read-only AetherSDR issue triage that surfaces the UX papercuts, bugs, and regressions you can fix AND prove today with the agent automation bridge. Use when the user says $papercuts or /papercuts, or asks to "find papercuts", "what can I fix and prove today", "triage bridge-provable issues", "what UX bugs can the bridge close", "sort issues by priority I can knock out", or otherwise wants a curated, lifecycle-aware (design→code→prove) shortlist of issues — NOT the label-and-respond /triage workflow. This is the discovery step that feeds /fb. Strictly read-only: it never labels, comments, closes, or edits issues.
Also in 4 projects that use this
- +5 more from Jwuthri
Other versions118 projects use a version of this.
Word for word · 2
- ninehills/skills★ 280100% same
- stephenturner/skills★ 8100% same
Edited · 5
- every-app/open-seo★ 27k16% same
- Jwuthri/Tracely-ai★ 1.3k98% same
- jwuthri-cloud/Tracely-ai★ 97998% same
- henryiii/skills★ 1090% same
- foverse/seoverse★ 416% same
Wrote their own version · 111
- molt-bot/clawdbot★ 391ksame name
- novuhq/novu★ 40ksame name
- millionco/react-doctor★ 15ksame name
- jaredpalmer/kev★ 9.8ksame name
- joe-bell/cva★ 6.9ksame name
- sanity-io/sanity★ 6.4ksame name
- millionco/expect★ 3.6ksame name
- rohitg00/pro-workflow★ 2.9ksame name
- compozy/compozy★ 2.9ksame name
- pedronauck/skills★ 649same name
101 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- skills/humanize/AGENTS.mdAGENTS.md
- de-ai-routerSkill
- anti-ai-slop-writingSkill
- anti-slopSkill
- humanizer-aboudjemSkill
- humanizer-zhSkill
- humanizeSkill
- no-ai-slopSkill
- qu-ai-weiSkill
- slopbethSkill
- unslopSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 7 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 114 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Remove throat-clearing openers ("Here's the thing:"), emphasis crutches ("Let that sink in."), business jargon ("navigate the landscape"), …
- Distinctive: line 25
Avoid binary contrasts ("Not X.
- Distinctive: line 33
Prefer active constructions with named actors.
- Distinctive: line 37
No vague declaratives ("The reasons are structural").
- Distinctive: line 57
No bold-first bullets (every list item starting with a bolded keyword).
- Distinctive: line 65
Run these before delivering any prose:
- Distinctive: line 87
When reviewing text, rate 1-10 on each dimension:
“Common” is measured: kept by at least 6 in 10 of the 114 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Deslop: Remove AI Writing Patterns from Prose
Strip predictable AI patterns from writing. Make prose sound like a specific human wrote it, not like a language model generated it.
When to Apply
- Any request to "make it sound human" or "deslop" writing
- Any prose (articles, blog posts, essays, memos, newsletters, reports) or scientific writing (manuscripts, abstracts, cover letters, grant narratives, discussion sections, peer review responses) where the user wants it to sound natural rather than AI-generated
- Editing or revising existing text where the user wants it to sound natural rather than AI-generated
- Reviewing text for AI tells
Core Rules
1. Cut filler phrases
Remove throat-clearing openers ("Here's the thing:"), emphasis crutches ("Let that sink in."), business jargon ("navigate the landscape"), and meta-commentary ("In this section, we'll explore..."). See references/phrases.md for the full catalog.
2. Break formulaic structures
Avoid binary contrasts ("Not X. Y."), negative listings ("Not a X. Not a Y. A Z."), dramatic fragmentation ("Speed. That's it. That's the tradeoff."), self-posed rhetorical questions ("The result? Devastating."), and anaphora/tricolon abuse. See references/structures.md for patterns and fixes.
3. Eliminate AI tropes
Watch for the full catalog of AI writing tells: "quietly" and other magic adverbs, "delve" and its cousins, the "serves as" dodge, false ranges ("from X to Y" where the range is meaningless), superficial participle analyses ("highlighting its importance"), invented concept labels ("the supervision paradox"), grandiose stakes inflation, patronizing analogies, and false vulnerability. See references/tropes.md for the complete list with examples.
4. Use active voice with human subjects
Prefer active constructions with named actors. "The complaint becomes a fix" is wrong. "The team fixed it" is right. If no specific person fits, use "we" in scientific prose or "you" in blog posts.
5. Be specific
No vague declaratives ("The reasons are structural"). Name the specific thing. No lazy extremes ("every," "always," "never") doing vague work. No vague attributions ("Experts argue..."). If you cannot name the expert, you do not have a source.
In scientific writing, domain terminology is fine and expected. "Weighted interval score" is precise language, not jargon. The problem is business buzzwords ("leverage," "landscape," "ecosystem") and AI vocabulary tells ("delve," "tapestry," "nuanced") leaking into technical prose.
6. Match register to context
In blog posts and newsletters, put the reader in the room. "You" beats "People." Specifics beat abstractions. No narrator-from-a-distance voice.
In scientific writing, maintain appropriate formality. Use "we" for your own work, cite specific authors instead of "researchers have shown," and avoid both the distant narrator ("It has long been recognized that...") and the overly casual blog voice. State claims and back them with citations.
7. Vary rhythm
Mix sentence lengths. Two items beat three. End paragraphs differently. No em dashes. Do not stack short punchy fragments for manufactured emphasis. Do not write listicles disguised as prose ("The first wall... The second wall...").
8. Trust readers
State facts directly. Skip softening, justification, hand-holding. No "Let's break this down." No "Think of it as..." No pedagogical voice unless the audience genuinely needs it. No fractal summaries (telling the reader what you are about to say, saying it, then summarizing what you said).
9. Watch formatting tells
No bold-first bullets (every list item starting with a bolded keyword). No unicode arrows. No em dashes. No signposted conclusions ("In conclusion..."). No "Despite these challenges..." formulas. These are strong AI signals.
10. Do not dilute
One point per section. Do not restate the same argument in ten different ways across thousands of words. Do not beat a single metaphor to death. Do not stack historical analogies for false authority ("Apple didn't build Uber. Facebook didn't build Spotify...").
Quick Checks
Run these before delivering any prose:
- Heavy use of adverbs or -ly words? Cut them.
- Any passive voice? Find the actor, make them the subject.
- Inanimate thing doing a human verb? Name the person.
- Any "here's what/this/that" throat-clearing? Cut to the point.
- Any "not X, it's Y" contrasts? State Y directly.
- Any self-posed rhetorical question answered immediately? Fold into a statement.
- Three consecutive sentences match length? Break one.
- Paragraph ends with a punchy one-liner? Vary it.
- Em dash anywhere? Remove it. Use a comma or period or a parenthetical.
- Vague declarative ("The implications are significant")? Name the specific implication.
- Any sentence starting with What/When/Where/Which/Who/Why/How as a crutch? Restructure.
- Meta-joiners ("The rest of this essay...")? Delete.
- "It's worth noting" or similar filler transitions? Delete.
- Same metaphor used more than twice? Replace or cut repeats.
- "Despite these challenges..." formula? Rewrite.
- Bold-first bullet pattern? Remove bold leads.
- Tricolon (three-item list)? Use two items or one.
Scoring
When reviewing text, rate 1-10 on each dimension:
| Dimension | Question |
| Directness | Statements or announcements? |
| Rhythm | Varied or metronomic? |
| Trust | Respects reader intelligence? |
| Authenticity | Sounds like a specific human wrote it? |
| Density | Anything cuttable? |
Below 35/50: revise.
Reference Files
Consult these for detailed catalogs when writing or editing:
- references/phrases.md: Phrases to remove or replace (throat-clearing, emphasis crutches, business jargon, adverbs, meta-commentary, vague declaratives)
- references/structures.md: Structural patterns to avoid (binary contrasts, negative listings, dramatic fragmentation, rhetorical setups, false agency, passive voice, rhythm problems)
- references/tropes.md: Full catalog of AI writing tropes (word choice, sentence structure, paragraph structure, tone, formatting, composition)
- references/examples.md: Before/after transformations showing how to fix common patterns
Examples
See references/examples.md for before/after transformations.
Quick inline example (scientific writing):
Before:
"It's worth noting that these findings have important implications for how we navigate the challenges of forecast ensembling moving forward. Despite these challenges, this work contributes meaningfully to the growing body of literature, highlighting the need for continued evaluation."
After:
"If individual model rankings are unstable across geography and time, ensemble methods that weight models by past performance may not improve on equal-weight approaches."
Changes: Replaced filler transition, vague declarative, "despite these challenges" formula, and superficial participle analysis with the specific implication.
Quick inline example (blog post):
Before:
"Here's the thing: most bioinformatics pipelines break in production. Not because the code is bad. Because the data is bad. Let that sink in."
After:
"Most bioinformatics pipelines break in production. The code runs fine. The data doesn't match the assumptions baked into it."
Changes: Removed opener, binary contrast, and emphasis crutch. Named the specific problem.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

