Skill 一多，新问题就不是「怎么改」，而是「谁有权改、改坏了找谁」，尤其团队的Skill管理尤其重要 。这篇文章讲治理。工具很少，规矩很多——而且这些规矩，你们仓库里其实已经有一半雏形了。

前言

一句话：让 Skill 需要治理管理工程化规范。

开场：CI 挂了，没人知道该找谁

Skill 一多，新问题就不是「怎么改」，而是「谁有权改、改坏了找谁」，尤其团队的Skill管理尤其重要 。

典型现场：有人顺手改了触发词，PR 上 regression 红了三条。 群里问「这是谁的 Skill？」——半天没人认。 最后靠 git blame 找到人，对方说：「我以为改两句 description 不用跑 eval。」

09 篇的流水线能拦住「改坏」。拦不住的是：

•没人维护的僵尸 Skill 还挂在清单里

•draft 实验品被当成正式能力推广

•Owner 离职后，下游编排器还在调用

这篇文章讲治理。工具很少，规矩很多——而且这些规矩，你们仓库里其实已经有一半雏形了。

治理要解决的三件事

问题	做法
谁负责？	一人一 Skill，写进 .skill-meta.json
能不能给别人用？	draft → beta → stable，别混着用
什么时候扔掉？	季度盘点：无 Owner、长期不用、覆盖率崩了就归档

L4 CI 解决「别改坏」。治理解决「别散架」。要做工程质量把控，不能无序无约束。

Skill Card：一张卡片说清责任

脚手架模板里，每个 Skill 都有 .skill-meta.json。别把它当成装饰字段——它就是团队契约。

最小够用的字段：

{
"skill_name":"frontend-dev-prompt-craft",
"version":"0.1.5",
"maturity":"beta",
"owner":"nathan",
"status":"active",
"updated_at":"2026-07-03T00:00:00Z"
}

编排器再多写上下游，例如 wechat-review-pipeline 会声明子技能、toolchain。 个人 Skill 先把 owner + maturity + status 填实，比写一堆空字段有用。

Owner 到底干什么

不是挂名。三件实事：

1.改之前：写假设、跑基线（09 那套）

2.用之后：高频问题进 skill-issues.jsonl，该转 eval 就转

3.每季度：参加盘点，决定晋级还是归档

没有 Owner 的 Skill = 待退役候选。 不是立刻删，是进盘点名单。

换人怎么换

情况	建议
Owner 离职	优先让下游 Skill 的 Owner 接手；接手前跑一遍 regression
暂时没空	可加 co-owner 帮忙审 PR，但 owner 字段别偷偷改
两个 Skill 合并	新目录、新 Owner，别继承一笔糊涂账

co-owner 可以审、可以跑回归；改 SKILL.md 仍建议 Owner approve。规矩简单，执行才省事。

Inventory：团队的 Skill 资产表

你们仓库里已经有一份活的清单：skills/skills-quality/skill-inventory.md。

它现在长这样（节选）：

Skill	定位	当前状态	下一步
pm-md-to-openspec-pipeline	编排器	L3 ready	跑 pipeline baseline
loop-engineering	闭环工程文档	L3 ready	live eval 补跑
frontend-dev-prompt-craft	前端提示词	（见 meta）	自进化 backlog
grill-me	对抗审查	L3 ready	grill-001～006

清单不需要漂亮。需要每周还能信。

更新节奏建议：

时机	做什么
新建 / 改名 Skill	当天登记
maturity 变更	当天改一行
每周 Review	扫一遍 status、Owner 是否空缺
季度 Stocktake	淘汰、晋级、换 Owner

Inventory 失效的征兆很明确：表上 20 个 Skill，真正有人用的不到 5 个，还没人敢删。

发布阶梯：draft / beta / stable

别「写完 SKILL.md 就算发布」。三级就够：

级别	什么意思	最低条件
draft	个人实验	有 SKILL.md；不保证稳定
beta	可以给同事试用	eval 覆盖够用；有 baseline 记录
stable	团队正式依赖	CI / 回归门禁能拦住 high；连续一段时间没被自己改崩

升级不是仪式，是证据：

draft → beta
  补 eval（至少盖住 high 风险场景）
  跑通一次 baseline，写入 results.tsv
  Owner 在 Review 里点头

beta → stable
  回归门禁接入（至少 high risk 必阻）
  一段时间里改动都过得了棘轮
  Inventory 与 .skill-meta.json 同步改 maturity

降级也要敢做：

•stable 连续被 regression 打脸 → 先降回 beta，修完再升

•beta 长期没人用、也没人补 eval → 降 draft 或直接进淘汰候选

draft 被误用是团队推广期最高频事故。解法很土：在 Inventory 和触发说明里写清楚「draft，勿当正式能力」；稳定前不要写进编排器默认路径。

季度 Stocktake：盘点，不是开会表演

议程可以短：

1.Inventory 汇览：active / deprecated / archived 各多少

2.淘汰候选：无 Owner、长期无调用、覆盖率崩了的

3.晋级候选：beta 里证据够的升 stable

4.Owner 交接

5.下季度只定 3 个目标（别定 15 个）

淘汰规则不必精确到算法，但要有默认值，例如：

条件	动作
无 Owner，且很久没人用	deprecated → 观察期 → archived
有 Owner，但 high regression 反复挂	警告 + 修复计划；再挂就降级
纯实验、已有替代 Skill	直接 archived，仓库保留历史

archived 不是删除。 目录留着，Inventory 移出「在用」区。以后要考古，git 还在。

盘点输出三样就够：stocktake-summary-Qx.md、更新后的 Inventory、各 Skill 的 meta。

一个更老实的推广预期

旧稿里写过「90 天 15 个 stable」。当激励可以，当承诺容易打脸。

更贴近真实仓库的节奏是：

阶段	大概在干什么	更现实的产出
前 30 天	把正在用的 Skill 补 meta + inventory	3～5 个 beta，Owner 齐
30～60 天	1～2 个接回归门禁	出现第一个 stable
60～90 天	自进化跑通 1 个案例 + 清僵尸	stable 缓慢增加，而不是冲数量

你们现在的 inventory 里，大量是 L3 ready——有 eval、能跑 baseline。 这已经比「文件夹里一堆 SKILL.md」强一个数量级。 治理的下一步不是堆 Skill，而是：把 L3 里真正高频的那几个，推到有门禁的 beta/stable。

新人改 Skill 的默认路径

写进团队约定，比写进文章更有用：

提 PR
  → Owner（或 co-owner）review
  → 改动触及 Skill 目录则跑 grade_evals / check_regression
  → 过了再合
  → 合入后改 CHANGELOG + meta.updated_at

「我只改了一句 description」——也算改动。触发词一变，误触发成本是全团队的。

这个对于内容文本创作者，或者AI改文章，改资讯信息的来说，改动Skill之后，会存在AI改文章之后的产物会很奇怪，有时候发现AI改文章之后的产物跟之前的一样，有时候发现改的面目全非。

读完先做这三件

1.打开 skills-quality/skill-inventory.md，给每个在用 Skill 补上（或核对）Owner

2.扫一遍 .skill-meta.json 的 maturity，draft / beta / stable 别再混用

3.约一次 45 分钟盘点：只决定「淘汰谁、谁升 beta、谁缺 Owner」

总结

本篇只记住三件事：

1.一人一 Skill：Owner 写进 .skill-meta.json；没人认领的，进退役候选，而不是继续躺在清单里装活跃。

2.draft / beta / stable 分开用：实验品别当正式能力推广；升级靠证据（eval、基线、门禁），降级也要敢做。

3.季度盘点清僵尸：Inventory 要能信；治理的目标不是堆数量，而是把高频 L3 推到有门禁的 beta/stable。

有计划有规律的进行把控Skill ，适合团队 Skill 治理，如果是存粹的个人Skill 治理，我认为也是需要这样的。

这个只是我认为的Skill 治理方法论。

也非常适合工程化管理团队/个人 Skill。