unslop is an agent skill that finds formulaic writing and edits it carefully

Four commands, and scanners that only suggest

unslop finds formulaic or unclear writing and makes targeted edits while preserving meaning and voice. It arrives as an agent skill with standalone Python scanners, and four commands cover the surface. The teach command builds a reusable voice from your own writing samples. The cleanup command flags AI tells as reviewable suggestions and changes nothing on its own. The rewrite command diagnoses a draft and rebuilds it under the guards, and that is the default. The mimic command drafts or rewrites in a taught voice and then clears every removal gate, which is the one behaviour to think hardest about before using it.

The division of labour is the design. Scanners suggest candidates and the agent checks each use in context, and rewrite gates check preservation and known defects. The project is careful about what this does not establish: neither a clean scan nor a familiar phrase proves who wrote the text, and the checks cannot guarantee that every defect is gone.

That last line is unusual to find in a README for a writing tool, and it tells you how the project is built. The scanners are evidence, and the agent is the judge.

The headline evaluation result is a no-ship

The most informative document in the repository is not the README but the evaluation pair, evals/CORE-BENCHMARK.md and evals/CORE-RESULTS.md, and the headline result is negative. The project states the product claim narrowly: on unfamiliar AI-generated or mixed prose, unslop should find genuine problems, repair them, and avoid damaging facts or already-good writing.

The latest independent public result is a no-ship. UNSLOP improved recall and repair over plain Luna, the same model working without the UNSLOP contract, but it did not meet the precision, damage, or whole-document safety bar. The core benchmark therefore reports detection precision and recall, repair success, preservation, collateral-damage rate, and whole-document net improvement separately, plus byte-exact no-op behaviour on clean prose.

For a user this is the single most useful fact about the project. A tool that reports its own failing score is giving you the information you need to decide whether to trust it, and the failure modes are documented in CORE-RESULTS.md rather than hidden.

Three scoreboards so engineering cannot inflate the product

Results are split across three scoreboards for a stated reason: supporting machinery should not be able to inflate the product result. The core product scoreboard covers detection, repair, preservation, damage and net improvement. The voice scoreboard covers teach and mimic fidelity along with its removal gates. The engineering scoreboard covers scanner coverage, schemas, routing, caching and repository regressions.

The line the project draws is the one worth remembering. The engineering suite can show that the implementation behaves as specified, while only the core scoreboard can show that the specification improves writing. Most projects would report the first kind of result, where every test passes, and treat it as a quality claim. This one separates them on purpose.

The development runner supports OpenAI through Codex, Anthropic through Claude, Gemini, and open models through Cloudflare AI Gateway, and each model runs paired with-skill and without-skill arms under the same contract, which is how the comparison against plain Luna is produced. The README adds a caveat worth repeating: provider support is separate from demonstrated writing quality.

Installing the skill with the Skills CLI

The recommended path is the Skills CLI, which installs the skill into any supported coding agent. The commands are the same shape each time, with the target agents named after the -a flag:

# Install to Claude Code (global)
npx skills add theclaymethod/unslop -g -a claude-code

# Install to several agents at once
npx skills add theclaymethod/unslop -g -a claude-code -a cursor -a codex

The global flag installs for the current user rather than into a single project, which is the choice to make deliberately, since a writing skill that follows your voice is more useful across repositories than inside one. The remaining documented forms cover installing to every detected agent without naming any, and listing what is available before you install:

# Install to every detected agent
npx skills add theclaymethod/unslop -g

# List available skills first
npx skills add theclaymethod/unslop --list

The global flag installs for the current user rather than into a single project, which is the choice to make deliberately, since a writing skill that follows your voice is more useful across repositories than inside one.

Manual install, and scanners that run without the skill

A manual install is a clone and a symlink, and there are two ways to wire it up, one as a skill directory and one as a slash command file:

git clone https://github.com/theclaymethod/unslop.git ~/dev/unslop
ln -s ~/dev/unslop ~/.claude/skills/unslop
# Or wire it as a slash command:
ln -s ~/dev/unslop/SKILL.md ~/.claude/commands/unslop.md

The more interesting half of the README is what happens if you do not want an agent in the loop at all. The Python scripts under scripts/ run on their own, with no third-party dependencies, just Python 3.8 and the standard library. You can call them from CI, from a pre-publish check, or from another agent, and the skill is never loaded.

That is a genuinely different integration model from the one most writing tools offer. The skill is a convenience wrapper around scanners that are usable as ordinary command line tools, which means a documentation pipeline can fail a build on a phrase list without anyone installing an agent.

The phrase layer masks code and quotes before it flags

Detection stacks three deterministic scanners, coarse to fine, and each one returns JSON and exits non-zero on a flag. The phrase layer is scripts/banned_phrase_scan.py, and its runtime pack holds 16 literal triggers, each backed by contextual false-positive protection. Gated words fire only in their jargon collocations, so literal legal, medical, mechanical, historical and technical uses stay clean.

The detail that matters most is the masking step. Quoted spans, blockquotes and code fences are masked first, so a tutorial documenting bad writing does not flag its own examples. For a tool whose whole purpose is scanning prose, a scanner that flags its own documentation would be unusable in a repository that discusses the patterns it removes, and the masking order is the fix.

The project is also honest about the limit. False-positive examples protect tested literal and domain uses, but unfamiliar contexts still need review. So the scanner is a source of candidates for a human or an agent to check, not a verdict.

The structure layer measures rhythm, and carves out genres

scripts/structure_scan.py carries 36 structural patterns plus document-level metrics, with names such as sentence_burstiness, paragraph_cv, triad_density, bold_colon_listicle_count, one_line_staccato_share, connective_paragraph_openers, signpost_density, opener_unique_ratio, top_opener_share, max_consecutive_opener, participial_closer_share, conclusion_coda and summary_sandwich. The intent is to catch the rhythm tells, uniform sentence length, staccato runs, moralising codas, connective scaffolds that open every paragraph the same way, and the bold-label lists that stand in for prose.

The genre carve-outs are what make it usable in practice. The docs genre allows the bold-label lists that reference documentation really uses, and the social genre allows the short-line cadence that belongs in social copy. A structure scanner without those exemptions would flag most technical writing, which is why a flag list on its own is a weak signal.

The same files, the taboo phrase catalogue in references/taboo-phrases.md and the eval rows, tie the removal side to the detection side, with severity marked as hard for an always-a-tell pattern or soft for a default register guard that your own voice can override.

The silhouette layer scores arrangement, and can be attacked

The third scanner, scripts/silhouette_scan.py, sits a level above the surface and scores how the ideas are arranged rather than which words appear. It catches outline-following, recap loops and paragraph-role templating, through metrics such as scaffold_opener_share, callback_content, role_entropy_bits, preview_fulfillment and heading_preview. Callback_content, meaning opening vocabulary that disappears mid-document and returns at the end, is called the strongest single tell, and the composite silhouette_penalty flags at 1.0 against a committed human reference.

The results on the corpus in the repository are clean: 12 of 12 AI documents flagged and 0 of 8 human documents flagged. The project also publishes the attack against its own method. A cue-deletion attack collapses the scaffold metric, so silhouette is scored jointly with the structure scanner, as a lower fence.

That is the right way to treat the number. A 12 of 12 result on a corpus in the repository, with a documented way to defeat the metric and a fence around it, tells you the signal exists in that corpus and tells you how far to trust it elsewhere.

Editorial conclusion

unslop suits writers who want a reviewable list of formulaic tells and a controlled rewrite rather than a one-click polish, and the standalone Python scanners are usable from CI without loading the skill at all. Do not adopt it as a detector of who wrote a text, since the project itself says a clean scan or a familiar phrase proves nothing, and do not read the engineering scoreboard as evidence of writing quality. Before you build a workflow on it, check three things: that the voice features you need come from the teach command, since mimic clears the removal gates, what the current core benchmark result says about precision and collateral damage, and whether your genre is one the structure layer carves out, since the docs and social presets allow patterns the default flags. The licence is not stated, no GitHub releases exist, and the last push was on 2026-09-07.

Frequently asked questions

Official sources

1. Issues
2. README
3. theclaymethod/unslop on GitHub