别再复制 Skills 文件夹了，我做了一个叫 Kitestring 的小工具

我最近做了一个开源小工具，叫 Kitestring。

它解决的问题很小：当我同时使用 Claude Code、Codex、Copilot CLI、Gemini CLI 时，不想再把同一份 Skill 复制到多个目录里。

每个工具都有自己读取 Skill 的路径。为了让同一套工作流在不同工具中都能使用，最直觉的办法就是复制文件夹。Claude Code 需要一份，Codex 需要一份，Copilot CLI 需要一份，Gemini CLI 可能也需要一份。

但只要你真的开始持续使用和修改 Skill，复制文件夹很快就会失控。

Kitestring 做的事情很简单：保留一份真实的 Skill 源文件，然后用 symlink 把它分发到不同 AI 工具会读取的目录里。

就像放风筝。Skill 可以出现在不同工具的目录中，但线还在你手里，真正需要维护的文件始终只有一份。

前段时间，我写过一篇介绍如何用 Claude Marketplace 管理 skills 的文章。

当时的出发点很明确：电脑里的 Skill 越来越多，我希望借助 Anthropic 官方提供的能力，把它们统一管理起来。这个初衷现在依然成立，但继续用了一段时间后，我发现 Claude Marketplace 只能解决 Claude Code 生态里的 Skill 管理问题。

我的日常使用场景已经超过 Claude Code。我会用 Codex、Copilot CLI、Gemini CLI，也会尝试其他 Agent 工具。它们各自有自己的目录约定，并不会主动读取 Claude Code 存放 Skill 的路径。

同时我自己也针对工作或创作场景，写了不少 skill，比如 article2ticktick、mp-article-writor、logging-session。

这些 skill 一开始都是为了解决我自己的真实工作流问题，不是为了上架某个市场而写的。它们里面可能包含我自己的路径约定、工作流习惯，甚至一些不适合公开的个人信息。为了管理它们而创建开源项目来上架 Claude Marketplace，对我来说并不合适。

还有一些开源项目也没有主动适配 Claude Marketplace，比如我下载过的 khazix-skills、magazine-web-ppt。我当然可以提交 Issue 甚至提交 PR 来帮助项目适配 Claude Marketplace，但最终是否接入，并不取决于我。

我希望自己能决定 Skill 放在哪里，也希望多个 AI 工具都能读取同一份 Skill。

直接复制一份，是最简单的解决办法。

Copilot CLI 从 ~/.copilot/skills/ 路径读取 skill，我就复制一份到那里。Codex 读 ~/.codex/skills/，我就再复制一份。

但随之而来的问题是数据不同步。

比如我在使用 mp-article-writor 时，经常会根据真实写作过程调整规则。今天发现文章开头容易虚，就加一条禁止教科书开头。明天发现标题太像产品说明书，就补一条标题风格规则。后天发现自检报告没有抓住 AI 味，又继续改审读标准。

如果我把这个 skill 复制到好几个工具目录里，那我每改一次，就要想起自己复制过哪些地方。漏掉一个目录，那个工具读到的就是旧版本。再过几周，我自己都不一定分得清哪个才是最新的。

从 Github 上下载的开源项目也是同理，作者更新后，我可以快速拉取最新的改动，但仍然需要手动一份份复制到其他工具目录中。目录越多，复制越容易漏。

还有一个更麻烦的问题：Skill 的迭代需求，最容易出现在日常使用过程中。

当我在某个项目里调用 Agent，发现某条规则不够准确时，最理想的方式是直接让当前 Agent 基于当下的上下文帮我修改 Skill。但如果 Skill 的真实存放路径和当前项目路径完全分离，我就需要先总结问题，再切换到保存 Skill 的目录里修改。

这一步看起来不大，但会明显打断工作流。我真正想要的状态是：无论在哪个工具、哪个项目中修改 Skill，最后改到的都应该是同一份源文件。

更合适的方案是使用 symlink。

你可以把 symlink 近似理解成 Windows 上的「创建快捷方式」，或 macOS 上的「制作替身」。它看起来像一个文件夹，但真实内容存放在别的地方。

和普通快捷方式相比，symlink 对很多命令行工具更友好。大多数软件会直接把它当成真正的文件夹来处理。

这样一来，真实文件夹只需要保留一份，放在你真正想维护的位置。其他工具目录里放的不是复制品，而是指向源文件夹的 symlink。

我只需要修改 mp-article-writor 的源文件，Claude Code、Codex、Copilot CLI 顺着 symlink 读到的就是最新内容。

我不用再想自己复制过哪些目录，也不用担心某个工具还在使用上周的旧版本。

symlink 带来的另一个好处，是我可以把所有 Skill 统一保存在一个本地文件夹中，同时让不同工具读取同一份内容。这样既能保持文件管理清晰，也方便我随时迭代自己的工作流。

问题在于，symlink 本身不够顺手。

它通常需要通过命令行创建：

ln -s 真实文件夹路径 目标文件夹路径

如果我同时使用 Claude Code、Copilot CLI、Codex、Gemini CLI，每个工具又有用户级路径和项目级路径，就需要反复执行类似命令。

路径要记，目录要找，创建完还要确认有没有生效。

所以我做了 Kitestring。

它的目标不是发明新的 Skill 格式，也不是重新做一个 Skill 市场。它只做一件事：帮你把已有 Skill 的源文件和各个工具目录之间的 symlink 管起来。

很多人真正需要这个工具时，本地早就已经有一堆 skill 了。

它们可能在 Claude Code 或是 Codex 的目录里，可能来自 Claude marketplace，也可能是某个 GitHub 仓库 clone 下来的文件夹。

所以 Kitestring 支持几种导入方式，尽量让你不用从零开始整理。如果你已经在使用 symlink 管理 skill，别担心，导入时会自动识别并标识，同时也会追溯真正的 skill 源文件一并导入。

第一种方式，从工具的用户级默认读取路径导入。

Kitestring 内置了 Claude Code、Copilot CLI、Gemini CLI、Codex 的默认路径，也支持通用的 Agent Folder。

比如 Claude Code 默认路径是：

~/.claude/skills/

Codex 默认路径是：

~/.codex/skills/

如果这些目录里已经有 Skill，Kitestring 会尝试识别并纳入管理。

对于 Claude Marketplace 下载的 Skill，我也做了专门识别。适配 Claude Marketplace 的 Skill 项目，路径往往是类似这样的层级：

~/skills/article2ticktick/skills/article2ticktick

它和一般的 Skill 文件夹路径不同。

所以 Kitestring 默认会扫描 ~/.claude/plugins/marketplaces，在有限深度内递归查找 SKILL.md，同时跳过 ~/.claude/plugins/cache/ 这类缓存目录。

只要 Skill 位于 Kitestring 已配置的扫描路径下，并且目录内有 SKILL.md，Kitestring 会尽量把它识别出来，而不是要求用户先理解每个平台的目录习惯。

第二种方式，是从本地文件夹导入。

Kitestring 可以直接从本地文件夹中扫描 Skill。无论这个文件夹里只有一个 Skill，还是包含多个 Skill，它都会递归查找 SKILL.md，读取里面的 name 和 description，并把真实文件夹记录为 Skill 源目录。

像我自己有一个独立的 skills 文件夹，用来保存自己创建的 Skill，以及从 GitHub 下载的开源 Skill，就可以用这种方式批量导入。

第三种方式，是创建项目并导入。

一个独立开发项目、一个 Obsidian 仓库，都可以视作 Kitestring 里的「项目」。

在同一个项目中，我们可能会使用多种 Agent 工具。比如我自己就经常同时使用 Claude Code、Codex 和 Copilot CLI。对于某些常用 Skill，每个工具都应该能读到。

通过项目导入后，Kitestring 可以从项目维度查看工具和 Skill 的关系。你可以看到这个项目下有哪些 Skill，也可以看到它们是否已经分发到对应工具路径中。

这个能力很适合探索新工具。

比如我已经在某个项目里用 Claude Code 打磨出一组常用 Skill，现在想试试 Codex，就不用手动复制目录。只要在项目视图里把这些 Skill 分发到 Codex 的项目级路径即可。

导入 Skill 之后，Kitestring 会记录它的源路径、来源类型、Git 信息和分发记录。

你可以看到一个 Skill 来自本地文件夹，还是来自 GitHub。你也可以看到它当前是否位于 Git 仓库中，以及它已经被分发到了哪些工具路径。

这里有一个重要边界：Kitestring 是本地 Skill 管理工具。

导入意味着在 Kitestring 中创建 Skill 记录。原文件仍然保存在原来的位置，Kitestring 不会默认把它复制到自己的项目目录里。

直接从 GitHub URL 导入时除外。这种方式下，Kitestring 会把仓库 clone 到：

~/.kitestring/repos/

我一开始不想把自动更新做得太激进。

Skill 里经常包含工作流、提示词、路径约定和个人习惯。它不是缓存文件，不能被随便覆盖。

如果 Skill 来自 GitHub，或者本地目录本身就是一个 Git 仓库，Kitestring 可以尝试拉取更新。但目前使用的是比较保守的策略：只处理干净工作区里的 fast-forward 更新。

如果存在未提交文件、未跟踪文件，Kitestring 会拒绝拉取。

如果分支已经分叉，Kitestring 也不会强行合并或覆盖。

对 Skill 来说，我更希望更新是可控的，而不是自动替你做危险决定。

Kitestring 里的「分发」，本质上就是在指定路径创建 symlink。

我最常做的动作很简单：选中一个 Skill，在对应工具路径上点击分发按钮，Kitestring 就会创建 symlink，并记录这条分发关系。

比如我把 mp-article-writor 分发到 Claude Code，也分发到 Codex。Kitestring 会在对应目录下创建 symlink。取消分发时，它只会移除目标路径里的 symlink，不会删除 Skill 源文件。

如果你需要自定义路径，也可以手动输入目标目录。这个功能对不完全遵循默认路径的工具，或者个人自定义配置很有用。

以前我遇到 Skill 没生效时，常常要在几个目录之间来回检查。到底是 Claude Code 没读到，还是 Codex 目录里没有，还是我复制的是旧版本，还是名字写错了。

Kitestring 至少把这件事变成一个可以被看见的状态。你能看到一个 Skill 分发到了哪里，也能看到某个工具路径下是否已经存在对应 symlink。

项目级分发适合多 Agent 工具项目

一个项目里可能同时使用 Claude Code 和 Codex。它们各自有项目级 skill 路径，比如 .claude/skills/ 和 .codex/skills/。如果一个项目级 skill 对这两个工具都有用，Kitestring 可以把它分发到对应路径。

在项目视图里，你可以看到这个项目下的所有 Skill，以及它们在各个工具路径里的状态。

你可以对单个 Skill 分发，也可以按某个工具列，把当前项目内尚未分发的 Skill 逐个分发过去。

这个功能的价值在于，它把「这个项目使用哪些 Skill」和「这些 Skill 是否已经被各个 Agent 工具读到」放在同一个视图里。

对我来说，这比手动记路径可靠得多。

Kitestring v0.1.0 现在已经发布，目前仍处于 Early Preview 阶段。

这个版本还不完美。配置格式、交互细节、工具兼容范围，都可能在后续版本里继续调整。

首个公开版本提供 macOS、Windows 和 Linux 的安装包。

如果你已经在使用 Claude Code、Codex、Copilot CLI、Gemini CLI，并且本地已经积累了越来越多 Skills，Kitestring 现在已经可以帮你处理这些工具的默认路径导入、Skill 识别和 symlink 分发。

它现在做的事情很明确：

把散落在不同目录里的 Skill，重新变成一份源文件和几根清楚的线。