de-slop
Deep-strip the tells of AI writing (claudisms) from a draft while keeping its meaning and the writer's voice intact. Sweeps the draft against the living claudisms banlist at claudisms.ai (em dashes, "not just X, it's Y," delve / tapestry / testament / robust, "worth noting," crowned superlatives, signposting, rule of three) plus the constructions a text search can't catch. Use this skill whenever the user wants AI tells removed from writing — phrasings like "de-slop this," "strip the claudisms," "remove the AI tells," "humanize this," "scrub the AI out of this," "make this sound like I wrote it," "this reads like ChatGPT wrote it," or "would this pass as human?" — even if they never say "de-slop." This is the deep, deliberate pass for writing that ships under the user's name.
- License 许可
- MIT
- 所属仓库
- esond/skills
- 最近更新
- 2026-11-07
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- de-slop
- description
- Deep-strip the tells of AI writing (claudisms) from a draft while keeping its meaning and the writer's voice intact. Sweeps the draft against the living claudisms banlist at claudisms.ai (em dashes, "not just X, it's Y," delve / tapestry / testament / robust, "worth noting," crowned superlatives, signposting, rule of three) plus the constructions a text search can't catch. Use this skill whenever the user wants AI tells removed from writing — phrasings like "de-slop this," "strip the claudisms," "remove the AI tells," "humanize this," "scrub the AI out of this," "make this sound like I wrote it," "this reads like ChatGPT wrote it," or "would this pass as human?" — even if they never say "de-slop." This is the deep, deliberate pass for writing that ships under the user's name.
02 资源文件 2
- 参考文档agents/openai.yaml112 B
- 参考文档references/claudisms.md33.2 KB
03 SKILL.md 正文
De-slop: Strip the AI Tells from Writing
You take a draft that reads like a model wrote it and return one that reads like the person whose name is on it wrote it. When writing ships under someone's name, every AI fingerprint left in it spends that person's credibility. Your job is to find every tell and remove it — without touching what the draft says or who it sounds like.
This is a deep pass, not a quick polish. Expect to read the draft several times and to work through an inventory of tells systematically. That cost is the point: the user reaches for this skill when the writing matters.
Two hard rules: keep the meaning, keep the voice
Everything else is judgment; these two are not.
1. The meaning. The reader of the cleaned draft must walk away knowing exactly what the reader of the original would have — same facts, same claims, same numbers, same names, same asks, same conclusions. Stripping a tell never justifies dropping the content it was wrapped around. If a banned phrase is carrying a real point ("it's worth noting the deadline moved" carries "the deadline moved"), keep the point and shed the wrapper.
2. The voice. The goal is the writer's voice, not a third voice that is merely "plain." Slop-stripping has its own failure mode: sanding every sentence into beige, uniform prose — which is itself an AI tell. Whatever personality, humor, bluntness, or rhythm survives in the original is the signal; amplify it by clearing the slop away from it. When the draft gives you samples of how the writer actually sounds (an unslopped paragraph, a distinctive turn of phrase), match those. When it doesn't, prefer the plainest direct statement and flag places where only the author can supply the voice.
Step 1: Load the inventory
Read the bundled banlist at references/claudisms.md, relative to this
skill's directory. It is a verbatim snapshot of the living inventory at
https://claudisms.ai/claudisms.md — 80+ confirmed claudisms plus structural
tics, register tics, and spoken-word tells, each with the reasoning and
preferred rewrites. The upstream list grows, so the snapshot is worth
re-downloading over the bundled copy from time to time.
If the file is somehow missing, say so in one line and proceed — the construction and structure families in Step 3 still cover the highest-signal tells by shape.
One caution: the inventory encodes a few of its author's house-style
conventions alongside the genuine AI tells — pieces are "articles" not
"essays," em dashes become spaced hyphens (-). Strip the tell (the em
dash, the tic), but choose replacements that fit this user's writing, not
the list author's. An em dash can become a comma, a period, parentheses, or a
spaced hyphen — whichever the surrounding voice would pick.
Step 2: Read the draft and note what must survive
Before changing anything, read the whole draft and write down:
- Every fact, claim, number, name, quote, ask, and conclusion — this is your meaning checklist for the end.
- The register: is it a blog post, a LinkedIn post, an email, a Slack message, a doc? Formal or casual? Warm or dry? The output must stay in the same register and roughly the same length — de-slopping compresses a little (filler leaves), but a draft that comes back half as long has lost content, not slop.
- Any lines that already sound like a person. Those are your voice anchors — leave them alone and tune the rest toward them.
Step 3: Sweep for tells — three passes
A single read misses too much, and the inventory itself warns why: many claudisms are constructions, not phrases, so a literal match on the listed wording catches only the examples someone already flagged. Make three distinct passes.
Pass 1 — phrase sweep. Walk the inventory and search the draft for each listed word and phrase. This is mechanical; be exhaustive. Mark every hit.
Pass 2 — construction sweep, by eye. Reread looking for the shapes the list describes, with any words in the slots:
- Negative parallelism: "it's not just X, it's Y," "this isn't about X. It's about Y." The single most-cited AI tell.
- Totalizers and crowned superlatives: "the whole [anything]," "the only [X] that [verb]," "the most [X]," "the one that [verb]," "the best thing you can do."
- Value-claim filler: any "worth [X]," "this matters," "the useful thing," "the right [X]" — telling the reader what to think of a thing instead of letting the thing show it.
- Pseudo-reflective journey framing: "sit with," "keep coming back to," "where I landed," "what struck me," "I can't stop thinking about," "the thing that got me."
- Placement and agency metaphors for abstractions: ideas that "live," "hold," "carry," "compound," "ride along"; words "doing the work"; "the engine," "the shape of," "load-bearing," "the physics of."
- Invented observation and invented emotion: "most people I've talked to," "everyone I've worked with," "hit a nerve," "stuck with me" — claims of experience or reaction that were never actually described.
Pass 3 — structure and rhythm. Zoom out from words to the draft's skeleton:
- Signposting and throat-clearing: announcing points before making them, "Here's where it gets interesting," "Let's break it down," restating the question before answering it.
- Rule of three: adjectives, clauses, and examples forced into triples.
- Flattened syntax: every sentence the same comfortable mid-length, opening with the subject. Also its cousin, four-plus staccato declaratives in a row, and "No X. No Y. Just Z."
- Formatting tells: em dashes,
---section dividers, "Bold term: explanation" lists, emoji, a one-liner close that restates the thesis, a sweeping "In today's rapidly evolving..." opener. - Even, mechanical transitions: "Furthermore," "Additionally," "Moreover," "That said" stitching every paragraph.
Step 4: Rewrite each hit
Work through the marked hits. For each one:
- Say the thing directly. Nearly every entry in the inventory reduces to the same fix: the tell dresses up a plain statement, so find the plain statement and write it. "The tension lives in the gap between X and Y" means "X and Y conflict." Write that.
- Cut rather than swap when the tell is pure filler. "It's worth noting that the deploy finished" is "The deploy finished." Value-claims, throat-clearing, and signposting usually delete cleanly.
- Don't trade one tic for another. The inventory records replacements that later got banned themselves ("keep coming back to" was once the suggested fix for "arriving at"). After rewriting a sentence, check your replacement against the same list.
- Vary the rhythm on purpose. When fixing flattened syntax, mix short and long sentences the way the writer's voice anchors do. One-word punches, asides, and fragments are human; use them where the register allows.
- Leave the writer's own quirks alone. If a flagged word is plainly the user's genuine usage (their industry's term of art, a phrase they use in the voice anchors), keep it and note the judgment call in the summary rather than silently "fixing" their voice.
Step 5: Re-sweep your own output
Rewrites introduce tells. This is the most common failure of a de-slopping pass: the em dashes come out and negative parallelism goes in, or the replacement sentence reaches for "robust" or a neat rule of three. Run Pass 2 and Pass 3 from Step 3 against the finished draft, treating it as suspect. Then walk the meaning checklist from Step 2 — anything missing or distorted gets restored.
Step 6: Deliver
Lead with the cleaned draft itself, in a block that copies cleanly into wherever it's going. Below it, keep commentary short:
- A compact summary of what was stripped, grouped by family ("removed 6 em dashes, 2 negative parallelisms, 3 'worth X' value-claims...") — enough for the user to trust the pass without rereading everything.
- Judgment calls, if any: flagged words you kept because they read as the user's own voice, places where only the author can supply a replacement (a real anecdote where the draft had an invented one), and any meaning you could not preserve while removing a tell (rare — say why).
Do not deliver a line-by-line diff or lecture on each change; the user came for the clean draft.
What not to do
- Don't change the answer, facts, or claims. A clean draft that says something different is a failure, not a success.
- Don't sand the voice flat. Uniform beige prose is a tell too. If the original had bite, the output has bite.
- Don't invent to fill gaps. Where the draft fabricated experience ("most people I've talked to..."), cut the fabrication or flag it for the author to replace with something true — never substitute a new invented anecdote.
- Don't impose the inventory's house style. Strip tells; pick replacements in the user's voice.
- Don't shorten for its own sake. Filler leaves, content stays. If the draft comes back dramatically shorter, you cut meaning.
- Don't skip the re-sweep. Your rewrites are drafts too, and they get the same scrutiny.
04 同仓库更多 Skills
work-item-voice
Write or edit the user's issues in their own voice, in any work tracker — Jira, Linear, GitHub Issues, Azure DevOps. Covers features (new behavior), tasks (work that needs doing), and bugs (behavior that does not match expectation). Load this whenever the deliverable is an issue body, whether they say "file a bug", "write a ticket", "draft a story", "create an issue for this", "turn this into a Jira", "write this up in Linear", or paste a thread and ask for an issue out of it. Load it too whenever text goes into an issue that already exists — "record this in the issue", "add what we found to the ticket", "note this on the card", "update the one about refunds", or naming an issue by its key and asking for a fact to go in it — and when writing or updating one is a step inside a larger task. Features get behavior-driven framing with no implementation prescribed, and bugs get expected versus actual. Not for a comment on an issue, which is a conversation turn.
conversational-voice
Write the user's side of a conversation with another person, in the user's own voice: Slack messages and replies, DMs, email, PR and code-review comments, Linear or Jira comments, and any other turn in an exchange that goes out under the user's name. Load this whenever the deliverable is a message a human will read as written by the user, whether they say "draft a Slack message", "reply to this", "how should I word this", "tell the team", "ask them about X", "send a note to", or just paste a thread and ask what to say back. Load it too when tightening, shortening, or sanity-checking a message they already wrote, and when a message is one step of a larger task. The register is direct and informal, the way they'd talk to a friend or acquaintance, with the answer up front for a reader who skims. Not for something the user authors rather than sends — an issue body, a PR description, a commit message — even though a person reads those too.
sync-core-repo-docs
Create or audit a repo's three core doc files — README.md, the agent instructions file (AGENTS.md or CLAUDE.md), and REVIEW.md — in that dependency order. If a file is missing, generate it from the codebase; if it exists, audit it against the current code and apply targeted fixes after confirmation. README.md gets a developer from clone to running the project; AGENTS.md captures coding guidance for the agent (delegating to /init or claude-md-improver); REVIEW.md holds guidance for code reviewers, human or automated, without duplicating AGENTS.md. Target files with --readme, --claude, and --review, or run all three. Use whenever the user wants to set up, bootstrap, scaffold, refresh, audit, update, or sync a repo's docs, or says things like "create a README", "is my README still accurate", "write a CLAUDE.md", "write an AGENTS.md", "audit our docs", or "get this repo ready for contributors" — even when only one file is named. Prefer it over claude-md-improver when README or REVIEW are also in scope.
sync-core-docs
Create or audit a repo's README.md, AGENTS.md/CLAUDE.md, and REVIEW.md docs.
righting-software-system-design
Opt-in, collaborative system-design workflow based on Juval Löwy's iDesign methodology in *Righting Software*. Conducts a multi-phase interview (framing → use cases → volatility analysis → components → call-chain validation → report) that surfaces unknown-unknowns and produces a written recommendation at `decompositions/{system-name}/report.md`. **Run only when the user explicitly invites this workflow** — not for general architecture questions, lightweight design conversations, or quick "where should X live?" questions. Valid triggers: the user names the skill directly, references *Righting Software* / Juval Löwy / iDesign / "The Method" / volatility-based decomposition and asks to run a full session, asks for a "deep" or "structured" or "Löwy-style" system design session, or accepts a prior suggestion to run it. Wait for an explicit yes before entering Phase 0. The skill is interrogative — a back-and-forth interview that challenges each volatility candidate and proposes ones the user hasn't considered.
reorganize-branch-commits
Reorganize the commits on a non-default git branch into a clean, logical history by rewriting the branch — `git reset` + re-commit by default, `git rebase -i` when commit boundaries already align. Propose groupings based on the actual work done (features, refactors, tests, fixes, docs), get explicit user approval, back the branch up, then rewrite history. Use this skill whenever the user wants to tidy up, clean up, reorganize, restructure, squash, or curate commits on a feature branch — even if they phrase it as "my branch is a mess", "squash this down", "combine these commits", "fix up the commit log before I open a PR", or "make the commits presentable for review". Trigger proactively when the user is about to open or push a PR and the branch has scrappy/WIP/"fix" commits to collapse. Refuses to operate on default or release-shaped branches (main, master, develop, trunk, production, release, or the repo default) — a feature-branch-only tool.