Claude Code 用久以后，Skill 最大的问题不是不会装，而是“装完没人管”。某个前端规范 Skill 半年前写的，测试 Skill 换过命令，项目里还残留两个重复目录，Agent 读到的上下文就会互相打架。vercel-labs/skills 的价值在管理环节：用同一组 `npx skills` 命令做发现、安装、查看、更新、删除和初始化。

从 find 开始，不从 add 开始

管理技能包时，第一步最好不是安装，而是发现。`npx skills find [query]` 用来按关键词找 Skill，内置的 find-skills 说明里也把它定义成 Skills CLI 的关键命令。对 Claude Code 来说，这一步能减少盲装。比如要找测试、设计、部署相关能力，先查有没有现成 Skill，再决定是否安装。失败场景是凭仓库名猜功能，装完才发现 Skill 面向的是另一个 Agent 或另一个框架。

给 Claude Code 留一份清单

安装后要定期跑 `npx skills list`。这个动作看起来普通，却能回答三个问题：当前项目有哪些 Skill，哪些是全局安装，哪些已经不该继续保留。团队协作时，建议把项目级 Skill 作为仓库约定的一部分，而不是每个人私下全局安装。全局安装适合个人习惯，项目安装适合团队流程。混用不记录，排查问题会很痛苦。

更新不是越频繁越好

`npx skills update` 能刷新已安装 Skill，但更新前要看它影响什么任务。如果 Skill 只是个人写作辅助，更新风险低；如果它控制发布、部署或测试流程，更新后要跑一个小任务验收。失败场景是 Skill 改了规则，Claude Code 仍按新规则执行，但团队文档和 CI 脚本没同步，结果不是模型出错，而是流程不一致。

给每个 Skill 贴一个责任标签

我会把 Claude Code 技能包分成三类：个人习惯、项目流程、团队规范。个人习惯可以全局安装，项目流程放在项目目录，团队规范要能被文档或仓库记录追踪。这样分类后，`list` 出来的内容才有意义。否则列表里全是名字，没人知道哪些能删、哪些不能动。管理 Skill 不是攒收藏夹，而是让 Claude Code 在正确场景读到正确规则。

还有一个小动作很有用：每次更新或删除前，先跑一个代表性任务。比如删除测试 Skill 前，让 Claude Code 修一个小测试；更新前端 Skill 前，让它审一段组件代码。输出变化很大，就说明这个 Skill 影响了真实工作，不该随手处理。

什么时候 remove

Skill 失效时要删，不要只靠“以后不用”。判断标准很简单：项目已经不用这个框架、命令和当前工具版本不匹配、同类 Skill 有两个以上、Claude Code 经常引用无关规则。此时用 `remove` 清理，比在提示词里反复强调“忽略某某 Skill”更干净。一个健康的 Claude Code 技能库应该少而准，能解释为什么存在，也能说清什么时候退出。管理做到这一步，Claude Code 才像稳定工具，而不是一堆越装越乱的提示文件，后续协作也更好交接、复盘即可。