一个 Skills 管理工具，解决一些痛点问题，已开源

现在 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 ，本质上通常意味着在多个目录中保存它的副本。

刚安装时，它们的内容完全相同。但使用一段时间后，很容易出现这样的情况：

1. Codex 中的 Skill 规则被修改；


2. Claude Code 中还保留着旧内容；


3. Cursor 的项目目录中又有一个针对当前项目调整过的版本；


4. 三个目录里的文件名相同，但内容已经不一样了。

这类问题可以称为 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

安装完成后，可以先尝试下面这条最短体验路径：

1. 打开 SkillBuddy ，查看自动检测到的 Agent ；


2. 查看本机已有的用户级 Skills ；


3. 添加一个项目目录，检查项目级 Skills ；


4. 选择一个 Skill ，查看它在不同 Agent 中的安装状态；


5. 尝试把它安装或同步到另一个 Agent ；


6. 将几个常用 Skills 保存为一个技能包。