失效Skill清理师

插件库为什么会"腐烂"

随着 AI 客户端（Claude、Cursor、WorkBuddy 等）里装的技能越来越多，一个现实问题逐渐浮现：有些技能已经悄悄失效了，却没人发现。 依赖的 Python 包被卸载了、调用的 MCP 服务下线了、脚本路径变了——这些技能还躺在目录里，一旦触发只会报错，反而拖慢上下文。更隐蔽的是功能重叠：你可能同时装了两个做相似任务的技能，其中一个早已不再维护。手动排查几十个技能目录既费时又容易遗漏。

它如何工作

失效Skill清理师 是一个只读优先的清理工具，核心流程分五步：

1. 遍历技能目录：扫描 ~/.claude/skills/、~/.cursor/skills/、~/.workbuddy/skills/ 等常见路径，列出全部已装 Skill。
2. 采集三类证据：依赖完整性（脚本、MCP、命令、Python 包是否还存在）、运行痕迹（调用日志中是否报错或零调用）、同类重叠（功能是否被更优技能覆盖）。
3. 加权评分：按"依赖缺失 > 频繁报错 > 零调用超阈值 > 有更优替代"的权重打分，分为「健康 / 建议归档 / 建议停用」三档。
4. 生成清单：输出带证据和风险等级的报告，扫描阶段绝不触碰任何文件。
5. 确认后执行：仅在你明确确认后，才做"软归档"（移入 历史版本/归档/ 子目录，可随时还原）或设置 disable: true。删除操作被完全禁止，彻底移除由你手动处理。

适用边界与注意点

• 零调用 ≠ 失效：低频但关键时刻有用的技能（如年度税报）应判为健康。工具会综合"最近一次成功调用距今天数"和你标注的白名单来判断。
• 无日志时降级：若客户端没有调用日志，判定降级为"依赖完整性 + 同类重叠"，结论会标注为"推断"而非"确定"。
• 静态扫描不执行脚本：只读取 frontmatter 与依赖声明，不会运行技能内部脚本，无法发现运行时才暴露的故障。
• 只针对明确失效信号：不承诺找出所有"低效"技能，scope 收紧在依赖缺失、频繁报错、长期零调用、被更优替代这四类明确信号上。