我最近做了一个开源小工具，叫 Kitestring。
它解决的问题很小：当我同时使用 Claude Code、Codex、Copilot CLI、Gemini CLI 时，不想再把同一份 Skill 复制到多个目录里。
这个问题听起来不像什么架构难题，甚至有点琐碎。但很多工具链里的麻烦，往往就是从这种琐碎开始的。一个目录复制一次没什么，复制到四个工具里也还能忍。真正麻烦的是，你开始持续修改这些 Skill，并且希望不同 Agent 工具都能读到同一套工作流。
到这一步，复制文件夹就开始变成技术债了。
一、Skill 变多以后，复制会失控
每个 Agent 工具都有自己的 Skill 读取路径。
Claude Code 有自己的目录，Codex 有自己的目录，Copilot CLI 也有自己的目录，Gemini CLI 可能又是一套约定。为了让同一份工作流在不同工具里都能使用，最直觉的办法就是复制文件夹：
- Claude Code 需要一份
- Codex 需要一份
- Copilot CLI 需要一份
- Gemini CLI 再来一份
一开始很顺手。甚至可以说，这是最符合直觉的方案。
但只要你真的开始长期使用和修改 Skill，问题很快会冒出来。
比如我自己写过一些面向工作流的 Skill：
article2ticktickmp-article-writorlogging-session
这些 Skill 一开始都不是为了上架某个市场而写的，而是为了解决我自己的实际工作流问题。里面可能有个人路径约定、写作习惯、审读规则，甚至有些不适合公开的内容。
以前我写过一篇介绍如何用 Claude Marketplace 管理 Skills 的文章。当时的想法很直接：电脑里的 Skill 越来越多，希望借助 Anthropic 官方提供的能力统一管理。
这个出发点现在依然成立。
但继续用了一段时间后，我发现 Claude Marketplace 解决的是 Claude Code 生态里的 Skill 管理问题。我的日常使用场景已经不止 Claude Code。我会用 Codex、Copilot CLI、Gemini CLI，也会尝试其他 Agent 工具。
这些工具不会主动读取 Claude Code 的 Skill 目录。
这就带来一个很现实的问题：如果我希望同一套 Skill 在多个工具里可用，靠 Claude Marketplace 还不够。
开源项目也类似。比如我下载过一些 Skill 项目，像 khazix-skills、magazine-web-ppt。它们不一定主动适配 Claude Marketplace。理论上我可以提 Issue，也可以提 PR，但最终是否接入，并不取决于我。
我更希望自己能决定 Skill 放在哪里，也希望多个 AI 工具都能读取同一份 Skill。
二、直接复制的问题不在当下，而在后续迭代
直接复制当然能用。
Copilot CLI 从：
~/.copilot/skills/
读取 Skill，我就复制一份到那里。
Codex 从：
~/.codex/skills/
读取 Skill，我就再复制一份。
如果只是一次性使用，这没什么问题。很多工程方案在规模很小时都能跑，麻烦往往出现在“后来又改了几次”。
比如我在使用 mp-article-writor 时，经常会根据真实写作过程调整规则：
- 今天发现文章开头容易虚，就加一条禁止教科书式开头
- 明天发现标题太像产品说明书，就补一条标题风格规则
- 后天发现自检报告没抓住 AI 味，又继续改审读标准
如果这个 Skill 被复制到了好几个工具目录里，每改一次，就要记得同步到所有地方。
漏掉一个目录，那个工具读到的就是旧版本。
再过几周，很可能连自己都分不清哪个才是最新的。这个问题我见过很多次，不只发生在 Skill 上。配置文件、脚本、模板、Prompt、SQL 片段，只要用复制来做分发，最后都会遇到类似的漂移问题。
开源 Skill 也一样。
作者更新后，我可以很快拉取最新改动。但如果我已经把它复制到了 Claude Code、Codex、Copilot CLI 的不同目录里，后面还要手动一份份覆盖。目录越多，漏同步的概率越高。
更麻烦的是，Skill 的迭代通常发生在使用现场。
当我在某个项目里调用 Agent，发现某条规则不够准确时，最理想的方式是直接让当前 Agent 基于上下文帮我修改 Skill。
但如果 Skill 的真实存放路径和当前项目完全分离，我就得先总结问题，再切换到保存 Skill 的目录里修改。这个动作看起来不大，但足够打断工作流。
我真正想要的状态是：
无论在哪个工具、哪个项目中修改 Skill，最后改到的都应该是同一份源文件。
这就是 Kitestring 想解决的核心问题。
三、symlink 是更合适的底层机制
Kitestring 没有发明新的 Skill 格式，也没有重新做一个 Skill 市场。
它做的事情很简单：保留一份真实的 Skill 源文件，然后用 symlink 把它分发到不同 AI 工具会读取的目录里。
就像放风筝。
Skill 可以出现在不同工具的目录中，但线还在你手里。真正需要维护的文件始终只有一份。
symlink 可以粗略理解成 Windows 上的“创建快捷方式”，或者 macOS 上的“制作替身”。它看起来像一个文件夹，但真实内容存放在别的地方。
和普通快捷方式相比，symlink 对很多命令行工具更友好。大多数软件会直接把它当成真正的文件夹来处理。
于是目录关系会变成这样：
真实文件夹只保留一份，放在你真正想维护的位置。
其他工具目录里放的不是复制品，而是指向源文件夹的 symlink。
我只需要修改 mp-article-writor 的源文件，Claude Code、Codex、Copilot CLI 顺着 symlink 读到的就是最新内容。
这类方案的工程取舍很明确：
| 方案 | 优点 | 问题 | 适合场景 |
|---|---|---|---|
| 手动复制 | 简单直接，不依赖额外工具 | 多份文件容易漂移，长期维护成本高 | 一次性使用、Skill 很少 |
| Git submodule | 版本可控，适合团队协作 | 对普通个人工作流偏重，操作心智成本高 | 团队共享、强版本管理 |
| 包管理/市场 | 分发清晰，有生态优势 | 依赖平台，私有 Skill 不方便 | 公开 Skill、生态内复用 |
| symlink | 源文件唯一，工具兼容性较好 | 路径和链接状态需要管理 | 本地多 Agent 工具共享 |
symlink 的优势不是“高级”，而是它刚好贴合这个问题：同一份本地内容，需要出现在多个工具约定目录里。
问题在于，symlink 本身不够顺手。
通常需要手动执行命令：
ln -s 真实文件夹路径 目标文件夹路径
如果我同时使用 Claude Code、Copilot CLI、Codex、Gemini CLI，每个工具又有用户级路径和项目级路径，就需要反复执行类似命令。
路径要记，目录要找，创建完还要确认有没有生效。
所以我做了 Kitestring。
四、Kitestring 先把已有 Skill 找出来
很多人真正需要这个工具时，本地早就已经有一堆 Skill 了。
它们可能在 Claude Code 的目录里，也可能在 Codex 的目录里；可能来自 Claude Marketplace，也可能是某个 GitHub 仓库 clone 下来的文件夹。
所以 Kitestring 支持几种导入方式，尽量不要求你从零整理。
如果你已经在用 symlink 管理 Skill，导入时 Kitestring 会自动识别并标识，同时追溯真正的 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 更新
- 如果存在未提交文件，拒绝拉取
- 如果存在未跟踪文件，拒绝拉取
- 如果分支已经分叉，不强行合并
- 不自动覆盖用户本地修改
这背后的判断很简单：对 Skill 来说，更新应该可控。
自动帮用户做危险决定，看起来省事，实际很容易变成另一个坑。尤其是 Skill 这种东西，很多内容并没有严格的测试用例，坏了以后未必立刻报错，但会悄悄改变 Agent 的行为。
这种风险不值得。
六、分发就是创建 symlink
Kitestring 里的“分发”，本质上就是在指定路径创建 symlink。
我最常做的动作很简单：
选中一个 Skill，在对应工具路径上点击分发按钮，Kitestring 就会创建 symlink，并记录这条分发关系。
比如我把 mp-article-writor 分发到 Claude Code，也分发到 Codex。Kitestring 会在对应目录下创建 symlink。
取消分发时，它只会移除目标路径里的 symlink，不会删除 Skill 源文件。
如果你需要自定义路径，也可以手动输入目标目录。这个功能对不完全遵循默认路径的工具，或者个人自定义配置很有用。
以前我遇到 Skill 没生效时，常常要在几个目录之间来回检查：
- Claude Code 到底有没有读到？
- Codex 目录里是不是没有？
- 我复制的是不是旧版本？
- 文件夹名字是不是写错了？
- 目标路径是不是工具实际读取的路径？
Kitestring 至少把这件事变成一个可以被看见的状态。
你能看到一个 Skill 分发到了哪里，也能看到某个工具路径下是否已经存在对应 symlink。
这类工具的价值不在于多复杂，而在于减少那些低价值但很耗精力的检查动作。
七、项目级分发适合多 Agent 项目
用户级 Skill 解决的是全局复用问题。
但项目级 Skill 也很常见。
一个项目里可能同时使用 Claude Code 和 Codex。它们各自有项目级 Skill 路径，比如：
.claude/skills/
以及：
.codex/skills/
如果一个项目级 Skill 对这两个工具都有用，Kitestring 可以把它分发到对应路径。
在项目视图里，你可以看到这个项目下的所有 Skill，以及它们在各个工具路径里的状态。
你可以对单个 Skill 分发，也可以按某个工具列，把当前项目内尚未分发的 Skill 逐个分发过去。
这个功能的价值在于，它把两件事放到了同一个视图里：
- 这个项目使用哪些 Skill
- 这些 Skill 是否已经被各个 Agent 工具读到
对我来说，这比手动记路径可靠得多。
八、Kitestring 现在能做什么
Kitestring v0.1.0 已经发布，目前仍处于 Early Preview 阶段。
这个版本还不完美。配置格式、交互细节、工具兼容范围，都可能在后续版本里继续调整。
首个公开版本提供 macOS、Windows 和 Linux 的安装包。
如果你已经在使用 Claude Code、Codex、Copilot CLI、Gemini CLI，并且本地已经积累了越来越多 Skills，Kitestring 现在可以处理几件事：
- 从常见工具默认路径导入 Skill
- 识别本地已有 Skill
- 识别部分 Claude Marketplace Skill 路径
- 从本地文件夹递归扫描
SKILL.md - 从 GitHub URL clone Skill 仓库
- 记录 Skill 源路径、来源类型和 Git 信息
- 把 Skill 分发到不同工具路径
- 用 symlink 保持同一份源文件
- 在项目视图中管理多 Agent 工具的 Skill 状态
它现在做的事情很明确：
把散落在不同目录里的 Skill，重新变成一份源文件和几根清楚的线。
如果你也被 Skill 的路径和分发问题烦过，可以先试试 Kitestring。
先把这根风筝线牵起来。
