prune-dev-clutter

name

prune-dev-clutter

description

Find and (on confirmation) remove the most common dev-environment space sinks on a Linux desktop — Python virtualenvs (.venv / venv / env), Node.js node_modules, Rust target/, Java target/build/, Go pkg/mod cache, Docker dangling images/volumes, and language-tool caches (pip, npm, yarn, pnpm cache). Prioritises stale ones (mtime > N days) and shows reclaimable bytes per category before any deletion. Triggers on "clean dev clutter", "prune venvs", "find old node_modules", "clear pip cache".

Prune Dev Clutter

The big offenders on dev workstations: hundreds of half-forgotten Python venvs, node_modules in every old experiment, multi-GiB Rust target/s. This skill finds them and quantifies reclaim before touching anything.

Inputs

1. Scope path — default ~. User can narrow (e.g. ~/repos, ~/projects).
2. Stale threshold — files not modified in N days qualify as stale. Default 90 days.
3. Categories — default: all. User can pick a subset.

Categories + scan

For each category, walk the scope path and find matches; report path + size + mtime + classification (active / stale).

Category	Match pattern	Tool
Python venvs	dir contains pyvenv.cfg	find <scope> -name pyvenv.cfg -printf '%h\n' 2>/dev/null then du -sh per dir
node_modules	dir name node_modules	find <scope> -type d -name node_modules -prune
Rust target/	sibling of Cargo.toml named target	find <scope> -name Cargo.toml then check sibling
Java/Gradle build/	sibling of build.gradle* named build	similar
Maven target/	sibling of pom.xml named target	similar
Go module cache	~/go/pkg/mod	du -sh ~/go/pkg/mod
Docker dangling	—	docker system df + docker image ls -f dangling=true
pip cache	~/.cache/pip	du -sh
npm cache	~/.npm	du -sh
yarn cache	~/.cache/yarn, ~/.yarn/cache	du -sh
pnpm store	~/.local/share/pnpm/store	du -sh (but note pnpm dedupes — this is shared across projects)
Hugging Face cache	~/.cache/huggingface	du -sh (warn: model re-downloads can be slow/expensive)
Conda envs	~/miniconda3/envs/*, ~/anaconda3/envs/*	per-env du -sh
Stale build dirs (generic)	build, dist, out next to a known project marker	report only, don't auto-delete

Active vs stale classification

For each candidate dir, get the mtime of the dir itself and the most recently modified file inside (recursively, capped at 1000 entries for speed). If both are older than N days → stale. Otherwise → active (don't suggest).

Exception: caches (~/.cache/pip, ~/.npm, etc.) are always candidates — they regenerate.

Report

Scope: /home/<user>  Stale threshold: 90 days

Reclaimable (stale):
  Python venvs        47 stale of 62   12.1 GiB
  node_modules        23 stale of 34    8.4 GiB
  Rust target/         5 stale of  9    6.7 GiB
  Java build/          3 stale of  4    1.2 GiB

Always-reclaimable caches:
  pip cache            2.3 GiB
  npm cache            1.8 GiB
  yarn cache           1.4 GiB
  Docker dangling     12.0 GiB (47 images, 8 volumes)

Total reclaimable: 45.9 GiB

Top 10 individual stale dirs:
  /home/<user>/repos/old-experiment-1/.venv        2.1 GiB   not touched 612 days
  /home/<user>/repos/some-project/node_modules     1.7 GiB   not touched 421 days
  ...

Apply (on confirmation only)

For each category the user picks:

• Venvs / node_modules / Rust target / Java build / Maven target: rm -rf per stale dir. Confirm once for the whole batch (showing the full list); not per dir.
• pip cache: pip cache purge.
• npm cache: npm cache clean --force.
• yarn cache: yarn cache clean.
• pnpm store: pnpm store prune.
• Hugging Face cache: ask first — re-download cost can be significant. Offer huggingface-cli scan-cache for selective cleanup.
• Docker dangling: docker system prune (images + volumes — warn about volumes!), or docker image prune for the safer subset.
• Conda envs: never auto-remove — list with conda env list and let the user pick conda env remove -n <name>.

Safety

• Confirm before any rm -rf. Show the full list.
• Never recurse into hidden top-level dirs without explicit scope (skip ~/.config, ~/.local unless explicitly included). Caches in ~/.cache are explicitly handled.
• Never touch anything inside .git/.
• For node_modules, after deletion suggest npm install / pnpm install / yarn install will rebuild them on next dev — they're not destroyed, just deferred.
• Save a manifest of what was deleted (path + size at time of delete) to <benchmarks_dir>/space-audits/prune-<timestamp>.json so the user can audit later.