yao-meta-skill: a governed lifecycle for reusable agent skills

The problem yao-meta-skill targets

Most agent skills start as a prompt that worked once. Someone pastes it into a chat, it produces a good result, and it gets saved as a Markdown file. The trouble begins when a second person installs it. There is no statement of what the skill expects as input, no record of which model or client it was tried against, and no way to tell whether a later edit broke a trigger. The README frames the 1.0 line as turning repeated workflows into installable, readable, cross-platform skill packages, and the 2.0 line as expanding that into what it calls a Skill OS: modeling a skill once, compiling it for multiple targets, testing behavior, reviewing release evidence and tracking the next iteration. The intended audience is therefore not the individual prompt tinkerer. It is the maintainer who owns a skill that other people depend on, and who has to answer questions about portability, permissions and whether a release is safe.

Skill IR and the target compilers

The central design decision in 2.0 is to stop treating SKILL.md as the source of truth. Instead the repository introduces a Skill IR, described as a platform-neutral intermediate representation covering intent, triggers, inputs, outputs, boundaries, references and expected artifacts. Target compilers and adapters then generate surfaces for OpenAI, Claude, generic agent skills, Agent Skills compatible packages and VS Code-oriented workflows. That is a compiler model applied to prompts, and it has a predictable consequence: the IR becomes the artifact you maintain, and the per-platform files become build output. It also means the IR has to be expressive enough to survive translation. The README does not publish the IR schema in the material available here, so whether the abstraction holds up across all five named targets is something you would need to check in the repository before relying on it. The 1.0 architecture is listed as SKILL.md, agents/interface.yaml, manifest files and report artifacts, so existing packages have a defined shape to migrate from.

Evaluation evidence and the release gate

The Output Eval Lab is where the project draws its line between a skill that seems fine and a skill that has been checked. The README lists trigger checks, output assertions, execution evidence, timing and token evidence, benchmark reproducibility, blind-review packs, answer keys and adjudication reports. Review Studio 2.0 is a single HTML gate page that collects intent, triggers, output eval, context cost, runtime checks, trust, Skill Atlas signals, adoption drift, waivers, annotations, release evidence, warnings, blockers and fix actions. The important detail is the posture statement: provider-backed production evidence, human blind-review evidence, native permission execution and real-client telemetry are tracked as separate evidence tasks rather than treated as completed work. Read that literally. The gate exists, the evidence slots exist, and some of them are empty by the maintainer's own account. A gate with unfilled evidence fields is a checklist, not a proof, and anyone adopting this should treat the empty slots as the real state of the project.

Getting it running

The repository ships a CLI at scripts/yao.py, and the README presents three read-only operator commands as the entry point. The first is python3 scripts/yao.py install-status --expected-source . which reports whether the active skill is coming from .codex/skills, .agents/skills or the disabled mirror, and flags duplicate active installs. The second is python3 scripts/yao.py localized-doc-sync-check which verifies that the Chinese README carries the public homepage sections added to the English README. The third is python3 scripts/yao.py pr-review-report 4 --repo yaojingang/yao-meta-skill. All three are described as diagnostics rather than generators, which is a sensible first contact: you can inspect an existing installation before you commit to producing anything. The README does not, in the material available, give the command that creates a skill from a workflow note or the command that runs the target compilers. That gap matters if you are evaluating setup cost, because the creation path is the part you would actually use daily.

Where this is the wrong tool

The 2.0 lifecycle assumes a skill will be installed by someone other than its author. If that assumption is false, the machinery is overhead. A Skill IR, compiler targets, evidence consistency checks, release locks, install simulation and runtime permission probes all exist to protect a boundary between author and consumer. For a personal skill that lives in one directory and is edited in place, the IR becomes a second file to keep in sync with the first, and the eval lab asks for evidence about a trigger you already know works. The README itself concedes the point indirectly in its comparison use case, saying that Anthropic and OpenAI style conversational creation and lean instruction writing should be kept where they fit. There is also a maturity caveat: the maintainer describes the repository as ready for beta and external testing, with stronger public claims remaining evidence-gated. Beta means interfaces can move, and a system whose value is a stable evidence format is exposed to exactly that kind of churn.

How it differs from conversational skill creation

The obvious alternative is the conversational route: describe the workflow to a model, let it write the skill file, and iterate by chatting. That approach is faster to first result and requires no intermediate representation, no compiler and no gate page. The difference is what survives the session. Conversational creation produces a file; yao-meta-skill produces a package plus a record of what was checked, which the README calls evidence consistency checks, package verification, install simulation and runtime permission probes. The trade is legibility for cost. A conversational skill has no artifact that states its triggers and boundaries in a form a compiler can read, so porting it to a second client means rewriting it by hand. The IR approach makes that port a build step. Neither is strictly better; they answer different questions. Conversational creation answers can I get this working, and yao-meta-skill answers can I hand this to someone else and defend the release.

Maintenance, licence and what to verify

The repository is licensed MIT, which permits commercial use, modification and redistribution provided the licence text is retained. That is a permissive baseline with no copyleft obligation, and it is a low-friction choice for a tool meant to be embedded in other teams' workflows. This is a description of the licence terms, not legal advice; if you redistribute the tool inside a product, have your own counsel confirm the notice requirements. On maintenance, the README describes a SkillOps loop with metadata-only adoption drift, telemetry hooks, adaptive proposals, daily and weekly curator reports and portfolio-level drift signals. Those are recurring jobs, and recurring jobs are recurring cost. Before adopting, check whether the drift and curator reports run from a scheduler you would have to host, and confirm the state of the four evidence tasks the maintainer lists as open. The honest summary is that this is a governance framework whose governance is partly aspirational, and the gap between the two is the thing to measure first.

Editorial conclusion

Adopt yao-meta-skill if you already maintain skills that other people install and you need a repeatable record of what was tested before release. Do not adopt it for a single personal prompt you iterate on alone, because the Skill IR, compiler and evidence steps cost more than the skill is worth. Before committing, run python3 scripts/yao.py install-status --expected-source . to confirm the active skill resolves from .codex/skills or .agents/skills without a duplicate install, then read the evals and failures directories to see how much of the evidence pipeline is populated rather than declared.

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. yaojingang/yao-meta-skill on GitHub