deslop
Skill1 starsChanged 3 months agoMITView on GitHub
Cut over-explained and AI-sounding prose from drafts, comments, docs, PR bodies, and Slack or Jira text before finalizing them. Use when drafting or editing these texts. Apply local edits when allowed; in plan or review mode, or for outbound text, propose changes without applying them.
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 · 0
None found.
Edited · 0
None found.
Wrote their own version · 118
- 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
108 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 repository4 other files it gives its agents.
- better-documentsSkill
- vet-planSkill
- vet-reviewSkill
- vet-testsSkill
The file
We split this skill into the rules it gives an agent
10 rules. 0 are common, 8 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 116 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
The cut test. Delete is the default, not rewrite: If it can be figured out by reading the code, delete it.
- Distinctive: line 34
Mechanical tells: Check every time, before reading for anything else.
- Distinctive: line 44
Do not use the word flying blind or blind to describe something
- Distinctive: line 60
Judgment tells: Read for these.
- Distinctive: line 108
Hands off: no logic changes, no test changes, no new comments, no rewording that shifts meaning, nothing outside scope.
- Very specific: line 112
Do not run gh pr edit, gh pr comment, gh api with a write method, updateConfluencePage, editJiraIssue, slack_send_message, or …
- Distinctive: line 118
Do not edit them during this pass.
- Very specific: line 122
Cut: - only edits actually applied: <file>:<line> - "<first few words>" -> <one-word reason>
- Distinctive: line 124
Kept: - only the genuinely borderline ones, same format plus why it survived.
- Distinctive: line 130
Keep the report tight. No preamble, no summary.
“Common” is measured: kept by at least 6 in 10 of the 116 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
Cut the AI-sounding prose out of what was just written. Apply local edits when allowed. In plan or review mode, or for outbound text, propose changes without applying them.
Scope, in order: prose written this session, then the current change, then the branch's open PR. Stay on files related to the current ticket, not the whole diff.
The cut test. Delete is the default, not rewrite. If it can be figured out by reading the code, delete it. The comment goes, the doc section goes, the file goes. Rewriting an inferable comment into a tighter inferable comment is the failure this exists to prevent. Only a non-obvious WHY or a hidden constraint survives, and shortening comes after, in the trim pass below.
For prose generally: does this carry information a reader cannot get from the thing it describes, or is it performing?
Trim survivors clause by clause. Passing the cut test earns a sentence its place, not its length. Cut:
- Restatement: two sentences carrying one fact keep the more concrete one
- Detail the artifact already shows, like a parameter's valid values
- Steps the remaining steps imply: "open a PR and merge to main" is "merge to main"
- Clauses that are true but off-point where they sit
Mechanical tells. Check every time, before reading for anything else.
- Em dashes, anywhere
- "lands" and "lands in" - use "shows up in" or "goes to"
- Walls of text. Break them up.
--as a separator becomes-- Jira keys like
ABC-1234as a comment prefix. State the why without the key. A key doing real work stays, like a TODO naming the ticket that tracks its removal. When unsure, flag instead of cutting. - "kill switch" in audience-facing text - use "on/off toggle"
- Do not use the word flying blind or blind to describe something
- AI vocabulary: crucially, delve, interplay, pivotal, tapestry, testament, seamless, robust, leverage, load-bearing, load bearing - plain equivalents
- Inflated copulas: "serves as", "stands as", "boasts", "features" - "is"/"has"
- Verbose phrases and filler words: "in order to" - "to", "due to the fact that" - "because", "utilize" - "use"
- Curly quotes - straight quotes
- Title Case Headings - sentence case, unless the surrounding document already established Title Case as its own heading convention (an existing README, Confluence page, or PR template with consistent Title Case headings throughout); match what's there instead of introducing a mismatched style
- Bold scattered inside sentences for emphasis (structural bold, meaning a lead phrase, a label, or a key figure, stays)
- Repeated or performative colon connectors, not ordinary explanatory colons or colons that are just syntax (URLs, timestamps, labels, code)
Judgment tells. Read for these.
- Punchy sentence fragments for rhetorical effect
- Victory-lap framing that explains why a result is impressive
- Closers that tie a bow on the thesis. End on the fact.
- Escalating three-clause builds
- Instructional voice where past-tense first person fits: "I used a scratch thread", not "Use a scratch thread"
- Stock openers and filler: "Good point", "turns out", "just to clarify", "essentially". No bullet recap, no closing summary.
- Step-by-step privilege-escalation chains. Keep the decision and the control.
- Hollow -ing phrases: "highlighting", "ensuring", "showcasing" - delete or state the actual mechanism
- Puffery: "pivotal moment", "evolving landscape" - cut, state facts
- "Not just X, but Y" - state the point directly
- Synonym cycling: same thing called three different names - pick one, repeat it
- Over-hedging: "could potentially possibly" - "may"
- Passive voice where the actor is knowable: "queries are validated" - "the compiler validates queries"
- Weak verb + adverb: "runs quickly" - cut the vague adverb and state what actually makes it fast, or cite a number. ("is fast" alone just trades one unsupported claim for another.)
- Feelings-over-mechanism: describe the actual function or cut
- Abstract metaphor nouns: substrate, wedge, vector, nexus, endgame, flywheel - concrete terms. Exclude "harness" from this list, since it's a legitimate term in AI agent contexts (agent harness), flagging it would produce false positives.
- Header-restating lists:
**Performance:** Performance improved...- convert to prose or fix the lead
Keep the courtesies. In outbound messages, scope-lock the content but leave the professional norms: OOO disclosure, greetings, acknowledgments. Cut the padding around a courtesy, never the courtesy.
Keep the substance. Data tables and enumerable lists are data presentation, not slop. Short sentences are not slop, only telegraphic fragments or symbol-chain formulas are. Established domain terms, identifiers, quoted text, and this repo's own terminology are preserved even when they appear on the AI-vocabulary or abstract-metaphor-noun lists above, those lists flag candidates for a second look, not an automatic find-and-replace.
Syntax. Multi-line comments collapse to one /* */ block, never stacked //. In
#-comment languages the fix is fewer and shorter lines.
Markdown. Cut the preamble when the first real section already orients, and cut the closing summary.
Nothing to cut is a valid result. Say so in one line and stop.
Hands off: no logic changes, no test changes, no new comments, no rewording that shifts meaning, nothing outside scope. In plan or review mode, return proposed cuts or rewrites without editing files.
Do not run gh pr edit, gh pr comment, gh api with a write method,
updateConfluencePage, editJiraIssue, slack_send_message, or
slack_update_canvas during a pass. Approval is per-action and per-surface, and does
not carry to the next invocation. Local file edits need no gate.
For Jira comments and already-sent Slack messages, provide proposed text to paste. Do not edit them during this pass.
Then report exactly this, and nothing extra:
Cut - only edits actually applied: <file>:<line> - "<first few words>" -> <one-word reason>
Kept - only the genuinely borderline ones, same format plus why it survived.
Proposed - outbound text or changes withheld in plan or review mode. Give each proposed cut or rewrite with its location and how to apply it. Do not apply any of them in this turn.
Keep the report tight. No preamble, no summary.
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.

