UnifySkillManager一个统一的 AI 编程工具 Skill / Rule Manager

现在不同 AI 编程工具都开始有自己的配置体系。

Codex 有 Skills，Claude 有用户级和项目级指令，Cursor 有 Rules，CodeBuddy 也有自己的 Skill 目录结构。它们解决的问题很相似：把可复用的工作流、规范、偏好和上下文保存下来，让 AI 在之后的任务里能稳定遵守。

但麻烦也随之出现了：每个工具的存储路径、文件格式、命名方式、全局配置和项目配置规则都不太一样。Skill 和 Rule 写起来不难，真正烦的是记住它们应该放到哪里。

UnifySkillManager 就是为了解决这个问题做的一个本地 Web 工具：把 Skill 和 Rule 统一存放在一个 Markdown-first 的本地库里，然后按需同步到 Codex、Claude、Cursor、CodeBuddy 等工具。

UnifySkillManager dashboard

UnifySkillManager library detail

问题从哪里来

现在很多 AI 编程工具都支持某种形式的可复用指令：

  • Skill：适合保存可重复执行的工作流
  • Rule：适合保存编码规范、行为约束和团队约定
  • 项目级指令：只在当前项目生效
  • 全局用户偏好：在所有项目里生效
  • 工具专属 prompt 片段：只对某个工具有意义

这些能力很有用，但它们散落在不同工具的目录中。

比如同一个 Skill，在一个工具里可能需要放在：

1
~/.codex/skills/my-skill/SKILL.md

另一个工具里可能是：

1
~/.claude/skills/my-skill.md

Cursor 的 Rule 又可能是：

1
.cursor/rules/my-rule.mdc

如果再加上“全局配置”和“当前项目配置”两个作用范围，管理成本会进一步增加。

我想要的是一个统一入口：Skill 和 Rule 只维护一份，需要给哪个工具用，就同步到哪个工具。

核心思路：Markdown 是主数据

UnifySkillManager 把 Markdown 当成主存储格式。

每个 Skill 或 Rule 都是一个 .md 文件。结构化信息放在 YAML frontmatter 里，正文仍然是普通 Markdown。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
---
id: swiftui-review
type: skill
name: SwiftUI Review
description: Review SwiftUI code for maintainability and performance.
targets:
  - codex
  - cursor
scope:
  - global
  - project
enabled: true
version: 1.0.0
---

# SwiftUI Review

Use this skill when reviewing SwiftUI code.

这样设计有几个好处：

  • 文件可以直接阅读，不依赖 Web UI。
  • 对 Git 友好，适合版本管理。
  • 可以用任意编辑器修改。
  • Web UI 仍然可以解析和管理元数据。
  • 以后要支持 JSON、YAML、TOML 导入，也可以统一转换成 Markdown 保存。

换句话说，Web UI 不是把内容藏进数据库，而是帮助你管理一组真实存在的 Markdown 文件。

Web UI 负责什么

UnifySkillManager 的 Web UI 主要围绕几个动作展开。

首先是添加 Markdown。主流程是直接添加已有 .md 文件，因为很多 Skill 和 Rule 本来就是 Markdown。

其次是扫描已有工具目录。它会扫描 Codex、Claude、Cursor、CodeBuddy 的常见目录，找出已有 Skill 或 Rule，并去重后导入当前 Library。扫描策略比较保守，不会扫全盘，也会避开 references/、templates/、assets/、scripts/ 这些辅助目录，避免把参考文档误当成 Skill。

然后是编辑和管理。选中一个 Skill 或 Rule 后，可以修改：

  • ID
  • 名称
  • 描述
  • 标签
  • 目标工具
  • 作用范围：全局或当前项目
  • Markdown 正文

最后是预览和同步。同步之前可以先看目标工具里将会生成什么文件，确认无误后再写入。

同步不只是复制文件

点击同步时，UnifySkillManager 会做一组操作：

  1. 先把当前页面上的元数据保存回源 Markdown。
  2. 根据目标工具和作用范围计算目标路径。
  3. 渲染工具专属的输出内容。
  4. 如果目标目录不存在，就自动创建。
  5. 如果目标文件已经存在，就先备份。
  6. 写入新文件。
  7. 写完后重新读取文件，确认确实写入成功。

每个生成文件都会带上一个标记：

1
<!-- Managed by UnifySkillManager. Manual edits may be overwritten. -->

这个标记有两个作用：

  • 让人一眼知道这个文件是由 UnifySkillManager 管理的。
  • 让工具检测面板可以统计某个目录下有多少 managed 文件。

当前支持的工具目录

当前适配器会写入这些布局：

工具 Skill 输出 Rule 输出
Codex skills/{id}/SKILL.md rules/{id}.md
Claude skills/{id}.md rules/{id}.md
Cursor 以 Rules 为主 {id}.mdc
CodeBuddy skills/{id}/SKILL.md rules/{id}.md

这里采用 adapter 的设计，是为了让核心模型保持简单，同时给不同工具保留独立演进的空间。

未来如果某个工具改了格式，只需要调整对应 adapter，不需要重写整套管理逻辑。

为什么选择本地优先

这个项目是刻意做成本地优先的：

  • 没有账号系统
  • 没有云同步
  • 没有外部数据库
  • 没有复杂依赖

核心数据就是本地文件：

1
2
3
4
5
library/
  skills/
  rules/
backups/
config/

其中 library/skills 和 library/rules 是主数据，backups 保存覆盖前的旧文件，config 预留给后续本地配置和缓存。

这种方式很朴素，但好处明显：可检查、可备份、可版本管理，也不会把个人配置交给远端服务。

什么才算同步成功

这里需要区分两个层面的成功。

第一层是文件系统层面的成功：UnifySkillManager 已经把文件写入目标路径，重新读回，并确认里面有管理标记。

第二层是工具层面的成功：目标工具已经加载并应用了这个 Skill 或 Rule。

第一层可以由 UnifySkillManager 直接验证。第二层取决于每个工具自己的加载机制。有的工具可能需要重新打开窗口，有的需要 reload workspace，有的可能要新开一次会话才会读取新配置。

所以当前 UI 会明确告诉你：文件是否已经写入并验证。至于工具是否立刻加载，需要结合具体工具的行为确认。

这个边界很重要。一个配置管理工具应该诚实地区分“已经写入磁盘”和“目标工具已经生效”。

后续可以继续做什么

这个版本只是第一步，后面还有很多可以继续完善的地方：

  • 针对每个工具做更严格的格式校验
  • 完善 Cursor .mdc frontmatter 支持
  • 增加导入冲突 review
  • 增加工具兼容性提醒
  • 做一个同步历史页面
  • 支持 Windsurf、Trae、Kiro、Antigravity 等更多工具
  • 支持更细粒度的启用、禁用和批量同步

小结

AI 编程工具正在从“聊天窗口”变成“可编程工作环境”。Skill 和 Rule 也会逐渐成为开发者个人工具链的一部分。

如果这些配置分散在每个工具里，就很难复用、迁移和维护。

UnifySkillManager 想做的是一件很简单的事：把这些可复用的 Skill 和 Rule 收拢到一个本地 Markdown Library 中，再按需同步到不同工具。

它不复杂，但它让个人 AI 工作流变得更可见、更可控，也更容易长期积累。