-20260617173511.png|500](https://mmbiz.qpic.cn/mmbiz_png/fkDSDWnukB1o40uOcyfib8HazsMrAjQgThfnyYM1S8ia8ANUIqgTgQkHB6q8XzxMVdPsfldEjkQ5oFHibURjDXVNckaqnwpnoh1EYwuYHw9G2E/640?wx_fmt=png&from=appmsg&_t=1783211059781)
如果我把这个 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 仓库 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 的项目级路径即可。
## 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，重新变成一份源文件和几根清楚的线。
