文档

文档

Skill Wiki 文档

Skill Wiki 把一项 skill 从整块 SKILL.md 改写成一座 带类型的原子 wiki —— 每个原子可寻址、按边相连、按需取用。

三个核心概念

带类型的原子

每一条知识都是一个原子，而且每个原子必须挑明自己是哪种类型 —— 一条 rule、一种 pattern、一个 value、一项 fact、一处 tradeoff……规范里一共定义了 28 种 kind。 类型不是装饰：它告诉运行时这个原子有哪些字段、各档投影该露出哪些信息、检索该走哪条路径。 散文式的内容没有类型，这也是 SKILL.md 没法被查询的根本原因 —— Skill Wiki 把散文换成了类型。

声明式的边图

原子之间用 14 个带类型的动词串起来 —— requires、contradicts、refines、 validates-with 等等。这些边写在原子文件里，编译进 _index.xml，查询时可以沿着图遍历。Agent 拿到的不是一块铺平的文档， 而是一张图：从一个种子原子出发往外走，按 verb 与 intent 沿途裁枝。

惰性投影

一份 skill 启动时只塞给 agent 一份约 3 KB 的索引 —— 每个原子的名字、类型、边都在，但正文都不在。等到任务真的需要某个原子， 运行时才把三档投影之一送进上下文：summary（约 30 token）、 core（约 150）或 full（约 380）。Agent 只为读到的部分付费， 不为整个 corpus 的体量付费。

为什么需要它

给 agent 教一项 skill，最常见的做法就是把一整块 SKILL.md 灌进上下文。 内容只有一千 token 时还撑得住；一旦做到一万 token，整套打法就崩了： 这块大 blob 不能被查询、说不清自己内部结构、还会在 agent 真正读到关键内容前先把上下文预算耗光。 Skill Wiki 给出的回答很直接 —— 把 skill 写成由带类型、带边的原子组成的 wiki， 上来只发索引，正文按任务需要再取。

术语约定

• Prime —— 底层协议本身。一个 Prime 就是一个自包含的 @scope，里面装着带类型的原子，也是发布和安装的单位。
• 原子（Atom） —— 一个带类型的知识单元。包含 kind、domain、id、projection 层级和边。
• 边（Edge） —— 两个原子之间带类型的关系。v1 共 14 个 verb。
• Projection —— 三种 Markdown 渲染视图之一：summary（约 30 token）、core（约 150 token）、full（约 380 token）。
• Index —— 启动时 agent 加载的 _index.xml。列出每个原子；约 3 KB；不包含原子正文。