deslop
Skill351 starsChanged 7 months agoApache-2.0View on GitHub
Clean up the prose, code or interface already in scope — protect its meaning, voice and behaviour, remove what only adds reading work, and return findings instead of edits when a review was asked for.
118 other projects use a version of this.
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 · 1
- namastexlabs/automagik-genie★ 351100% same
Edited · 0
None found.
Wrote their own version · 117
- molt-bot/clawdbot★ 391ksame name
- novuhq/novu★ 40ksame name
- every-app/open-seo★ 27ksame 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
107 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 repository21 other files it gives its agents.
- AGENTS.mdAGENTS.md
- mikro/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- skills/refine/prompts/claude.mdCLAUDE.md
- authoringSkill
- brainstormSkill
- councilSkill
- docsSkill
- fixSkill
- genie-hacksSkill
- genieSkill
- mergeSkill
- refineSkill
- reportSkill
- researchSkill
- reviewSkill
- skill-auditSkill
- verifySkill
- wishSkill
- workflySkill
- workSkill
The file
We split this skill into the rules it gives an agent
2 rules. 0 are common, 2 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 115 edited versions we read keep these.
2
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 38
No deletion quota, no detector score, no punctuation ban, no compulsory stylistic change.
- Distinctive: line 52
Read the result once against the original.
“Common” is measured: kept by at least 6 in 10 of the 115 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
Reduce the work of reading, maintaining and safely changing what is in front of you, without losing what it guarantees. Lines, sentences, files, wrappers, dependencies and tests have no target count, and a pass that changes nothing is a valid result.
Bound the scope
The subject is what the request already names: this draft, this document, this diff, the code just touched and the callers it reaches. A repository-wide sweep is separate work with its own request. Ordinary drafting and ordinary implementation include checking what you touch; neither authorizes unrelated cleanup, and neither reopens a decision the caller already made.
Name the mode in one line before the first change, and take the narrowest mode the request supports:
| Mode | You return | Done when |
| Draft or implement | The artifact | The requested scope is covered and its own checks pass |
| Cleanup | The edited artifact and what changed | Every change names a benefit, and every protected invariant still holds |
| Review | Findings, nothing edited | Every finding carries a location, the burden it imposes, and the smallest useful fix |
A request to look at something is a review. Rewriting on a review request destroys the evidence the caller asked for.
Protect before you remove
List what must survive before proposing a single removal, and keep the list where the caller can read it.
In prose, protect names, quantities, claims, citations, requirements and causal links, along with the author's stance and degree of certainty. In code, protect the requested behaviour, the existing contracts, and whatever an apparently redundant construct is there to defend.
Removing something whose purpose you cannot state is a guess wearing a diff. When the reason for a construct stays unclear after you have looked for it, the honest output is a low-confidence finding, not a deletion.
Tells are clues, never quotas
The references below name what tends to signal avoidable work. Each one is a reason to look, never a verdict. A contrast may explain a real distinction, passive voice may focus on the right subject, an adverb may qualify a claim, and an extra layer may hold a boundary. Judge the instance in front of you.
No deletion quota, no detector score, no punctuation ban, no compulsory stylistic change. Swapping one stock phrase for another, or chopping prose and flattening call graphs so the work looks done, fails the same way the original did.
The three parts
Load only the part the request needs:
references/writing.md— prose: messages, documents, reports, copy, pull request bodies.references/code.md— code: the touched implementation, its callers and its tests.references/design.md— interfaces, only for a project that has one: the rendered screen, its states, and the tokens and components behind it.
Prose judged against the live product belongs to the docs skill, a prompt to refine, a skill to authoring. A blocking review gap is repair work for the fix skill, not for this one.
Before you stop
Read the result once against the original. In prose, check numbers, named entities, degree of certainty and who said what. In code, run the checks that actually cover the changed behaviour and quote their exit codes.
Report what changed, the benefit each change bought, the checks you ran, and what you deliberately left alone and why. Never argue a change from the size of the diff: a shorter diff is not evidence of performance, correctness, or saved effort. Stop when the artifact serves its purpose instead of polishing it into a different voice or a different architecture.
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.

