Agent 用的越多，Skills 却散落在各处
现在同时使用多个 Agent 变得很常见：
开发者可能在不同场景下使用：
不同 Agent 的 Skills 通常保存在各自约定的目录中。
当只使用一个 Agent 、安装三五个 Skills 时，直接管理文件夹并没有什么问题。可是一旦 Agent 和 Skills 的数量增加，事情就变得复杂了。
你可能会遇到这些情况：
文件夹只能告诉用户“文件放在哪里”，却很难回答“当前拥有哪些能力”。
这就是第一个明显的管理痛点：Agent 众多，但缺少一个统一的 Skills 视图管理。
缺少的不是一个 Skills 市场，而是可视化管理
现在已经有 skills.sh 、skillhub 、GitHub 等渠道帮助我们发现 Skills ，也有命令行工具帮助用户完成安装。
它们很好地解决了 “去哪里找” 和 “怎么装” 的问题。
但长期使用时，用户还需要知道：
当 Skills 从几个变成几十个甚至更多时，继续依赖命令行和文件目录，会逐渐失去整体视角。
更理想的方式，是提供一个类似软件包管理器的工作台，打开以后就能看到本机所有 Agent 、Skills 、安装位置和状态，而 SkillBuddy 则是为此而来。
同一个 Skill ，为什么会出现好几个版本？
把一个 Skill 安装到多个 Agent ，本质上通常意味着在多个目录中保存它的副本。
刚安装时，它们的内容完全相同。但使用一段时间后，很容易出现这样的情况：
[ol]
[/ol]
这类问题可以称为 Skills 内容漂移。
它比“有没有安装”更难发现。因为从文件名来看，一切似乎都很正常，只有真正比较文件内容时，才能发现它们已经不是同一份 Skill 。
SkillBuddy 会聚合不同 Agent 中的同名 Skills ，并提示内容不一致。用户可以查看差异，选择一个可信版本作为基准，再同步到其他目标。
这意味着 Skills 管理不再只是复制文件，还包括：
全局 Skills 和项目 Skills ，也应该分开管理
并不是所有 Skills 都适合全局安装。
例如：
如果把所有 Skills 都放在全局目录中，Agent 会接收到越来越多与当前任务无关的信息。如果全部放进项目，又会出现大量重复配置。
因此，Skills 管理需要明确区分：
SkillBuddy 可以添加项目目录，扫描项目中的 Skills ，并把它们与用户级 Skills 分开展示。
一个 Skill 不够，还需要管理“技能包”
在真实项目中，开发者很少只依赖一个 Skill 。
以 Vue 项目为例，一套完整的开发能力可能包括：
如果每次创建项目都逐个寻找、选择和安装，不仅操作重复，还很容易漏掉其中一项。
这和开发环境中的依赖管理很相似：最终需要管理的不是一个个孤立工具，而是一套可以复用的能力组合。
所以 SkillBuddy 支持把多个 Skills 组合成技能包，用于：
可以建立：
Skills 只有能够被组织和复用，才会逐渐从“几份提示词文件”变成真正的能力体系。
个人 Skills 和团队 Skills ，分开管理
个人使用 Skills 时，更关心：
因此，SkillBuddy 支持将个人用户级 Skills 和技能包备份到私有 Git 仓库。更换电脑时，可以先预览远端内容和安装目标，再决定恢复哪些资源。
但团队管理完全是另一个层次的问题。
团队不能把未经确认的 Skill 直接分发给所有成员。它通常需要考虑：
只把文件放进一个共享目录，并不能解决这些问题。
SkillBuddy 的团队库使用 Git 仓库作为事实来源。团队可以在仓库中管理经过审核的 Skills 、MCP 定义、岗位技能包和项目策略，并继续利用 Git 已有的分支、提交和 Pull Request 审核流程。
还有更多功能特性，欢迎下载查看👇
下载和体验
SkillBuddy 已经在 GitHub 开源，使用 MIT 协议。
安装完成后，可以先尝试下面这条最短体验路径：
[ol]
[/ol]
