遇到的问题
skill 越装越多，特别是全局安装的 Skill ，元信息占用了过多的上下文空间。为了解决这个问题，我的第一反应是全局只装必要的 Skill ，其他的就具体的项目里安装。
但是这样我就逃避了一个问题：怎么样才能集中管理Skill？
前段时间看到宝玉老师通过 Symlink 去管理 Skill：通过 Symlink 直接链接到原始 Skills 的 Repo。我觉得这是个管理 Skill 的好办法，再结合我现在使用 Skill 的经验：
- 别人的 Skill clone 下来需要根据不同的Agent架构与电脑环境进行适配才好用。更新的时候适配还需要重新做一遍。
- Skill 太多，对于 Skill 的触发方式、功能、完成度、来源（主要用于更新）两眼一抹黑，需要 Skill 总览和 Skill 搜索，提高 Skill 的使用效率。
找AI聊需求
发现自己遗漏了一些细节。
之前的设计我只是通过安装方式对 Skills 进行了分类，并没有管理 Skill 的状态，所以让AI补全了相关的设计。
before:
- custom 目前表示“自己写的、完成后进入 skills”。
- remote 表示“远程拉取的、待适配”。
- skills 表示“最终可用”。
after:
./
├── registry/ # 核心索引层，不是给人手工翻目录用的
│ ├── skills.json # 所有 skill 的注册表
│ ├── sources.json # 来源仓库、版本、同步信息
│ └── projects.json # 各项目启用关系
├── warehouse/
│ ├── remote/ # 原始拉取内容，只保留上游原貌
│ ├── adapted/ # 适配后的可分发版本
│ └── local/ # 本地原创 skill
├── runtime/
│ ├── global/ # 当前全局启用集合
│ └── projects/ # 每个项目的启用清单或 symlink 目标
├── manifests/
│ └── <skill-name>.yaml # 每个 skill 的声明文件
└── bin/
└── hk-skill # 管理命令入口
和AI探讨了之后，让他重新出了一版设计文档。
项目已开源，设计文档放在里面了，如果不忙会把方案单独抽出来做成工具。
产品效果
./bin/hk-skill install {repo}
# 执行流程：fetch → vet → adapt → register
# 拉取远程项目并进行安全审查，成功就注册，失败就清除文件
./bin/hk-skill enable {skill-name} --global
# 全局启用，建议工具类方法
./bin/hk-skill enable {skill-name} --project {project-path}
# 项目内启用，project-path为绝对地址
经验教训
因为刚开始只是当作小工具在开发，所以出了设计文档就开始 vibe coding，正是因为没有技术方案，也没有写 spec、rules 和 agents.md 这些文档才导致了后面 token 飙增的情况出现。
有了设计文档一定要有配套的技术方案和规范文档！这里不能省，省了后面更亏。
设计就像十月怀胎，写代码就像一朝分娩，设计就是写代码。情况不明决心大，心中无数点子多。
期间我尝试了多种模型配合开发的场景，最后感知到的体验是：
- OpenCode + oh-my-openagent 效果比单一类型的模型效果更好。但是偶尔会出现卡死的情况，虽然有指定Agent-Atlas作为上下文维持，但是还是没法及时中断并重启项目，写之前需要单独声明：做不来的工作别勉强，及时中断或者换个工作。
- GPT5.4 计划/审核/测试 + kimi2.5 执行，效果最好。（期间还用了 glm5.1/gemini3/minimax2.5）
