agentleFS
FirzusFirzus/agent-skills/skills/engineering/unslop/SKILL.md

unslop

Skill4 starsChanged 21 days agoMITView on GitHub

Audit a codebase for dead code and AI slop, clear each suspect against the legitimate reason it exists, and remove only what the evidence carries.

197 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use principle-never-block-on-the-human, greploop-apps 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.
  • jaydubya818Skill

    principle-never-block-on-the-human

    Apply when safe reversible implementation details can proceed inside scope.

    Also in 45 projects that use this

  • jaydubya818Skill

    greploop-apps

    Run greploop through @greptile-apps when the normal trigger rejects a large PR. Use only with the companion greploop skill.

    Also in 5 projects that use this

  • ianclearySkill

    principle-explain-the-number

    Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.

    Also in 30 projects that use this

  • bnemaSkill

    setup-pstack

    Configure which Pi models pstack uses per role. Detects available provider/model specs and writes pstack's user configuration. Use for /setup-pstack, "configure pstack models", or changing pstack model choices.

    Also in 26 projects that use this

  • ianclearySkill

    poteto-help

    Guides users through pstack setup, /poteto-mode, and picking the skill, playbook, or principle for a task. Type /poteto-help with a question.

    Also in 15 projects that use this

  • +7 more from jaydubya818

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 9 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 193 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep them apart at every stage.

    line 19
  2. Distinctive:

    Authorship is not the defect: No detector of LLM-written source exists, and every pattern in this skill is abundantly present in …

    line 34
  3. Distinctive:

    Only candidates reach the proposal.

    line 46
  4. Very specific:

    Read signals.md and collect suspects against it.

    line 87
  5. Distinctive:

    Run whatever the repository already has before installing anything: its linter, its compiler warnings, its analyzers, its coverage.

    line 92
  6. Distinctive:

    Done when: every suspect carries its signal, its detection command, and its evidence grade.

    line 103
  7. Very specific:

    Search the symbol as a bare string literal across the whole repository, including untracked and ignored files, data, config, templates, and …

    line 116
  8. Very specific:

    Search the mechanism, not the symbol: getattr(, importlib, Class.forName, Type.GetType, Activator.CreateInstance, obj[name], .send(, DI …

    line 119
  9. Distinctive:

    Done when: every suspect is either dismissed with the exoneration that cleared it, or promoted to a candidate carrying: files, signal, what …

    line 128
  10. Distinctive:

    When commits are authorized, land each logical deletion as its own commit, with a message recording which searches ran and what they …

    line 163
  11. Distinctive:

    Verify from the main thread before reporting a candidate done: re-read the diff, re-run the build and tests, and confirm the scope held.

    line 174
  12. Distinctive:

    Done when: every approved candidate meets its verification and agreed delivery conditions, and the closing message gives a one-line outcome …

    line 179

“Common” is measured: kept by at least 6 in 10 of the 193 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

Unslop

Find code that should not exist, dead code that no longer runs and slop that runs and earns nothing, then prove each candidate before touching it. A run proposes a ranked list of candidates in the conversation, with the evidence attached; removal follows the user's approval, one deletion per commit.

Two problems, two epistemics

Keep them apart at every stage. Auditing them in one pass is the error that produces confident wrong deletions.

Dead codeSlop
QuestionIs this reachable?Should this exist in this form?
Decided byReference graphs, call graphs, runtime evidenceReading the code
CoreDecidable, with documented blind spotsNo decidable core
Terminates inA removal backed by evidenceA ranked proposal for a human

No tool decides deadness. Each one decides a decidable approximation of it, and the identity of that approximation, never the tool's confidence score, determines whether removal is safe. Perfect detection reduces to the halting problem, so every tool is either unsound for deletion or incomplete.

Authorship is not the defect. No detector of LLM-written source exists, and every pattern in this skill is abundantly present in human-written code. Report the defect and the rule it violates; leave authorship out of the finding.

Vocabulary

  • A suspect is a raw tool hit or a read observation. It is not yet a finding.
  • To exonerate a suspect is to find the legitimate mechanism that keeps it alive or earns its shape. Every signal has an exoneration list, and clearing that list is the whole work of the audit.
  • A candidate is a suspect whose exonerations were checked and none applied. Only candidates reach the proposal.
  • The root set is the declared entry points reachability is measured from. "Unreachable" is a function of the root set, so it is a configuration artifact, not a property of the code.
  • Blast radius is what breaks if the candidate was alive after all, and whether that break is loud (a failing build) or silent (a runtime failure on a rare path, months later).

1. Scope

Three decisions, made before any tool runs, because each one changes what the output means.

Closed world or open world. In a closed world (application, service, game) every entry point lives in the repo or its deploy config, and an unreferenced symbol is a candidate. In an open world (library, SDK, plugin, published package) the exported surface is the product: zero in-repo callers is the expected state of the entire public API, and a reachability tool measures nothing but the density of its own examples. A monorepo is open-world per published package boundary. Establish this first; it changes the answer more than any tool setting.

The root set, written down. Enumerate every entry point before scanning: package.json bin and scripts, [project.scripts], [[bin]], Dockerfile CMD/ENTRYPOINT, CI workflows, Terraform and Kubernetes manifests, serverless handlers, crontabs, route and task decorators, test discovery roots. A missing entry does not produce one false positive: it cascades, and every file it reaches, every export in those files, and every dependency only they used all report as dead.

Exclusions and reach. Generated output and its input schemas, vendored and third-party trees, and test trees leave the reachability query. Then choose the reach: a diff-scoped audit has an owner for every finding, while a repo-wide audit produces hundreds of ownerless ones. Prefer the diff, and weight the rest toward code that keeps changing.

Done when a scope note names the world, lists the root set, and lists the excluded trees.

2. Detect

Read signals.md and collect suspects against it. It carries the signal table (detection procedure, what a hit proves, the exoneration list, and the evidence grade) plus what each detector is structurally unable to see.

Run whatever the repository already has before installing anything: its linter, its compiler warnings, its analyzers, its coverage. Record the exact command and configuration next to every hit, because a finding is only ever "unused within the set I analyzed."

Alongside the tools, read for the shapes no tool encodes: a wrapper that only forwards, a second implementation of an existing repository utility, a path left wired after a mid-task change of approach, a test whose assertions touch only mocks. These are where slop concentrates, and compilers report none of them.

Done when every suspect carries its signal, its detection command, and its evidence grade.

3. Exonerate

The heart of the audit. Read false-positives.md and work each suspect against it: twelve mechanisms that keep statically unreferenced code alive, each with the grep recipe that finds it and the check that clears it. Unity and C# have their own section there, because engine wiring defeats .NET static reachability in ways no analyzer reports.

Two moves carry most of the weight, and both are free:

  • Search the symbol as a bare string literal across the whole repository, including untracked and ignored files, data, config, templates, and serialized assets: git grep --untracked --no-exclude-standard 'Symbol'.
  • Search the mechanism, not the symbol: getattr(, importlib, Class.forName, Type.GetType, Activator.CreateInstance, obj[name], .send(, DI registrations, assembly scans. A name assembled at runtime from a prefix and a variable is unresolvable statically, and that ends the enquiry.

Grade what survives. A and B signals may carry a removal proposal. C signals produce a question for the author. D signals, anything resting on tone or style, are mentioned at most, never acted on.

Done when every suspect is either dismissed with the exoneration that cleared it, or promoted to a candidate carrying: files, signal, what the signal proves, the exonerations checked, evidence grade, and blast radius with its loud/silent classification. A candidate that does not name the exonerations it cleared is not a finding.

4. Present

Present the candidates directly in the conversation as a numbered list, in the user's language and the project's domain vocabulary. Order them by evidence grade, then by blast radius ascending, so the cheapest and safest work reads first. Give each candidate a short title and:

  • Files: the exact locations.
  • Signal: what fired, with the command that produced it.
  • Proves: the bounded claim the signal supports.
  • Cleared: the exonerations checked and why none applied.
  • Blast radius: what breaks if this was alive, loud or silent.
  • Verdict: Remove, Consolidate, Migrate, or Ask.

Duplication is a Consolidate verdict, never a Remove: extract the shared behaviour, redirect every call site, and the originals then become ordinary unreferenced symbols with established provenance. A superseded implementation still serving traffic is Migrate: an incomplete migration, not a deletion.

End with a Top recommendation, then ask the user which numbered candidates to apply. Work starts only on the candidates the user accepts.

5. Remove

For each accepted candidate, read deletion.md and climb its verification ladder until the evidence matches the blast radius. Rungs 1 to 4 are free and offline; run all four every time. Public surface switches the work to a deprecation cycle, which the audit proposes rather than performs.

When commits are authorized, land each logical deletion as its own commit, with a message recording which searches ran and what they returned. Without commit authorization, preserve the local changes and verification evidence; report Git delivery as pending rather than committing or discarding the work. Preserve a recoverable copy of any uncommitted content before removal.

Independent candidates with disjoint files may run as parallel sub-agents, each given the candidate's evidence, the ladder rungs required, and the instruction that everything outside its files is out of bounds. Overlapping scopes run in sequence.

Verify from the main thread before reporting a candidate done: re-read the diff, re-run the build and tests, and confirm the scope held. Failed checks, scope drift, or pending required delivery leave the candidate open with its reason; re-dispatch within scope or surface the decision.

Done when every approved candidate meets its verification and agreed delivery conditions, and the closing message gives a one-line outcome per numbered candidate. Otherwise report partial completion and the unresolved blockers; recording a blocker does not complete the candidate.

Standing guardrails

  • Trust boundaries are protected. Validation, authorization, error handling that prevents data loss, and accessibility affordances stay, however redundant they look. The same null check is noise in a private helper and mandatory at a process, network, file, plugin, or FFI edge.
  • Deprecation, compatibility, migration, rollback, and disaster-recovery paths stay until a dated statement says the window closed. They are the highest-cost false positives: silent at build time, silent in tests, and catastrophic on the one day they were written for.
  • Generated output and vendored trees stay. Reduce them at the schema or the dependency, or leave them alone.
  • Baseline against the repository. Churn, comment density, duplication, and function length are interpretable only as percentiles of the surrounding code.

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.