现在 Skills 生态已经发展的很好了，而随着 AI Agent 的壮大，Skills 的管理也成了一个头痛的问题。
Agent 用的越多，Skills 却散落在各处
现在同时使用多个 Agent 变得很常见：
开发者可能在不同场景下使用：
- Claude Code
- Codex
- Cursor
- Gemini CLI
- GitHub Copilot
- Trae
- OpenCode
- CodeBuddy
- WorkBuddy
- ...
不同 Agent 的 Skills 通常保存在各自约定的目录中。
当只使用一个 Agent 、安装三五个 Skills 时，直接管理文件夹并没有什么问题。可是一旦 Agent 和 Skills 的数量增加，事情就变得复杂了。
你可能会遇到这些情况：
- 不知道电脑里一共安装了多少 Skills ；
- 不知道某个 Skill 被安装到了哪些 Agent ；
- 同一个 Skill 被复制到多个目录，占据了多个独立副本；
- 新安装一个 Agent 后，需要重新寻找和安装常用 Skills ；
- 全局 Skills 和项目级 Skills 混在一起；
- 已经不再使用的 Skill 留在某个角落，很久以后才被发现。
文件夹只能告诉用户“文件放在哪里”，却很难回答“当前拥有哪些能力”。
这就是第一个明显的管理痛点：Agent 众多，但缺少一个统一的 Skills 视图管理。
缺少的不是一个 Skills 市场，而是可视化管理
现在已经有 skills.sh 、skillhub 、GitHub 等渠道帮助我们发现 Skills ，也有命令行工具帮助用户完成安装。
它们很好地解决了 “去哪里找” 和 “怎么装” 的问题。
但长期使用时，用户还需要知道：
- 这个 Skill 是做什么的？
- 它来自哪里？
- 它安装在哪些 Agent 中？
- 它属于全局范围还是项目范围？
- 它当前是否启用？
- 多个 Agent 中的同名 Skill 内容是否一致？
- 哪些 Skills 是自己的，哪些来自插件或系统？
当 Skills 从几个变成几十个甚至更多时，继续依赖命令行和文件目录，会逐渐失去整体视角。
更理想的方式，是提供一个类似软件包管理器的工作台，打开以后就能看到本机所有 Agent 、Skills 、安装位置和状态，而 SkillBuddy 则是为此而来。
同一个 Skill ，为什么会出现好几个版本？
把一个 Skill 安装到多个 Agent ，本质上通常意味着在多个目录中保存它的副本。
刚安装时，它们的内容完全相同。但使用一段时间后，很容易出现这样的情况：
- Codex 中的 Skill 规则被修改；
- Claude Code 中还保留着旧内容；
- Cursor 的项目目录中又有一个针对当前项目调整过的版本；
- 三个目录里的文件名相同，但内容已经不一样了。
这类问题可以称为 Skills 内容漂移。
它比“有没有安装”更难发现。因为从文件名来看，一切似乎都很正常，只有真正比较文件内容时，才能发现它们已经不是同一份 Skill 。
SkillBuddy 会聚合不同 Agent 中的同名 Skills ，并提示内容不一致。用户可以查看差异，选择一个可信版本作为基准，再同步到其他目标。
这意味着 Skills 管理不再只是复制文件，还包括：
- 识别重复副本；
- 检测内容差异；
- 判断哪个版本是基准；
- 预览同步范围；
- 将确认后的内容分发到其他 Agent 。
全局 Skills 和项目 Skills ，也应该分开管理
并不是所有 Skills 都适合全局安装。
例如：
- Vue 3 通用开发规范，可以作为个人全局 Skill ；
- 某家公司的接口约定，只适合公司的项目；
- 某个仓库的目录结构和业务规则，只应该跟随当前项目；
- 临时实验规则，可能只在一个项目中使用几天。
如果把所有 Skills 都放在全局目录中，Agent 会接收到越来越多与当前任务无关的信息。如果全部放进项目，又会出现大量重复配置。
因此，Skills 管理需要明确区分：
- 用户级 Skills：面向个人，在多个项目中复用；
- 项目级 Skills：跟随仓库，只服务于特定项目；
- 插件或系统 Skills：由外部工具维护，通常不应随意修改。
SkillBuddy 可以添加项目目录，扫描项目中的 Skills ，并把它们与用户级 Skills 分开展示。
一个 Skill 不够，还需要管理“技能包”
在真实项目中，开发者很少只依赖一个 Skill 。
以 Vue 项目为例，一套完整的开发能力可能包括：
- Vue 3 最佳实践；
- Vue Router 使用规范；
- Pinia 状态管理规范；
- VueUse 组合式函数规范；
- 组件测试规范；
- UI 组件库规范；
- 项目自己的代码和设计规范。
如果每次创建项目都逐个寻找、选择和安装，不仅操作重复，还很容易漏掉其中一项。
这和开发环境中的依赖管理很相似：最终需要管理的不是一个个孤立工具，而是一套可以复用的能力组合。
所以 SkillBuddy 支持把多个 Skills 组合成技能包，用于：
- 保存常用的个人开发组合；
- 一次安装到多个 Agent ；
- 给新项目快速配置一套 Skills ；
- 导入、导出和分享组合；
- 批量启用或管理相关 Skills 。
可以建立：
- Vue 前端技能包；
- React 性能优化技能包；
- UI 设计审查技能包；
- Node.js 后端技能包；
- 代码评审技能包；
- 某个岗位或项目的专属技能包。
Skills 只有能够被组织和复用，才会逐渐从“几份提示词文件”变成真正的能力体系。
个人 Skills 和团队 Skills ，分开管理
个人使用 Skills 时，更关心：
- 安装了什么；
- 哪些 Agent 可以使用；
- 多台电脑之间如何迁移；
- 如何备份自己编写的 Skills ；
- 如何保持多个副本一致。
因此，SkillBuddy 支持将个人用户级 Skills 和技能包备份到私有 Git 仓库。更换电脑时，可以先预览远端内容和安装目标，再决定恢复哪些资源。
但团队管理完全是另一个层次的问题。
团队不能把未经确认的 Skill 直接分发给所有成员。它通常需要考虑：
- 哪些 Skills 已经通过团队审核；
- 谁可以维护和发布 Skills ；
- 如何记录每次修改；
- 不同岗位应该安装哪些 Skills ；
- 新成员如何快速获得标准能力；
- 项目要求的 Skills 是否缺失或过期；
- 如何阻止不符合安全要求的 MCP 配置。
只把文件放进一个共享目录，并不能解决这些问题。
SkillBuddy 的团队库使用 Git 仓库作为事实来源。团队可以在仓库中管理经过审核的 Skills 、MCP 定义、岗位技能包和项目策略，并继续利用 Git 已有的分支、提交和 Pull Request 审核流程。
还有更多功能特性，欢迎下载查看👇
下载和体验
SkillBuddy 已经在 GitHub 开源，使用 MIT 协议。
- GitHub：https://github.com/konnga/skill-buddy
- 下载地址：https://github.com/konnga/skill-buddy/releases
- 问题反馈：https://github.com/konnga/skill-buddy/issues
安装完成后，可以先尝试下面这条最短体验路径：
- 打开 SkillBuddy ，查看自动检测到的 Agent ；
- 查看本机已有的用户级 Skills ；
- 添加一个项目目录，检查项目级 Skills ；
- 选择一个 Skill ，查看它在不同 Agent 中的安装状态；
- 尝试把它安装或同步到另一个 Agent ；
- 将几个常用 Skills 保存为一个技能包。
Select Language