源项目： yaojingang/yao-meta-skill

核心入口： SKILL.md

项目作者： Yao Team / yaojingang

评测对象定位： 一个面向 Agent Skill 创建、评审、测试、打包、治理和跨平台迁移的 Meta Skill / Skill OS。

评测说明： 本文基于项目公开 README、SKILL.md、AGENTS.md、方法论文档、Eval 文档和 Manifest 信息进行评测，未实际运行其完整脚本链路。

Yao Meta Skill 把 Skill 从提示词文件升级成可创建、可评审、可验证、可治理的工程资产。

Matt 解决什么是好 Skill，Codex 解决怎么创建 Skill，Yao 解决怎么把 Skill 工程化管理。

一句话结论

yao-meta-skill 不是一个普通 Skill Creator，而是一个接近 Skill OS 的工程化系统。

如果说 Matt Pocock 的 writing-great-skills 是 Skill 设计哲学，Codex 的 $skill-creator 是 Skill 创建器，那么 yao-meta-skill 更像是把 Skill 当成工程资产来管理的一套操作系统。

它的核心价值不是“帮你快速写一个 SKILL.md”，而是回答一个更大的问题：

当 Skill 从个人 prompt 文件，变成团队和组织依赖的能力资产时，它应该如何被建模、评审、测试、打包、发布、治理和持续迭代？

这也是它最值得被单独评测的原因。

一、基础信息

yao-meta-skill 的项目说明里写得很清楚：YAO 代表 Yielding AI Outcomes，目标不是生成更多 prompt text，而是生产可复用的 AI 资产和真实运营结果。项目能力覆盖 reusable agent skills 的创建、评估、打包和治理；其 2.0 版本进一步扩展为 Skill OS，强调 skill modeling、multi-target compiling、behavior testing、release evidence 和 iteration tracking。

从仓库结构看，它已经不是一个单文件 Skill，而是一个完整工程仓库。项目包含 agents、assets、docs、evals、references、registry、reports、runtime/conformance、schemas、scripts、security、skill-ir、skill_atlas、templates、tests 等目录。

它的 manifest.json 也能看出定位：项目状态是 active，成熟度标记为 governed，生命周期阶段是 library，目标平台包括 openai、claude、generic、agent-skills-compatible 和 vscode。

所以，这不是一个“教你写 Skill”的小工具，而是一个面向 Skill 工程化的完整系统。

二、基础评分

评测维度评分判断
Skill 方法论完整度9.2 / 10覆盖创建、评审、治理、发布、迭代，体系完整
工程化程度9.4 / 10有 scripts、evals、reports、registry、security、Skill IR、测试体系
可执行性8.7 / 10有大量 CLI、测试和报告生成脚本，但上手成本较高
上下文控制8.5 / 10根 SKILL.md 很克制，深度内容外置
可读性 / 上手体验7.2 / 10概念密度很高，新用户容易被治理体系吓到
对 Agent 产品的参考价值9.3 / 10非常适合作为 Skill 工程化范式案例
综合评分8.9 / 10社区里少见的 Skill OS 化探索，强但偏重

一句话评价：

这是一个强项目，但不是轻项目。
它适合被研究、拆解、借鉴，不适合所有人直接照搬。

三、它最强的地方：把 Skill 从文件变成系统

很多 Skill 项目本质上还是一个 SKILL.md 文件，加上一些参考说明。

但 yao-meta-skill 的思路明显不同。

它的根 SKILL.md 非常短，核心 description 是：从 workflows、prompts、SOPs、scripts 中创建、改进和评估 agent skills；适用于 migration、release、package、routing、evals/tests、install checks，以及优化已有 skill、补 trigger 评测；同时排除 summary、translation、docs 这类不需要生成 skill 的任务。

更关键的是，它在根 SKILL.md 里明确规定：

Keep SKILL.md lean;
put guidance in references/;
logic in scripts/;
evidence in reports/.

也就是说，主入口只负责触发、边界和紧凑工作流；方法论放到 references/，确定性逻辑放到 scripts/，证据和报告放到 reports/。

这正好符合高质量 Skill 的基本原则：

入口要轻，深度要外置，执行要工具化，证据要报告化。

它的 AGENTS.md 也进一步确认了这个工程分层：SKILL.md 是 public trigger surface 和 compact workflow；references/ 是稳定方法论；scripts/ 是执行逻辑、报告生成器、编译器和 gates；evals/ 是 trigger、output、packaging、semantic 和 regression fixtures；security/ 是脚本、依赖、网络、权限和信任策略；registry/ 是包元数据、安装证据和兼容性元数据；reports/ 是生成的 review、trust、conformance、registry、overview 和 release evidence。

这已经不是普通 Skill，而是一个 Skill 工程仓库模板。

四、它的核心方法：先判断要不要 Skill 化

yao-meta-skill 最值得学习的一点，是它没有默认“万物皆 Skill”。

它的方法论文档把第一步定义为：先判断这个请求到底应不应该变成 Skill。只有当 workflow 会被复用、容易被错误路由、确定性脚本能减少重复劳动，或者治理和可移植性重要时，才值得升级成 Skill。反过来，如果只是解释、总结、翻译、头脑风暴、一次性回答，或者没有 agent execution 的普通文档任务，就不应该创建 Skill。

这个判断非常重要。

因为现在很多人做 Agent Skill，容易犯一个错误：

看到一个任务，就想沉淀成 Skill。
看到一个流程，就想包装成 Skill。
看到一个 prompt，就想纳入 Skill Registry。

但真正高质量的 Skill，不应该是内容归档，而应该是可复用的行为资产。

所以，yao-meta-skill 给出的第一原则可以总结成：

只有重复、可路由、可评估、可沉淀的工作流，才值得 Skill 化。

这个原则比“怎么写 Skill”更重要。

五、四种成熟度模式：Scaffold / Production / Library / Governed

yao-meta-skill 把 Skill 分成四种模式：

模式适合场景核心判断
Scaffold个人探索、短期使用不要过度治理
Production团队复用、质量敏感加 trigger eval 和资源边界检查
Library组织共享、长期维护加包装、兼容、治理、回归证据
Governed高信任、发布关键、合规相关加 trust/security、runtime permission、Review Studio、claim guard

它的 Operating Modes 文档讲得很清楚：Scaffold 适合探索性、个人化、短期 Skill；Production 适合团队复用和质量敏感工作流；Library 适合组织重要、广泛共享、需要维护和可移植性的 Skill；Governed 适合 incident、release、compliance、security 或组织标准相关的高风险场景。

这个设计非常高级。

因为不同阶段的 Skill，不应该承担同样的工程成本。

一个个人 Skill 只需要跑通，不需要完整治理。 一个团队 Skill 需要稳定，不一定需要公共证据链。 一个组织级 Skill 需要可维护、可迁移、可审计。 一个高信任 Skill 则必须有权限、安全、回滚、证据和发布边界。

更重要的是，它明确说：

a mode upgrade does not justify a larger SKILL.md

也就是说，模式升级不应该让 SKILL.md 变得更臃肿；更高的 rigor 应该主要增加 references、reports、evals 和 metadata，而不是增加初始上下文负担。

这句话非常关键。

很多团队一做“生产级”，就把主文档写得越来越重。 yao-meta-skill 的思路是反过来的：

生产级不是入口更重，
而是证据、测试、治理和边界更强。

六、Skill IR：平台无关的中间表示

yao-meta-skill 2.0 的一个重要升级，是提出 Skill IR。

README 里把 Skill IR 定义为一种平台中立的 intermediate representation，用来描述 intent、triggers、inputs、outputs、boundaries、references 和 expected artifacts。它还支持 target compilers 和 adapters，可以面向 OpenAI、Claude、generic agent skills、Agent Skills compatible packages 和 VS Code-oriented workflows 生成不同目标表面。

这个方向非常重要。

未来 Skill 一定会面对多平台问题：

  • OpenAI 有自己的 Skill / Agent 生态；
  • Claude 有自己的 Skills 生态；
  • IDE Agent 有自己的上下文和权限模型；
  • 企业内部 Agent 平台也会有自己的插件协议；
  • 不同平台对工具权限、上下文加载、文件结构、分发格式的要求都不一样。

如果每个平台都手写一套 Skill，就会很难维护。

yao-meta-skill 的思路是：

先建一个平台中立的 Skill IR，
再编译到不同目标平台。

这非常像软件工程里的：

Source Model → Compiler → Target Runtime

这可能是 Skill 生态未来最重要的方向之一。

七、Eval Lab：不只测触发，还测输出质量

yao-meta-skill 另一个很强的地方，是它把 Skill Eval 做得很系统。

它的 Output Eval Method 明确说，Output Eval Lab 证明的是：Skill 是否改善了最终用户可见结果，而不只是是否正确路由。生产级、Library、Governed 或团队分发型 Skill 都应该使用 output eval；Scaffold 可以先从一个 smoke case 开始，但 Production 以上应该证明 with-skill 相比 baseline 有正向信号。

这点非常关键。

很多 Skill 的评估只停留在：

Agent 是否调用了这个 Skill？

但真正重要的是：

调用 Skill 后，最终结果有没有更好？

它要求每个 eval case 包含真实 prompt 或任务形态、必要输入文件、baseline output、with-skill output、可检查 assertions，以及可选 human review notes。它还强调，assertions 不应该只奖励措辞复读，而要捕捉真实质量。

这已经很接近真正的 Agent Skill Eval。

更重要的是，它还设计了 blind A/B review：每次 output eval 都应该生成 blind review pack 和单独的 answer key，review pack 要隐藏 Variant A / B 分别来自 baseline 还是 skill-guided output。

这说明它不是只做自动化格式检查，而是在尝试建立：

baseline 对比
  ↓
with-skill 输出
  ↓
断言评分
  ↓
盲审
  ↓
人工裁决
  ↓
证据沉淀

这是 Skill 从“感觉更好”走向“证据更好”的关键一步。

八、Promotion Policy：防止 description 过拟合和路由污染

Skill 一多，最大的问题不是单个 Skill 不好用，而是 Skill 之间会互相污染。

最常见的问题是：

一个 Skill 的 description 写得太宽，
结果它偷走了其他 Skill 的任务。

yao-meta-skill 的 Promotion Policy 就是在防止这个问题。

它明确区分 dev ranking、visible holdout、blind holdout、adversarial holdout、route confusion gate 和 family stability。文档强调，dev 只能用来排序候选项，不能单独授权 promotion；真正的 promotion 需要 visible / blind / adversarial holdout 不回退，并且 route confusion 保持干净。

它还明确规定，当候选项只在 dev 上更好、holdout gate 回退、route confusion 变得模糊时，应该保留当前版本；如果 adversarial risk 进入 overlap、偷走 sibling route，或者 no-route prompt 开始进入该 Skill，就应该 block promotion。

这比一般的 description 优化高级得多。

它本质上是在说：

Skill description 不是文案，
而是路由边界。

而路由边界必须经过测试，不能只靠感觉。

九、安全与信任：把 Skill 当成可执行资产

yao-meta-skill 有独立的 security/ 目录，项目说明和 AGENTS.md 也都强调安全、依赖、网络、权限和信任策略。

这背后有一个重要判断：

Skill 不是普通文档；
Skill 是会影响 Agent 行为的可执行资产。

一旦 Skill 可以携带 scripts、references、assets、metadata，并且能影响 Agent 的路由和执行，它就进入了软件供应链的范畴。

所以，团队级 Skill 系统必须考虑：

  • 脚本是否执行危险命令；
  • references 是否夹带注入指令；
  • assets 是否含有隐藏 payload；
  • Skill 描述是否故意扩大触发范围；
  • 是否请求了不必要的工具或权限；
  • package hash、registry metadata、install simulation 是否可验证；
  • public claim 是否有证据支持；
  • 高风险 Skill 是否有 owner、review cadence、rollback boundary。

yao-meta-skill 对这些问题的重视，是它区别于普通 Skill Creator 的重要地方。

十、主要问题：体系太重，上手成本高

yao-meta-skill 最大的问题不是能力不足，而是能力太多。

它包含 Skill IR、Compiler、Eval Lab、Review Studio、Evidence Ledger、Claim Guard、SkillOps、Telemetry、Adoption Drift、Registry Audit、Package Verification、Runtime Permission Probe、World-class Evidence Intake 等大量模块。

这些对组织级 Skill OS 很有价值，但对普通用户来说，上手门槛很高。

它容易给人一种感觉：

我只是想写一个 Skill，
你却给了我一套治理平台。

这不是坏事，但会影响传播和使用。

所以我的判断是：

用户类型是否适合直接使用
个人写小 Skill不适合全量使用
团队沉淀可复用 Skill适合借鉴核心流程
企业建设 Skill Registry很适合研究
做 Agent 产品平台非常值得拆解
写轻量 Skill Creator不建议照搬

这个项目的价值更像是“上限样板”，不是“新手模板”。

十一、第二个问题：产品入口还可以更轻

根 SKILL.md 已经很克制，这是优点。

但项目整体概念密度仍然很高。普通用户第一次进入项目，很容易不知道该从哪里开始：

我现在应该用 Scaffold 还是 Production？
我只是想改一个 description，需要跑哪些检查？
我不需要 Governed，还要看这些 evidence 吗？
我想做一个轻量 Skill，哪些模块可以跳过？

我建议它未来可以增加一个更轻的入口分流：

你现在是哪一种？

A. 我只是想快速创建一个个人 Skill
B. 我想把团队工作流沉淀成可复用 Skill
C. 我想评审 / 优化已有 Skill
D. 我想把 Skill 做成跨平台包
E. 我想建设 Skill Registry / 治理体系

每条路径只给最小命令、最小产物和最小 gate。

这样会显著降低认知负担。

十二、第三个问题：公开 Claims 要更谨慎

README 里提到，项目当前 posture 是 ready for beta and external testing，但更强的 public “world-class” claims 仍然需要 evidence-gated；provider-backed production evidence、human blind-review evidence、native permission execution 和 real-client telemetry 被作为单独 evidence tasks 跟踪，而不是当作已完成工作。

这个表述是比较谨慎的。

但从传播角度看，凡是涉及 benchmark、world-class、quality score、对比其他 meta-skill 的表达，都容易被读者质疑：

这是第三方 benchmark，还是自建标准？
是真实用户数据，还是本地工程证据？
是已完成能力，还是 evidence plan？

更稳妥的表达方式应该是：

它具备更完整的工程证据链，
但是否优于其他 creator，需要第三方 benchmark、真实用户任务和盲审结果继续验证。

这不会削弱项目价值，反而会增强可信度。

十三、和前面两个 Skill 的关系

如果把它和前面评测过的两个方向放在一起，可以很清楚地看到三者关系：

项目本质最强点最大短板
Matt writing-great-skillsSkill 设计哲学Predictability、信息分层、completion criteria不够执行化
Codex $skill-creatorSkill 创建工具从真实工作流生成 Skill评审、治理、Eval 不够完整
yao-meta-skillSkill 工程系统创建、评审、Eval、治理、跨平台、证据链重，学习成本高

一句话：

Matt 解决“什么是好 Skill”；
Codex 解决“怎么创建 Skill”；
Yao 解决“怎么把 Skill 工程化管理”。

这也是为什么 yao-meta-skill 很值得研究。

它不是取代前两者，而是把前两者的讨论推进到了系统层。

十四、对 Agent 产品的启发

我认为 yao-meta-skill 最值得吸收的，不是它全部的治理模块，而是这五个设计原则。

1. 先判断要不要 Skill 化

不是所有任务都值得变成 Skill。 只有重复、可路由、可评估、可沉淀的工作流，才值得 Skill 化。

2. 根 SKILL.md 必须保持轻

入口只放触发、边界和 compact workflow。 方法论放 references，确定性逻辑放 scripts，证据放 reports。

3. Skill 要分成熟度

个人探索、团队复用、共享基础设施、高信任治理，不应该使用同一套成本结构。

4. Eval 要分两层

不仅要测是否触发，还要测输出是否比 baseline 更好。

5. Skill Registry 必须防止路由污染

一个 Skill 写得太宽，会偷走其他 Skill 的任务。 所以需要 holdout、adversarial、route confusion 和 promotion policy。

十五、最终结论

yao-meta-skill 是一个很强的项目，甚至可以说它基本把 Skill 工程闭环做出来了：

Create
  ↓
Review
  ↓
Rewrite
  ↓
Eval
  ↓
Package
  ↓
Govern
  ↓
Operate

它的价值不在于“帮你快速写一个 Skill”，而在于提出了一个完整问题：

当 Skill 从个人 prompt 文件，变成团队和组织依赖的能力资产时，它应该怎么被建模、评审、测试、打包、分发、治理和迭代？

这是它真正的高度。

但它也不是所有人都应该直接照搬的方案。 对个人和小团队来说，它太重；对 Agent 产品平台和企业级 Skill Registry 来说，它非常值得拆解。

我的最终判断是：

如果 Matt 的 writing-great-skills 是 Skill 设计宪法，
Codex skill-creator 是 Skill 生产工具，
那么 yao-meta-skill 就是 Skill 工程操作系统的雏形。

这也是 Agent Skill 接下来最重要的方向：

不是写更多 Skill，而是把 Skill 从 Prompt 文件升级成可创建、可评审、可验证、可迁移、可治理的工程资产。

参考来源