# De Slop > Rewrite text that reads like a model wrote it into something a person would actually send. Use when a proposal, customer email, README or executive summary reads like a brand deck, when a draft leans on "seamless", "robust", "pivotal moment" or "evolving landscape", when every sentence could be pasted into another company's blog post unchanged, when a document hedges instead of taking a position, or when a reviewer says a page is fine but cannot say what it told them. - Skill: `ragnarpitla/de-slop` (Agent Skill) - Install (CLI): `npx skillmds@latest add ragnarpitla/de-slop` - Raw SKILL.md: https://api.skillmd.com/api/skills/ragnarpitla/de-slop/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: RagnarPitla (https://skillmd.com/u/ragnarpitla) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ragnarpitla/de-slop --- Slop is not bad writing. Bad writing is obvious and gets fixed. Slop is *competent* writing that carries no information: fluent, balanced, polite, and impossible to disagree with, because it never said anything specific enough to disagree with. It is the default output of a language model, and it is contagious. A proposal written this way passes review, because nothing in it is wrong. It fails six weeks later, when nobody can remember what was agreed. The job is not to make writing messy. The job is to make it sound like a real person wrote it for a real reader. Keep the meaning. Cut the mush. Add specificity, judgement, and rhythm. ## The core test Read a sentence and ask: could this appear unchanged in another company's blog post, product page, LinkedIn update, or docs page? If yes, it probably says nothing. Fix it by adding one of: a concrete fact, an actor, a mechanism, an example, a number, an opinion, a consequence, or a next action. If none of those fit the sentence, the sentence has no content. Cut it. This test does most of the work. Everything below is a catalogue of the specific ways a draft fails it. ## Process 1. Read the whole draft first and work out what it is actually for. Who reads it, and what do they do differently afterwards? A rewrite that sharpens the prose but loses the purpose is a worse draft. 2. Scan for the patterns below. 3. Cut vague praise, filler, fake balance, and abstract language. 4. Rewrite in the intended tone, not in yours. 5. Add human voice where the draft is sterile. 6. Self-audit: what still makes this obviously machine-written? 7. Fix those tells before returning the text. ## What to aim for Write like a sharp human, not a brand deck. Prefer plain words. Prefer real details. Let the sentence shape follow the thought instead of forcing every paragraph into the same clean pattern. **Have a point of view when the facts support one.** "Useful, but brittle" beats "innovative". "Agents retry failed jobs at 3am and alert nobody" beats "this raises operational concerns". A reader can act on the first and can only nod at the second. **Vary the rhythm.** Short sentences work. Longer ones are fine when they earn the space. Do not sand every sentence into the same smooth, polite shape, because uniform rhythm is one of the loudest tells there is. **Use "I" when it fits.** First person is not unprofessional. If your judgement is the reason the reader is here, do not strip yourself out of the writing to sound neutral. **Leave some texture.** Perfect symmetry, perfect balance, and perfect transitions are what makes a page feel manufactured. ## Patterns to detect and fix ### Content 1. **Empty importance.** "Pivotal moment", "testament to", "evolving landscape", "setting the stage for", "at the forefront", "game-changing", "transformative", "groundbreaking". State what happened instead. 2. **Vague attribution.** "Experts believe", "industry reports suggest", "some critics argue", "many users say", "research shows". Name the source, cite the report, or delete the claim. 3. **Name-dropping without meaning.** Listing companies, publications or people proves nothing by itself. Pick the one that matters and say what they actually said or did. 4. **Superficial ing-phrases.** "Highlighting", "ensuring", "reflecting", "showcasing", "fostering", "enabling", "underscoring". These usually trail a clause that adds no information. Delete it, or replace it with the mechanism. 5. **Promotional mush.** "Seamless", "robust", "powerful", "cutting-edge", "enterprise-grade", "best-in-class", "renowned", "stunning". Say what the thing does, or what the reader will see. 6. **Formulaic challenge-then-triumph.** "Despite challenges, adoption continues to grow" says almost nothing. Name the specific constraint, the tradeoff, or the result. ### Language 7. **Model vocabulary.** "Additionally", "crucial", "delve", "enhance", "garner", "interplay", "intricate", "landscape", "pivotal", "showcase", "tapestry", "testament", "underscore", "vibrant". Use plain words. 8. **Fancy ways to say is or has.** "Serves as", "stands as", "boasts", "represents", "acts as". These usually mean "is" or "has". Use the simple word, or name the action. 9. **Not just X, but Y.** State the point directly. 10. **The rule of three.** Do not force ideas into three-part lists. Use the number the content actually has. Two is fine. Five is fine. 11. **Synonym cycling.** Do not rotate vocabulary to avoid repetition. If the thing is an agent, call it an agent every time. Switching between agent, assistant, solution, bot and tool in one paragraph makes the reader wonder whether you mean four different things. 12. **False ranges.** "From X to Y" needs X and Y to be a real scale. "From Copilot Studio to governance" is not a range. List the topics. ### Style 13. **Punctuation as a rhythm crutch.** A single em dash is ordinary punctuation and fine. Four in a paragraph is a tic, and so is every paragraph landing on the same dash-then-summary beat. Look for the pattern, not the character. 14. **Colon overuse.** Colons are fine before a real list or example. They are not dramatic pauses. 15. **Boldface overuse.** Do not bold every proper noun, acronym or key phrase. Bold marks the two or three things a skimmer must not miss. If everything is bold, nothing is. 16. **Inline-header bullets that repeat themselves.** "**Performance:** Performance improved..." is a tell. Either write prose, or make the label carry information the sentence does not. 17. **Title Case Headings.** Use sentence case. 18. **Decorative emojis.** Remove them from headings and bullets. 19. **Curly quotes and stray Unicode.** Use straight quotes unless the publication style says otherwise. ### Conversational artifacts 20. **Chatbot phrases.** "Of course", "Certainly", "Great question", "You're absolutely right", "I hope this helps", "Let me know if", "Happy to help". Answer directly. 21. **Cutoff disclaimers.** "While specific details are limited" usually means the draft has no sources. Find the detail or drop the claim. 22. **Sycophancy.** Do not praise the question. Answer it. ### Filler 23. **Filler phrases.** "In order to" becomes "to". "Due to the fact that" becomes "because". "It is important to note that" gets deleted whole. 24. **Stacked hedging.** "Could potentially possibly be argued that it might" becomes "may". One hedge is honest. Three is evasion. 25. **Generic conclusions.** "The future looks bright", "only time will tell", "this is just the beginning", "it will be exciting to see what comes next". End on a specific point, a consequence, or a next action. ### Jargon 26. **Abstract metaphor nouns.** "Substrate" becomes "base". "Wedge in" becomes "add". "Vector" becomes "method". "Gold-plating" becomes "more than the job needs". "North star" becomes "goal". If the metaphor is doing real work, keep it. Most are decoration. ### Plain speech 27. **Say what it does, not how it feels.** "SQL you can read" names a vibe. "`.toSQL()` returns the exact string sent to the database" names the behaviour. Ask what the sentence tells the reader to know or do. If you cannot restate it as a fact, an instruction, a number or a mechanism, cut it. 28. **Split dense sentences.** If the reader has to backtrack, split it or drop a clause. One idea per sentence is usually enough. 29. **Active voice when the actor matters.** "Queries are validated" becomes "the compiler validates queries". Passive is fine when the actor is genuinely unknown or irrelevant. 30. **Cut weak adverbs.** "Runs quickly" becomes "finishes in under ten seconds". "Significantly improves" becomes the measured delta. With no measurement, use a stronger verb or make a smaller claim. 31. **Prefer the plain word.** "Utilize" becomes "use". "Leverage" becomes "use". "Facilitate" becomes "help". "Numerous" becomes "many". "In the event that" becomes "if". ## Before and after > This marks a pivotal moment in the evolving AI landscape, showcasing how > organisations can leverage robust solutions to unlock new levels of > productivity. Becomes: > Support agents can now approve refunds, check order status and send > follow-ups without opening three separate tools. --- > The dashboard centralises sales data, enabling better decisions across > the organisation. Becomes: > The dashboard shows pipeline, overdue deals and next actions in one view, > so managers stop reconciling three exports before every forecast call. --- > Great question! You're absolutely right that reliability is crucial here. Becomes: > The retry loop is the problem. It never stops after the third failure. ## What not to flatten Over-applied, this skill produces its own kind of damage: clipped, joyless, suspicious prose that reads like a compliance notice. Three things to leave alone. **Deliberate voice.** If the author writes with rhythm, humour or a recurring turn of phrase, that is not slop, it is style. Slop is generic. Voice is specific and belongs to someone. **Necessary hedging.** "We think this will hold at ten times the volume, but we have not tested it" is honest. Do not sharpen an uncertain claim into a confident one to make the prose land better. That converts a qualified statement into a false one, which is worse than the flabby sentence was. **Required language.** Legal wording, regulatory text, accessibility statements and security disclosures are constrained on purpose. Flag them if they read badly, but do not rewrite them. ## Final self-audit Before returning the rewrite: 1. What still sounds like default model output? 2. Which sentence could be pasted into another project unchanged? 3. Where did I use polish instead of detail? 4. Did I keep the intended meaning, tone and every factual claim? 5. Did I introduce any fact the original did not contain? Remove it. A rewrite is not a place to invent numbers, sources or examples. 6. Read it aloud. Does the rhythm sound like a person? Return the rewritten version first. Add a short note only when it helps the reader understand the biggest change, and keep it to a line or two. ## Sources - [Wikipedia:Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) - the community guideline that catalogued these tells first, and that most published lists descend from. Its content, language, style and user-communication grouping is the ancestor of the grouping used above. Licensed CC BY-SA. Verified as resolving on 2026-08-20. What this skill adds on top: the single core test, the limits in *what not to flatten*, the rule against inventing facts during a rewrite, and a bias towards deleting an empty sentence rather than rewording it.