Skill 全生命周期编排器

> 为什么需要它：单独的「创建」「质检」「查找」工具各自能用，但没人告诉你什么时候该用哪个。
> 结果就是：重复的 skill 越建越多、装进来的 skill 从不质检、建完的 skill 从不迭代。
> 本 skill 是这条链的编排层，它不重复造轮子，只负责在正确的阶段调用正确的工具。

一、四阶段闭环

① 判定（该不该建）  →  ② 创建（怎么建）  →  ③ 质检（能不能用）  →  ④ 固化（怎么不退化）
        ↑                                                                      │
        └──────────────────────  ⑤ 迭代（发现更好的做法）  ←──────────────────┘

二、阶段① 判定：先查重，再动手（最常被跳过的一步）

🔴 不查重就建 = 制造技术债。常见后果：三个 skill 干同一件事、触发词互相打架、
用的时候不知道该调哪个。

机械判据：

1. 用 find-skills 按「场景」搜一次（不是按关键词）
2. 命中已有 skill ⇒ 逐条比对覆盖范围
   ├─ 完全覆盖      ⇒ 🚫 不建（直接用已有的）
   ├─ 部分覆盖      ⇒ ⚠️ 只建「差异层」，并在新 skill 里写明与旧 skill 的分工
   └─ 确无覆盖      ⇒ ✅ 可以建
3. 若选择"部分覆盖也重建一遍" ⇒ 必须同时给出「旧 skill 的处置方案」（删/合并/降级）

> 🩸 血证：某系统 23 个漫剧 skill 里，剧本类 ×2、提示词类 ×3 功能重叠 ——
> 建的时候每个都"有理由"，合起来就是"不知道该用哪个"。查重成本 5 分钟，去重成本 5 小时。

三、阶段② 创建：选对模板

创建时必须同时产出三件东西（少一件就不算完成）：

1. frontmatter：name + description（description 里必须含触发词，否则不会被命中）
2. 触发判据：明确写「用户说什么话时该用它」
3. 验收标准：怎么知道它跑对了（可核对，不是「感觉还行」）

四、阶段③ 质检：装机前必过

🔴 任何从外部（GitHub / 技能市场 / 他人分享）来的 skill，未经质检不得安装运行。

必查五项：

> ⚠️ 「无许可」是最容易被忽略的一条：作者主观愿意分享，不等于你获得了法律许可。
> 权利状态不明 = 不进生产环境、不进商业包。
>
> 💡 若需要更系统的审查协议，可另行安装 skill-vetter（ClawdHub）作为外部依赖 ——
> 注意：它是独立第三方组件，许可状态不明，请自行评估后决定是否使用。

五、阶段④⑤ 固化与迭代：防止"修了就忘"

🔴 判定是否真的「固化」只有一个标准：

> 换一个会话（甚至换一台机器），它会不会被自动读到？
> 不会 ⇒ 不算固化，只是一次性动作。

载体分工（不同的东西落进不同的地方）：

迭代原则（加一减一）：修完一个问题，必须同时：
1. 落进上表某个载体（+1）
2. 压掉一个已失效/重复的旧条目（−1）

报出 +N / −M。只加不减 ⇒ 载体膨胀 ⇒ 最终没人读 ⇒ 等于没固化。

六、一句话总纲

> ① 先查重再动手（防技术债）→ ② 建完必须能验收（防自嗨）→
> ③ 外来必检（防事故）→ ④ 固化判据是「换会话还能自动读到吗」（防遗忘）→
> ⑤ 加一必减一（防膨胀）。

七、相关组件