agentleFS
Sign inStart free
ngctongcto/oh-my-pstack/skills/deslop/SKILL.md

deslop

Skill1 starsChanged 38 days agoMITView on GitHub

Remove AI-generated slop from a branch diff: noisy comments, abnormal defensive checks, `any` casts, deep nesting, style drift. Use for \"deslop\", \"clean up the AI code\", \"tidy this branch\", or before opening a PR and before review.

118 other projects use a version of this, 24 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use simple-issue-description, openseo-review-web-content and 7 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.
  • JwuthriSkill

    simple-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

  • JwuthriSkill

    openseo-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

  • learnerLjSkill

    verify-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

  • ten9876Skill

    papercuts

    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

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 116 edited versions we read keep these.

  • 5

    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
  1. Distinctive:

    After edits, run the project's own typecheck and tests.

    line 27
  2. Distinctive:

    Keep behavior unchanged unless fixing a clear bug.

    line 31
  3. Distinctive:

    Prefer minimal, focused edits over broad rewrites.

    line 32
  4. Distinctive:

    Run before thermos review, not after.

    line 33
  5. Distinctive:

    Keep the final summary to 1-3 sentences.

    line 34

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Remove AI code slop

Diff the branch against trunk and remove AI-generated slop it introduced. Behavior stays the same.

Scope

  • Base: the caller's scope spec. For a stack layer the base is its parent branch. With no spec, use git merge-base HEAD origin/HEAD, falling back to main/master. Review git diff <base>...HEAD plus uncommitted changes.
  • Touch only lines the branch added or changed. In a stack, never edit lines owned by lower layers.

Focus areas

  • Comments that restate code or clash with local style. When comment noise dominates the diff, run the no-comments skill first, then continue here.
  • Defensive checks or try/catch blocks that are abnormal for trusted code paths.
  • Casts to any used only to bypass type issues. Fix the type instead.
  • Deep nesting that early returns would flatten.
  • Anything else inconsistent with the file and its neighbors.

Tools

  • xd://lsp diagnostics find unused imports, needless casts, and type errors the cleanup exposes.
  • xd://ast_grep finds a slop pattern across the diff. xd://ast_edit rewrites it mechanically when the same shape repeats.
  • After edits, run the project's own typecheck and tests.

Guardrails

  • Keep behavior unchanged unless fixing a clear bug.
  • Prefer minimal, focused edits over broad rewrites.
  • Run before thermos review, not after.
  • Keep the final summary to 1-3 sentences.

Adapted from cursor-team-kit (MIT).

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free