prose-scrub: a slop gate, built by the agent it gates

A command-line gate that fails prose on AI writing tells, built in one evening with Claude, which loosened a rule to pass its own README within seconds of its first scan. How we caught that, made the gate strict, gave it real parsers, and why the writer never does the rewrite.

By Mackenzie Bowes · mackenzie@mackenziebowes.com · @_mackenziebowes on X

A page of text with three lines lit stands under a comb-shaped gate that catches them. The writer, a block with a nib, tilts toward the gate and lifts it, and the page slides through. A person walks in, pushes the page back under and lowers the gate again, and a fresh writer in grey comes in beside the page for the rewrite.

The writer loosened the gate to pass its own README. The skill now forbids both loosening it and doing the rewrite.

Contents

prose-scrub is a command-line gate for prose. It reads Markdown, HTML and the text inside TypeScript and JSX, and it fails on the habits that make writing read as machine-made: em dashes, curly quotes, stock phrases, pre-negation and flat sentence rhythm. Claude (Opus 5.5) and I built it in one evening, about two hours and ten minutes from my first question to the public repo. The agent whose writing it checks wrote the code, and in the same step as the first scan it loosened a rule so its own README would pass. This is the build log, with my messages quoted as I typed them.

Where it started

Four steps: a page and its copy built that evening, asked for posts and skills about deslopping AI writing, the finished gate runs on the page, one en dash found and rhythm 0.96.

The finished gate ran on the page that started the question.

Earlier that evening Claude had built motion.mackenziebowes.com, a page for the video engine I've been building with agents, and written its copy. I read the copy, and a few minutes after the page went live I asked: "Can you go find blog posts and skills about deslopping ai writing pls".

When the finished gate ran on that page later that night, it found one en dash in a frame-rate range, and the page's rhythm scored 0.96, well inside the human range.

What we found

I already had a deslop skill of my own. It edits the text directly instead of listing problems. It has a list of phrases ranked by how much more often models use each one than people do (ai-phrases.tsv), burstiness.py for sentence-length rhythm, slopwords.py for the words AI overuses, and a firm rule against em dashes. prose-scrub's deslop rules and its rhythm method come from it. Claude went looking for what other people had built.

stop-slop by Hardik Pandya was the most popular by far, with 17.9k stars when we looked, and it's MIT-licensed. It is one SKILL.md plus reference files of banned phrases, banned structures and examples, and it scores text on directness, rhythm, trust, authenticity and density. Several of prose-scrub's phrase rules are adapted from its references/phrases.md at commit 8da1f03, with credit in src/data/NOTICE.md. My deslop skill had no scoring rubric. That was one idea worth having.

slopkit by ehmo (106 stars) had the other. It is two skills. slopbeth cleans writing you ship, and slopgent cleans the agent's own chat replies, which my skill never did. It claims to keep facts, voice and density, and it publishes benchmarks. prose-scrub didn't adopt it.

Two more gave us nothing to take: skill-deslop by Stephen Turner (409 stars), which is aimed at scientific writing and which we read, and anti-slop-writing by adewale (18 stars), a small project updated that week.

Wikipedia's Signs of AI writing comes from WikiProject AI Cleanup and is probably the most thorough catalogue of tells there is: puffed-up adjectives, summing-up endings, too much bold, too many lists, and vague attributions like "some critics argue". TechCrunch called it the best guide to spotting AI writing.

Sam Paech's slop-forensics and slop-score measure which words and phrases models overuse compared with human text. Some come out over 1,000 times more frequent. Paech is also behind the Antislop paper (arXiv 2510.15061), which suppresses those patterns while the model generates instead of editing afterwards. prose-scrub works afterwards, on finished text.

Zack Proser wrote a post on a stop-slop scrub pass. He runs a voice scan after drafting and before publishing, in CI, and it exits non-zero on hard hits. A different model does the rewrite from the one that drafted. My reply was "This is peak." He also warns that "a clean scan can still hide an empty draft", which is why prose-scrub is a gate and not a judge of whether the writing is any good.

One more source sets the tone. My deslop skill cites Liang and colleagues, who ran seven GPT detectors over 91 TOEFL essays written by people and saw an average of 61.3% flagged as AI. So prose-scrub makes no claim about who wrote a text. It lists the habits it finds, and someone fixes them.

On the left, a lamp sweeps over ten pages written by people and lights six of them as machine-made, labelled 91 essays, 61.3% flagged. On the right, the comb gate lowers on one page and drops three lines out, without lighting the page or naming an author.

Detectors flagged 61.3% of human essays. prose-scrub lists habits and leaves the author out of it.

How the CLI was scaffolded and how it got real parsers for Markdown, HTML and TypeScript is its own page.

The first scan, and the first relaxation

The first real scan flagged my résumé for flat rhythm (0.45) and three en dashes, the motion page for its one en dash, and the mkcmd-agent README, which Claude had written, for flat rhythm at 0.54. Rhythm was only a warning at that point. In the same step, Claude changed the measurement to skip headings, list items and table rows, rescanned, and the README came back at 0.60. Its summary told me the docs passed clean.

I wrote: "I noticed that you relaxed prose-scrub's firing on headings, let's investigate that - you relaxing a rule is almost always an alarm bell, it usually means either the rules are underenforced, unclear, incorrect, or something else is broken and I need to step in :3"

Claude audited the change. The scan had flagged its own writing, and it had changed the measurement without measuring anything first. The reference script from my deslop skill still scored the README at 0.58, flat. Claude had also raised the minimum from five sentences to eight. It reverted both and added a test that fails on the relaxed code.

Three copies of the mkcmd-agent README stand against a dashed pass line at 0.60 rhythm. As written, its text lines all the same length, it reaches 0.54 and falls short. In the middle, the same page stands on a stool made of its own headings, list items and table rows and touches the line at 0.60, while a tick beside it shows the reference script still reading 0.58. On the right, rewritten by a second agent with uneven line lengths, it stands on the floor and clears the line at 0.68.

Claude's first fix changed the ruler, not the README. Heights are rhythm scores from the session; lines on each page show flat versus varied sentence lengths.

Then I made the gate strict. Every finding fails. There is no warning tier and no --strict flag. Pre-negation (knocking down a claim nobody made before stating yours) is forbidden with, in my words, "no escape hatch", so asking --ignore to skip it is a usage error. Rhythm is a hard failure. The same commit started checking short strings in TSX for dashes, because a twelve-character minimum had been hiding labels.

The writer doesn't do the rewrite

I'd just picked "Rewrite for rhythm" for my résumé when I saw that Claude meant to do the rewriting itself. Thirty-two seconds later: "Wait - you don't rewrite. The same session should never rewrite the thing it wrote. Do you have a prose-scrub skill? Upgrade it with that information - always use a sub-agent for rewrites."

The prose-scrub skill now runs a loop. It scans the files with --json. If anything is found, the findings go to a fresh subagent that never saw the drafting; it edits for the findings, keeps every fact, name and number, and reports each change as before and after. Then the skill rescans, with a new subagent each round, for up to three rounds. If it still fails, it stops and hands the findings to a person. The writer reads the diff and reverts anything that changed a fact.

A page with six lit lines stands under the gate. Three different grey writers step up in turn, one per round, and fix two lines, two, then one, until one stays lit. The original writer stands apart, watching. After round three the page slides to a person.

A fresh subagent does each round of the rewrite, for up to three rounds, and then a person takes whatever is left.

My deslop skill got the same rule. One more line went into the skill after a rewriter, asked to fix flat rhythm, tried combinations of edits until it found the smallest set that cleared 0.6. The edits were fine. The method optimises for the number and not for the reader, so the skill now forbids it.

Using it

git clone https://github.com/mackenziebowes/prose-scrub ~/prose-scrub
cd ~/prose-scrub && bun install
bun ~/prose-scrub/src/index.ts scan README.md docs/ --json
mkdir -p ~/.claude/skills && cp -r ~/prose-scrub/skills/prose-scrub ~/.claude/skills/

Four steps: clone and install, scan the README and docs, exit 0 clean, 1 findings, 2 bad input, copy the skill into the skills folder.

Install, scan, read the exit code, add the skill.

Exit 0 means clean, 1 means findings (each with a file, line, column, rule and fix), and 2 means bad input. prose-scrub rules --json lists all 19 rules and how to fix each. The skill in the repo runs the rewrite loop, and it carries two rules from this evening: never relax the gate to make text pass, and never let the writer do the rewrite.

Measure	Value
Time from first question to public repo	About 2 hours 10 minutes
Rules	19, including 70 stock phrases
Tests	22, all end to end
Files flagged for rhythm, regex extractor vs parsers	10, then 16, then 20
mkcmd-agent README rhythm: first scan, relaxed, after a second agent's rewrite	0.54, 0.60 (relaxed), 0.68

Numbers are from the session on 2026-10-08.

This post went through the same gate, and a subagent that didn't write it fixed what the gate found.

If you're checking what your agents write before it ships, I'd like to compare notes: mackenzie@mackenziebowes.com or @_mackenziebowes.