Kitestring实用测评：告别Skills文件夹复制老方法
为什么需要这个工具
此前，我曾分享过如何利用 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 帮助适配，但最终是否接入，不由我决定。
我希望自己能掌控 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。你可以把 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。
Kitestring 能把已有 Skill 找出来
很多人真正需要这个工具时，本地已经积累了一堆 skill。它们可能散落在 Claude Code 或 Codex 的目录里，可能来自 Claude marketplace，也可能是 GitHub 仓库克隆下来的文件夹。因此 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.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 的项目级路径即可。
Kitestring 只做本地管理
导入 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 而言，更新应该是可控的，而非工具替你做危险决定。
分发就是创建 symlink
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，重新变成一份源文件和几根清晰的线。 GitHub 地址：balabalabalading/Kitestring[1] Release 下载地址：Kitestring Releases[2] 如果你也被 Skill 的路径和分发问题困扰过，可以先试试 Kitestring。先把这根风筝线牵起来。- https://github.com/balabalabalading/Kitestring ↩
- https://github.com/balabalabalading/Kitestring/releases ↩