agentleFS
rafaelobrafaelob/pragmatic-agent-skills/skills/kill-slop/SKILL.md

kill-slop

Skill23 starsChanged 8 days agoApache-2.0View on GitHub

Use to remove unneeded code, dependencies, abstractions or dead code, with proof; keep behavior. Not repo junk files. Module shape -> codebase-design. Trade-off -> pragmatic-engineering. PR review -> code-review.

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 6 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    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
  1. Very specific:

    Run the finder from the project's declared dev dependencies and manager (uv run, npm run/pnpm exec).

    line 49
  2. Very specific:

    Check before deleting: dynamic dispatch/reflection (getattr, registries, plugin entry points), CLI/HTTP route registration, pytest …

    line 50
  3. Distinctive:

    Delete in small commits, each carrying the finder output plus the tests as evidence.

    line 51
  4. Distinctive:

    Default to minimal. If the user explicitly asks for more structure, obey that request.

    line 63
  5. Distinctive:

    Do not override an explicit ask in the name of kill-slop.

    line 65
  6. Distinctive:

    If only (2) is true, do not split.

    line 77
  7. Distinctive:

    Before writing, name the goal (one sentence), the touch list (files the asked result actually needs) and what you will not do.

    line 81
  8. Distinctive:

    When summarizing, say what you changed and what you deliberately did not change.

    line 94

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “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

Kill slop

Force a minimal, merge-ready diff. Prefer the smallest change that fully solves the stated task. Junk files in the repo (logs, scratch, stale artifacts) are out of scope: that is exhaustive-repo-cleanup-audit.

Dead-code finders

Run the finders on the diff's files; go repo-wide only on an explicit "remove dead code" request. Delete only code proven dead: no hit from git grep -n --untracked (or rg -F --hidden --no-ignore-vcs -g '!.git') across the repo, config, .github/, entrypoints and registrations, and the tests stay green after the deletion. A finder nominates; it never authorizes "delete everything flagged."

  • Python: ruff check --select F401,F811,F841,ERA001, then vulture <src> --min-confidence 80; whitelist proven false positives in a file, never inline.
  • TypeScript/JavaScript: knip (unused files, exports, dependencies); tsc --noEmit with noUnusedLocals/noUnusedParameters when the project enables them. Use the ecosystem's own equivalent elsewhere.
  • Run the finder from the project's declared dev dependencies and manager (uv run, npm run/pnpm exec); never a uvx/npx/dlx stand-in — propose adding a missing one.
  • Check before deleting: dynamic dispatch/reflection (getattr, registries, plugin entry points), CLI/HTTP route registration, pytest fixtures/conftest, __all__/public re-exports, framework hooks/templates/serialization/ORM fields, and any installed or vendored payload that a generator or installer owns.
  • Delete in small commits, each carrying the finder output plus the tests as evidence.
  • A versioned sibling of a live file, function or doc (x_v2, -new, -final, PLANO_V3) is merged into one and the rest deleted; git keeps the history. Keep a version only when it is part of an external contract (API path, schema, migration, model ID, release).
  • Removing a path takes what only it used: its flags, modes, aliases, fallbacks, state, permissions and config. Verify the surviving flow, including what the deleted path assumed about navigation, permissions or persisted data.

Boundary with codebase-design

This skill answers one question about code that exists: is this unneeded, and can I prove it? It removes what is proven unneeded and leaves the design alone. codebase-design answers a different one: what shape should a module's interface and seams have, and should a shallow module be deleted, inlined or deepened? That is a design judgment, made by the deletion test and the evidence for a seam, never by a size threshold.

Hand off both ways. When this skill meets a wrapper or layer whose value is a design question, ask codebase-design for the verdict; when codebase-design decides a module goes, the deletion comes back here and needs this skill's proof (finder output, repo-wide search, tests green).

User intent wins

Default to minimal. If the user explicitly asks for more structure, obey that request.

Do not override an explicit ask in the name of kill-slop. If the ask is ambiguous, prefer minimal and say what you skipped.

File shape

Default: colocate. Edit the file/folder that already owns this concern.

Split only when ALL of these hold:

  1. Pain now — the file is already hard to navigate or mixes unrelated concerns and your change would make it worse
  2. One unit — you are extracting a single cohesive piece with a clear name
  3. Local fit — the new file follows an existing nearby pattern. If there is no pattern, colocate beside the caller

If only (2) is true, do not split.

Diff against the asked result

Before writing, name the goal (one sentence), the touch list (files the asked result actually needs) and what you will not do. An extra file or a one-use helper is justified by the problem, not by a file count — there is no fixed file budget.

Checker (diagnostic, no veto)

The bundled checker is optional diagnosis, never a gate. Read scripts/check_diff.py for flags. OVER_BUDGET is information; it does not forbid finishing. SKIP / EMPTY_SCAN means the scan failed — report that, do not treat unknown as clean.

python -X utf8 <path-to-this-skill>/scripts/check_diff.py
python -X utf8 <path-to-this-skill>/scripts/check_diff.py --base HEAD

Output

When summarizing, say what you changed and what you deliberately did not change.

Attribution

Adapted from iCodeCraft/anti-slop (MIT), skill kill-slop.

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.