terrylica/cc-skills/disk-hygiene

Claude Code and agent skill by terrylica/cc-skills

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

macOS disk cleanup, cache pruning, stale file detection, and Downloads triage. TRIGGERS - disk space, cleanup, disk usage

Install

npx vskill@latest install terrylica/cc-skills/disk-hygiene

SKILL.md

Disk Hygiene

Audit disk usage, clean developer caches, find forgotten large files, and triage Downloads on macOS.
Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.

When to Use This Skill

Use this skill when:

  • User asks about disk space, storage, or cleanup
  • System is running low on free space
  • User wants to find old/forgotten large files
  • User wants to clean developer caches (brew, uv, pip, npm, cargo)
  • User wants to triage their Downloads folder
  • User asks about disk analysis tools (dust, dua, gdu, ncdu)

TodoWrite Task Templates

Template A - Full Disk Audit
1. Run disk overview (df -h /System/Volumes/Data && major directories)
2. Audit developer caches (uv, brew, pip, npm, cargo, rustup, Docker)
3. Scan in-repo build artifacts (Rust target/, .venv, node_modules — often the biggest, see Phase 2.5)
4. Scan for forgotten large files (>50MB, not accessed in 180+ days)
5. Present findings with AskUserQuestion for cleanup choices
6. Execute selected cleanups
7. Report space reclaimed
Template B - Cache Cleanup Only
1. Measure current cache sizes
2. Run safe cache cleanups (brew, uv, pip, npm)
3. Report space reclaimed
Template C - Downloads Triage
1. List Downloads contents with dates and sizes
2. Categorize into groups (media, dev artifacts, personal docs, misc)
3. Present AskUserQuestion multi-select for deletion/move
4. Execute selected actions
Template D - Forgotten File Hunt
1. Scan home directory for large files not accessed in 180+ days
2. Group by location and type (media, ISOs, dev artifacts, documents)
3. Present findings sorted by size
4. Offer cleanup options via AskUserQuestion

Phase 1 - Disk Overview

Get the lay of the land before diving into specifics.

bash
/usr/bin/env bash << 'OVERVIEW_EOF'
echo "=== Disk Overview ==="
# MUST be /System/Volumes/Data, NOT `/`. On APFS (Catalina+) `/` is the SEALED
# READ-ONLY system volume and reports a fixed ~10GB used — it is not your disk.
# Verified 2026-07-31: `df -h /` said "10Gi used, 185Gi avail" on a machine that
# was actually 707GB used and 80% full. Reading `/` will make you conclude there
# is nothing to clean.
df -h /System/Volumes/Data
echo ""
echo "=== Major Directories ==="
du -sh ~/Library/Caches ~/Library/Logs ~/Library/Application\ Support \
~/.Trash ~/Downloads ~/Documents ~/Desktop ~/Movies ~/Music ~/Pictures \
2>/dev/null | sort -rh
echo ""
echo "=== Developer Tool Caches ==="
du -sh ~/.docker ~/.npm ~/.cargo ~/.rustup ~/.local ~/.cache \
~/.conda ~/.pyenv ~/.proto 2>/dev/null | sort -rh
OVERVIEW_EOF

Phase 2 - Cache Audit & Cleanup

Cache Size Reference
CacheLocationTypical SizeClean Command
uv~/Library/Caches/uv/ or `~/.cache/uv/`5-15 GBuv cache clean
Homebrew~/Library/Caches/Homebrew/3-10 GBbrew cleanup --prune=all
pip~/Library/Caches/pip/0.5-2 GBpip cache purge
npm~/.npm/_cacache/0.5-2 GBnpm cache clean --force
cargo~/.cargo/registry/cache/1-5 GBcargo cache -a (needs cargo-cache)
rustup~/.rustup/toolchains/2-10 GBrustup toolchain uninstall <name> (list with rustup toolchain list)
proto~/.proto/tools/<tool>/<version>/0.2-2 GB eachproto uninstall <tool> <version> (list with proto versions <tool> --installed), or proto clean tools
DockerDocker.app5-30 GBdocker system prune -a
Playwright~/Library/Caches/ms-playwright/0.5-2 GBnpx playwright uninstall
sccache~/Library/Caches/Mozilla.sccache/1-3 GBrm -rf ~/Library/Caches/Mozilla.sccache
go-build~/Library/Caches/go-build/5-25 GBgo clean -cache (or rm -rf if go not on PATH)
huggingface~/.cache/huggingface/1-10 GBrm -rf ~/.cache/huggingface/hub/<model>
Claude Code plugins~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/5-30 GBDelete versions not in ~/.claude/plugins/installed_plugins.json, keeping the 3 newest (sort -V) for already-running sessions
Safe Cleanup Commands (Always Re-downloadable)
bash
/usr/bin/env bash << 'CACHE_CLEAN_EOF'
set -euo pipefail
echo "=== Measuring current cache sizes ==="
echo "uv: $(du -sh ~/Library/Caches/uv/ 2>/dev/null | cut -f1 || echo 'N/A')"
echo "Homebrew: $(du -sh ~/Library/Caches/Homebrew/ 2>/dev/null | cut -f1 || echo 'N/A')"
echo "pip: $(du -sh ~/Library/Caches/pip/ 2>/dev/null | cut -f1 || echo 'N/A')"
echo "npm: $(du -sh ~/.npm/_cacache/ 2>/dev/null | cut -f1 || echo 'N/A')"
echo ""
echo "=== Cleaning ==="
brew cleanup --prune=all 2>&1 | tail -3
uv cache prune 2>&1 # prune, NOT `clean --force` — see "uv cache lock" below
pip cache purge 2>&1
npm cache clean --force 2>&1
CACHE_CLEAN_EOF
Troubleshooting Cache Cleanup
IssueCauseSolution
uv cache lock heldIdentify the holder firstSee "uv cache lock" below — --force can be actively dangerous
brew cleanup skips formulaeLinked but not latestSafe to ignore, or brew reinstall <pkg>
pip cache purge permission deniedSystem pip vs user pipUse python -m pip cache purge
Docker not runningDocker Desktop not startedStart Docker.app first, or skip
⚠️ uv cache lock — never reach for --force before naming the holder

uv cache clean waits 300 s for an exclusive lock, then errors. Earlier revisions of this skill said "use --force". That advice is wrong when the lock holder is a long-running service, and it is the same class of mistake as the api-gateway incident: mutating a cache underneath a live daemon.

Measured 2026-08-24: uv cache clean timed out, and the holders were

uv 1934 uv run python ~/code/search-svc/kernel/embed.py serve --model minishlab/potion-retrieval-32M
uv 2652 uv run python ~/code/search-svc/kernel/embed.py rerank --serve --model Xenova/ms-marco-MiniLM-L-6-v2

— both children of the launchd job `com.search-svc.serve`, up 1 h 37 m. These are persistent daemons, so the lock is never released and clean can never succeed on its own. Always identify the holder before deciding:

bash
lsof ~/.cache/uv/.lock 2>/dev/null # exact PIDs holding the lock
ps -o pid,ppid,lstart,command -p <PIDS> # how long, and whose child
launchctl list | grep -i <service> # is the parent a launchd job?

Then pick by holder:

HolderAction
Transient (uv sync you just ran)Wait for it, or --force — genuinely safe
Long-running launchd/daemonDo NOT `--force`. Either skip, or launchctl bootout → clean → bootstrap → verify
Unknown / can't identifySkip. The cache is never worth an outage

Prefer `uv cache prune` over `uv cache clean` in routine hygiene. prune removes only _unused_ entries and leaves everything a live environment depends on, so it is the correct periodic-maintenance verb; clean nukes everything and forces a full re-download.

uv archive-v0 silently accumulates whole virtual environments

The uv cache's headline number is misleading, so classify before you judge it. archive-v0 is documented as unpacked _wheel_ bodies that get hardlinked into each .venv — that part earns its keep. But it also accretes complete virtual environments (build envs / tool envs) that are never garbage-collected, and those are pure dead weight. Measured 2026-08-24 on a 69 GB uv cache:

Entry shapeCountSize
Full venvs (contain pyvenv.cfg)21039 GB
Genuine unpacked wheels1,57710 GB

So 78 % of archive-v0 was orphaned environments, not the dedup layer. Classify it — the split changes both the diagnosis and the remedy (prune, not clean):

bash
du -sk ~/.cache/uv/archive-v0/* 2>/dev/null > /tmp/uv-all.txt
while read -r kb path; do
[ -f "$path/pyvenv.cfg" ] && echo "VENV $((kb/1024))MB $path"
done < /tmp/uv-all.txt | sort -k2 -rn | head

Also check hardlink counts before promising a number. uv hardlinks cache files into live .venvs, so deleting a cache entry with links>1 reclaims _nothing_:

bash
stat -f 'links=%l size=%z %N' "$(find ~/.cache/uv/archive-v0 -type f -size +20M | head -1)"
# links=1 -> deleting truly reclaims; links>1 -> shared with a live venv, no gain

Don't let "Python is bloated" be the conclusion. In the same audit, Rust's per-repo target/ dirs totalled 57 GB against ~7 GB of Python .venvs — 8× more — because target/ is per-repo with no sharing while uv's archive is shared across every project. Report the measured split, not the folk wisdom.

Phase 2.5 - Project Build Artifacts (in-repo, regenerable)

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 95 of 100Pattern checks on the skill's files.
  • Model reviewPassed

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

Repository stars
62
Repository forks
10
7-day trend score
21

Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/terrylica/cc-skills/disk-hygiene/badge)](https://verified-skill.com/skills/terrylica/cc-skills/disk-hygiene)

Something wrong with this skill or its page? Tell us.