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 baselineloop-engineering闭环工程文档L3 readylive eval 补跑frontend-dev-prompt-craft前端提示词见 meta自进化 backloggrill-me对抗审查L3 readygrill-001006清单不需要漂亮。需要每周还能信。更新节奏建议时机做什么新建 / 改名 Skill当天登记maturity 变更当天改一行每周 Review扫一遍 status、Owner 是否空缺季度 Stocktake淘汰、晋级、换 OwnerInventory 失效的征兆很明确表上 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 里证据够的升 stable4.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 inventory35 个 betaOwner 齐3060 天12 个接回归门禁出现第一个 stable6090 天自进化跑通 1 个案例 清僵尸stable 缓慢增加而不是冲数量你们现在的 inventory 里大量是L3 ready——有 eval、能跑 baseline。 这已经比「文件夹里一堆 SKILL.md」强一个数量级。 治理的下一步不是堆 Skill而是把 L3 里真正高频的那几个推到有门禁的 beta/stable。新人改 Skill 的默认路径写进团队约定比写进文章更有用提 PR → Owner或 co-ownerreview → 改动触及 Skill 目录则跑 grade_evals / check_regression → 过了再合 → 合入后改 CHANGELOG meta.updated_at「我只改了一句 description」——也算改动。触发词一变误触发成本是全团队的。这个对于内容文本创作者或者AI改文章改资讯信息的来说改动Skill之后会存在AI改文章之后的产物会很奇怪有时候发现AI改文章之后的产物跟之前的一样有时候发现改的面目全非。读完先做这三件1.打开skills-quality/skill-inventory.md给每个在用 Skill 补上或核对Owner2.扫一遍.skill-meta.json的maturitydraft / beta / stable 别再混用3.约一次 45 分钟盘点只决定「淘汰谁、谁升 beta、谁缺 Owner」总结本篇只记住三件事1.一人一 SkillOwner 写进.skill-meta.json没人认领的进退役候选而不是继续躺在清单里装活跃。2.draft / beta / stable 分开用实验品别当正式能力推广升级靠证据eval、基线、门禁降级也要敢做。3.季度盘点清僵尸Inventory 要能信治理的目标不是堆数量而是把高频 L3 推到有门禁的 beta/stable。有计划有规律的进行把控Skill 适合团队 Skill 治理如果是存粹的个人Skill 治理我认为也是需要这样的。这个只是我认为的Skill 治理方法论。也非常适合工程化管理团队/个人 Skill。