正在打开每日关注
正在打开每日关注
通过单一源、脚本分发和禁用自动调用，降低 Skills 管理成本与上下文开销。
我是这么管理 Skills 的。 Skill 有两个痛点。 一个是同步。如何保持一个源，让它在项目、全局、以及远程机器上保持一致。 另一个是上下文爆炸。我见过装了两千多个 skill 的用户，然后回过头来问我们，为啥 code agent 这么慢。 我的解法：一个中央仓库，一个 sync 脚本，绝大多数 skill 加 disable-model-invocation: true。 1\ 只有一个源头 维护了一个 ~/Projects/cc-skills/，60+ skills，实验性质的不在这。改只在这里改，别处都是副本。 2\ 分发交给脚本 有个 sync.ts 脚本，底下是 rsync -av --delete，支持 local 和 ssh，推送到全局、多个项目和远程机器（比如在 macmini 上部署了 hermas 或 openclaw，只需要部分 skill）。 3\ 默认 .claude/skills，其余软链过去 通过软链支持不同的 Qoder 和 Codex 等，比如 ~/.agents/skills -> ~/.claude/skills，~/.qoder/skills -> ~/.claude/skills。 4\ 90% 以上加 disable-model-invocation: true 我同步到 global 的 15 个里，14 个加了这个 flag。所以用 claude code 的 /doctor 分析，结果很干净。 几十个 skill 就是几十段常驻描述，活还没开始干，窗口先被咬掉一块。几千个是什么光景，可以自己想。。 而且我本来就知道什么时候该用哪个。/deslop、/handoff 我打得出来，不需要模型替我猜。 5\ 新 skill 用 create-skill 建 上面这些约定我不想每次重记一遍，全塞进这个 scaffold 里了。它建出来的 skill 就按这套走：有副作用的一律加 disable-model-invocation: true，只有规范和知识型的才留给模型自己判断。 注：我的 create-skill 开源了：https://t.co/kD46Fp0VIh
是什么 这条推文提出一套 Agent Skills 治理方法：以中央仓库作为唯一源头，用 sync.ts 配合 rsync -av --delete 分发到全局、项目和 SSH 远程机器，再用软链兼容不同 Agent 的 Skills 目录；对大多数 Skill 设置 disable-model-invocation: true，把自动发现改为显式调用。链接的 sorrycc/skills 仓库是一个以 Claude Code 插件市场分发的自定义 Skills 集合，README 目前列出 create-skill 与 karpathy-3d-story 两项，支持插件市场安装或 npx skills add。仓库元数据为 30 Stars、HTML、2026-03-23 创建、2026-08-06 最近提交。核心设计 关键不是增加 Skill 数量，而是把编写、分发、触发拆开治理：源代码集中，副本由脚本收敛，触发权交给人。create-skill 将约定前置到脚手架，降低新 Skill 的维护偏差。关键洞察 Skill 描述会持续占用上下文；规模扩大后，自动调用的便利可能转化为检索噪声与延迟。按副作用和知识型能力区分触发策略，是成本、可控性与体验之间的实用折中。边界与风险 rsync --delete 和软链要求路径、权限、平台环境稳定，误同步可能覆盖本地变更；禁用自动调用也会牺牲模型主动发现能力。README 较简洁，不能据此推断更完整的测试、版本治理或跨平台保障。