Give ~/projects a checkup: which projects are asleep and should be archived, which directories are rebuildable build artifacts that should be cleared to free up space. Produce adisposition list, and only act after you have circled and confirmed your selections.
This discipline comes from a real project cleanup: a dozen-plus projects put in place by category, several discontinued lines archived into _archive/ with an archive record left for each stating the reason for discontinuation and the date. This skill is about solidifying that manual cleanup into a reusable process, and welding the risk of "almost deleted by mistake" firmly behind the confirmation gate.
Usage
/ray-cleanup # 全量扫 ~/projects,出处置清单
/ray-cleanup net # 只扫某个类别目录
/ray-cleanup ~/projects/apps/foo # 只体检单个项目
/ray-cleanup --slim # 只找可删的构建产物(不碰项目归档)
Highest discipline: must stop before destructive operations
This is the reason this skill exists, and it ranks above all efficiency:
- List first, act later. Before any
rm/mv, list the complete inventory: each item'spath + size + disposition action + basis. Execute only after the user confirms item by item or circles selections. No nod = no action. - Archiving is the default, deletion is the exception. When unsure, archive (reversible), don't delete (irreversible). Deletion holds only for the one case of "user explicitly nods + it is indeed a rebuildable build artifact".
- Never delete non-build artifacts. Source code, data, config, keys,
.env、.git—none of these ever go on the deletion list. Even if the user says "just delete them all", pull such targets out separately and restate them for confirmation; do not delete them along with build artifacts. - Before acting, take a look at whether the target matches its name. A directory called
node_modulesmust actually look like a dependency directory; a repo "with no commits for three months" must be confirmed before archiving that it is not a running production service. If anomalies are found (source code mixed into the target, suspected online assets, uncommitted changes), report first, don't act.
To judge "what can be deleted, what must not be touched", consult references/safe-to-delete.md(whitelist + blacklist).
Step 1: Scan candidates
For each project repo within the target scope, collect two signals in parallel:
1a. How long it has been untouched (git last-commit)
git -C "<项目>" log -1 --format='%cr | %cd' --date=short 2>/dev/null
If unavailable (non-git repo), fall back to file mtime:ls -lt "<项目>" | head -3。
1b. How much disk it takes up
du -sh "<项目>" 2>/dev/null
# 找项目内的大头目录:
du -sh "<项目>"/{node_modules,.next,dist,build,target,.venv} 2>/dev/null
Summarize into a raw table: project · category · last-commit · total size · details of big directories. First show the user thisread-onlycurrent-state table, without any disposition actions—let them get a sense of the "family assets", then proceed to classification.
Step 2: Classify and give recommendations
Each project falls into one of three tiers,and each tier must state its basis clearly, not just a conclusion:
| Tier | Criteria | Default action |
|---|---|---|
| 🟢 Keep | Still active (commits within the last 3 months) / has value signals (see below) | No action. Optional: clear its build artifacts to slim down |
| 🟡 Archive | 3+ months untouched + no value signals + indeed a discontinued line | mv into _archive/ + leave an archive record |
| 🔵 Deletable | Pure build artifacts / cache; deleting them can be rebuilt with one command | Add to the deletion list pending confirmation |
Value signals (hitting any one → no mechanical archiving allowed; mark 🟢 or at least report first):
- Has paying customers / a business running in production (e.g. an API service that is still charging)
- An already-deployed live site (has a production domain, Vercel/server serving it)
- Infrastructure configuration / credentials / "source of truth" repos (e.g. a source-of-truth repo for some hosted configuration, a proxy/node subscription repo, a repo holding node credentials)
- Something else symlinks to it or depends on it (touching it will break things in a chain)
Low commit frequency ≠ dormant. A configuration repo may change only once every few months yet be a production lifeline. So the confirmation gate in Step 3 is mandatory for projects that are "suspected dormant but possibly important"—see below.
Step 3: Confirmation gate (cannot be skipped)
Organize the Step 2 suggestions into adisposition checklistfor the user to select from:
拟处置清单(逐项确认,未勾选=不动)
──────────────────────────────────────────────────────────
[ ] 🟡 归档 ~/projects/apps/old-blog 420M 末次提交 5 月前,这条线已停
[ ] 🟡 归档 ~/projects/lab/experiment-x 1.2G 末次提交 4 月前,实验结束
[ ] 🔵 删除 .../webapp/node_modules 890M 构建产物,pnpm i 可重建
[ ] 🔵 删除 .../site/.next 210M 构建缓存,next build 可重建
[ ] ⚠️ 待核 ~/projects/net/edge-config 3M 5 月没动,但疑似线上真源→请确认
──────────────────────────────────────────────────────────
合计:归档 1.6G,删除 1.1G,待核 1 项
Rules:
- ⚠️ To be verified For things like this (suspected dormant but hitting or possibly hitting a value signal), always lay them out and ask first; never take it upon yourself to archive or delete. Better to miss archiving than to accidentally harm a production asset.
- Only do what the user has selected. For anything not selected or with ambiguous wording ("just clean up whatever"), go back and confirm the specific items; do not expand execution.
- Before executing, for each checked itemtake another lookat whether the target matches its name in reality (Step "Highest Discipline" item 4).
Step 4: Execute
Archive (🟡): Move the project into _archive/ and leave a record of "why it was archived and when." For the specific directory conventions, what the archive record should contain, and how to handle git and symlinks, check references/archive-protocol.md—follow it; don't invent your own format. Archiving is reversible, but you must first confirm there are no uncommitted changes (if there are, remind the user to commit or explicitly give them up).
Slimming (🔵): Only delete references/safe-to-delete.md rebuildable directories in the whitelist. Before deleting, make one final confirmation that the project currently has no running dev server (deleting a node_modules in use will interrupt the process). After deleting, report how much space was actually freed.
Step 5: Wrap up
- Account: how many projects were archived, how much disk space was freed, and which ⚠️ To be verified items remain for the user to decide.
- If the archiving action is worth recording in long-term memory (such as shutting down a business line), prompt the user to add a note in memory, so the reason for archiving doesn't just sit in
_archive. - At any step in the process, if the user has not explicitly nodded, stop there and wait; don't guess, don't do it on their behalf, and don't "conveniently" delete one extra item.