ray-cleanup

name	ray-cleanup
description	项目归档与磁盘瘦身。扫 ~/projects 各仓的 last-commit 时间和磁盘占用,找出 3+ 月没动的沉睡项目和 node_modules/.next 这类大头,分类给出「归档/可删/保留」建议,并按既定归档纪律执行。核心是安全——任何 rm/mv 之前先列完整清单(路径+大小+动作)让你逐项点头,绝不自动删、绝不删源码/数据/配置。当你说「归档沉睡项目」「清 node_modules 瘦身」「整理 projects 目录」「磁盘满了清一清」时使用。不用于:删除数据库/生产数据(那不是清理是运维);清理别人的目录或系统目录;把「删除」当默认动作(默认是归档)。

ray-cleanup:项目归档与瘦身

给 ~/projects 做一次体检:哪些项目睡着了该归档、哪些目录是可重建的构建产物该清掉腾空间。产出一张处置清单,你圈选确认后再动手。

这条纪律来自一次真实的项目整理:十几个项目按类别归位、几条已停的线归档进 _archive/ 并各留一份归档记录写清停用原因和日期。这个 skill 就是把那次手动整理固化成可复用流程,并且把「差点误删」的风险焊死在确认门后面。

用法

/ray-cleanup              # 全量扫 ~/projects,出处置清单
/ray-cleanup net          # 只扫某个类别目录
/ray-cleanup ~/projects/apps/foo        # 只体检单个项目
/ray-cleanup --slim       # 只找可删的构建产物(不碰项目归档)

最高纪律:破坏性操作前必须停

这是本 skill 存在的理由,排在所有效率之前:

• 先清单,后动手。 任何 rm / mv 之前,列出完整清单:每一项的路径 + 大小 + 处置动作 + 依据。等用户逐项确认或圈选后才执行。没点头 = 不动。
• 归档是默认,删除是例外。 拿不准就归档(可逆),不删(不可逆)。删除只对「用户明确点头 + 确属可重建构建产物」这一种情况成立。
• 绝不删非构建产物。 源码、数据、配置、密钥、.env、.git——这些一律不进删除清单。就算用户嘴上说「都删了吧」,也要把这类目标单独拎出来复述确认,不跟着构建产物一起删。
• 动手前看一眼目标是否名实相符。 一个叫 node_modules 的目录要真的长得像依赖目录;一个「三个月没提交」的仓在归档前要确认它不是正在跑的生产服务。发现异常(目标里混着源码、疑似线上资产、有未提交改动)先报告,不动手。

判断「什么能删、什么碰都不碰」查 references/safe-to-delete.md(白名单 + 黑名单)。

Step 1:扫候选

对目标范围内每个项目仓,并行采两个信号:

1a. 有多久没动(git last-commit)

git -C "<项目>" log -1 --format='%cr | %cd' --date=short 2>/dev/null

拿不到(非 git 仓)就退回看文件 mtime:ls -lt "<项目>" | head -3。

1b. 磁盘占多大

du -sh "<项目>" 2>/dev/null
# 找项目内的大头目录:
du -sh "<项目>"/{node_modules,.next,dist,build,target,.venv} 2>/dev/null

汇总成一张原始表:项目 · 类别 · last-commit · 总大小 · 大头目录明细。先给用户看这张只读的现状表,不带任何处置动作——让他对「家底」有数,再往下分类。

Step 2:分类给建议

每个项目落到三档之一,每一档都要写清依据,不能只给结论:

档	判据	默认动作
🟢 保留	仍活跃(近 3 月有提交)/ 有价值信号(见下)	不动。可选:清它的构建产物瘦身
🟡 归档	3+ 月没动 + 无价值信号 + 确属停掉的线	mv 进 _archive/ + 留归档记录
🔵 可删	纯构建产物 / 缓存,删了能一条命令重建	列进删除清单待确认

价值信号(命中任一 → 不许机械归档,标 🟢 或至少先报告):

• 有付费客户 / 线上跑着的业务(如一个还在收费的 API 服务)
• 已部署的线上站(有生产域名、Vercel/服务器在服务)
• 基础设施配置 / 凭证 / 「真源」仓(如某个托管配置的真源仓、代理/节点订阅仓、装着节点凭证的仓)
• 别的东西软链或依赖它(动了会连带断)

低提交频率 ≠ 沉睡。 一个配置仓可能几个月才改一次却是线上命脉。所以第 3 步的确认门对「疑似沉睡但可能重要」的项目是硬性的——见下。

Step 3:确认门(不可跳过)

把 Step 2 的建议整理成一张处置清单给用户圈选:

拟处置清单(逐项确认,未勾选=不动)
──────────────────────────────────────────────────────────
[ ] 🟡 归档  ~/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 项

规则:

• ⚠️ 待核 这类(疑似沉睡但命中或可能命中价值信号)一律先摆出来问,绝不自作主张归档或删。宁可漏归档,不可误伤线上资产。
• 用户圈了哪些就只做哪些。没圈的、语义含糊的(「随便清清」),回去确认具体项,不扩大执行。
• 执行前对每个勾选项再看一眼目标是否名实相符(Step「最高纪律」第 4 条)。

Step 4:执行

归档(🟡): 把项目移进 _archive/ 并留下「为什么归档、什么时候归的」的记录。具体的目录规范、归档记录该写什么、git 和软链怎么处理,查 references/archive-protocol.md——照它做,别自己发明格式。归档是可逆的,但也要先确认没有未提交改动(有就先提醒用户 commit 或明确放弃)。

瘦身(🔵): 只删 references/safe-to-delete.md 白名单里的可重建目录。删前最后确认该项目此刻没有跑着的 dev server(删正在用的 node_modules 会打断进程)。删完报一句实际释放了多少空间。

Step 5:收尾

• 报账:归档了几个项目、释放了多少磁盘、还剩哪些 ⚠️ 待核项等用户定夺。
• 如果归档动作值得记进长期记忆(停掉一条业务线这种),提示用户在记忆里补一笔,别让归档理由只躺在 _archive 里。
• 全程哪一步只要用户没明确点头,就停在那里等,不猜、不代劳、不「顺手」多删一个。