一句话结论：当 Skill 从几个变成几百个，它就不再是"个人收藏"，而是一个需要治理的组织资产。命名冲突、版本漂移、权限失控、重复造轮子、找不到该用哪个——这些问题的解决，不靠自觉，靠制度与工具。

引言：从个人技巧到组织资产

一个人维护三个 Skill 没问题。一百个人维护一千个 Skill，问题立刻浮现：两个团队做了功能一样的东西、同名 Skill 互相覆盖、某个 Skill 悄悄有了写权限、新人找不到现成能力只能再造一个。治理就是让这一切可控。

一、治理要解决的五个问题

二、命名与命名空间

• 用命名空间隔离：team/domain/action 的层级，避免全局重名。

• 名字携带语义：动宾结构，别用 tool1、helper。

• 建立命名评审：新增 Skill 前先查目录，避免重复。

三、版本与生命周期

• 语义化版本：破坏性变更加主版本，行为变更加次版本，修正加修订号。

• 变更记录：每个版本记录改了什么、为什么（呼应 AGENTS.md 的"可审计"精神）。

• 废弃流程：Skill 要能优雅下线——标记废弃、给迁移期、再移除。别直接删导致下游炸。

• 灰度：重要 Skill 的更新先小范围验证再全量。

四、权限与安全治理

• 权限声明：每个 Skill 明确声明它需要什么权限（读/写/网络/凭证）。

• 最小授权：按声明授予，超出即拒绝。

• 定期审计：定期复查"权限是否仍需要"，防止权限蔓延。

• 来源可信：第三方 Skill/工具要有审计与准入（呼应安全篇与 MCP 篇）。

五、可发现性与复用

• 可检索目录：统一的 Skill 索引，支持按名称、标签、能力检索。

• 元数据完备：每个 Skill 有描述、标签、作者、维护者、适用范围。

• 推荐复用：新需求先查目录，能找到就复用而非重造。

• 定期清理：僵尸 Skill（无人维护、无人使用）要归档，避免噪音。

六、质量门槛

• 准入标准：新 Skill 要满足检查单（原子、有示例、有失败路径等）才能进入目录。

• 定期复评：过期的 Skill 重新评估，或标记为待废弃。

• 度量：使用频次、成功率、成本，作为治理决策依据（呼应可观测篇）。

七、常见误区

• 无命名空间：全局同名，互相覆盖。

• 无版本无变更记录：无法回答"上周它是什么行为"。

• 权限无声明无审计：Skill 悄悄拥有它不该有的能力。

• 没有目录：重复造轮子，团队效率被内耗吃掉。

• 只增不删：Skill 库膨胀成垃圾场，检索命中率下降。

• 第三方无准入：供应链风险直接进入生产。

• 治理靠自觉：没有工具与流程，规范形同虚设。

八、检查单

• [ ] Skill 有命名空间与命名规范

• [ ] 语义化版本 + 完整变更记录

• [ ] 有废弃与迁移流程

• [ ] 重要变更可灰度

• [ ] 每个 Skill 声明权限，按最小授权

• [ ] 权限定期审计，防蔓延

• [ ] 有可检索的 Skill 目录与完备元数据

• [ ] 有准入检查单与定期复评

• [ ] 有使用与质量度量，驱动治理决策

• [ ] 第三方 Skill/工具经审计准入

• [ ] 僵尸 Skill 定期归档清理