yao-open-skills: a curated catalogue of AI skills with an explicit publishing rulebook

A collection whose stated goal is to stop adding prompts

The repository is written in Chinese and its README opens with a framing decision worth translating carefully. OpenYao continues a line of method called `YAO = Yielding AI Outcomes`. The explicit intention is not to accumulate more prompt text, but to settle effective methods, processes, evaluation, aesthetic constraints and execution boundaries into reusable AI assets that ultimately produce real deliverable results.

The skills collected here target real working situations: turning uncertain decisions into reports, breaking a business question into structured analysis, producing tutorial documents from a topic, a source pack or reference material.

The repository states it does three things. It presents the public skills that have been prepared, with documentation and source entry points. It records each skill's intake path, public status and sync status. And it acts as the release entry point for later iterations, pushing confirmed updates to GitHub.

That third job is the interesting one. This is not a static dump of prompts. It is a publishing pipeline with metadata, and the difference shows up in the directory layout.

The registry is the source of truth, and the docs say so

The directory structure is small and each entry has one job, which the README spells out:

yao-open-skills/
├── index.html
├── assets/
├── README.md
├── docs/
├── registry/
├── scripts/
└── skills/

`index.html` is the HTML navigation page served through GitHub Pages, with `assets/` holding its CSS and JavaScript. `docs/` carries the repository design, publishing rules and sync conventions. `registry/` is the skill registration table, described as the source of truth for local and public status. `scripts/` holds helper scripts that update the registry and the README. And `skills/` holds the actual copies of the skills included in the public collection.

That split between `registry/` and `skills/` is the mechanism that makes the curation claim testable. If the registry is the source of truth, then a skill's presence in `skills/` without a corresponding registration entry is a gap, and the scripts that update the registry are how the two stay consistent. That is a stronger design than a directory of folders, though it also means the README is generated in part and you should trust the registry over the prose when they disagree.

For navigation, the README points first at the HTML navigation page and the skill directory index, and reserves the deeper links for people who want the methodology rather than a skill.

Four criteria that decide whether a skill may be published

The publication standards are the heart of the repository, and they are short enough to quote almost directly. A skill needs a clear topic, meaning someone seeing its name and description understands what problem it solves. It needs to be reusable, meaning it does not depend on private context on your own machine to run. It needs to be cleanable, meaning sensitive information, caches, outputs, account traces and internal documents can be removed. And it needs to be maintainable, meaning you are willing to keep fixing, iterating and explaining it.

That last criterion is the unusual one. A collection that requires an ongoing commitment from the author, stated in advance, filters differently from one that accepts contributions and hopes.

The rules are documented separately in `docs/repository-design.md`, `docs/naming-conventions.md` and `docs/publishing-rules.md`, all linked from the README. The stated repository goals reinforce the intent: turn scattered local skills into a stable public collection, keep a clear source, intake path, sync status and licence for every public skill, use one consistent screening rule so private data, output artifacts and experiment debris do not reach a public repository, and let the genuinely useful skills accumulate into a public asset library that keeps evolving.

The licensing picture is simple: the repository carries an MIT `LICENSE` at the top level. That covers the catalogue infrastructure, and it is worth checking separately whether each individual skill carries its own terms before you reuse one commercially.

Fourteen published skills, from decision diagnosis to security review

The published documentation index lists fourteen skills, and they are more varied than a name like a prompt collection suggests. There is `yao-crux-skill` for diagnosing primary and secondary contradictions in complicated real situations, `yao-bayesian-skill` for evidence updating, `yao-business-skill` for structured business analysis, `yao-kelly-skill` for position sizing, and `yao-gametheory-skill`. Alongside those sit `yao-demand-skill`, `yao-expert-skill`, `yao-doctor-skill` for diagnosing security risks in skills and AI workbench configurations, `yao-websecurity-skill` for authorized security review, `yao-tutorial-skill` for producing tutorial documents, `yao-weread-skill` for visualising personal reading data, `yao-copyright-skill`, and a `yao-open-skills-sync` entry describing the sync process itself.

The depth is uneven by design, and the README shows how to enter each one. For the crux skill it gives a ten-step reading order, starting from the public description document, through the Chinese and English directory READMEs, into `SKILL.md`, then the references on intake and questioning, theory anchors, the contradiction model and the report export pipeline, and finally the example reports and reference materials.

That structure is the pattern across the collection: a description document in `docs/skills/`, a directory under `skills/` with its own README in at least Chinese and sometimes English, a `SKILL.md` entry point, and a `references/` folder holding the theory and the contracts. A skill is a small documented system, not a prompt string.

Where output goes, and what stays on your machine

Several skills describe their output formats, and the pattern is consistent enough to be a house style. The crux skill defaults to generating Markdown, HTML, DOCX, PDF and a report JSON. The web security skill outputs Excel, HTML, Markdown, PDF and a sanitized JSON, with the HTML supporting Chinese and English switching and a sticky top navigation.

The security skill's design is the most careful thing in the collection. Instead of calling a scanner, it reads the system code, routes, authentication, data model, deployment configuration, dependencies and AI and LLM integrations first, then selects the relevant checks from an ontology of 275 vulnerability items and produces a reviewable scoring sheet. It supports five review modes: `static`, `dynamic-safe`, `dynamic-active`, `online-authorized` and `hybrid`. Local code and GitHub repositories must be copied or cloned into a fresh temporary directory first, with build, run, test and report generation all happening inside that isolated workspace, and destructive checks such as blind SSRF and out-of-band callbacks, brute forcing, file changes, database writes and resource stress are restricted to isolated temporary deployments.

The same boundary shows up elsewhere. The crux skill ships three fictional business examples and downloadable reference material, with real cases and private inputs kept out of the repository. The WeRead skill reads its API key only from environment variables, and its real reports do not enter the public repository by default. That discipline is the collection's actual contribution.

Published skills versus planned capability lines

The README keeps two different lists and is explicit that they are not the same thing. Three capability lines are described as planned long-term work, styled to be function-oriented and verb-like so the naming system does not fragment. Skill Doctor, diagnosing security risks in skills and AI workbench configurations, is already collected as `yao-doctor-skill`. Skill Optimizer, improving a skill's structure, execution quality and maintainability, and Skill Ranker, ranking skills on real measured results, are named as directions.

The README says directly that these names represent product direction and do not mean all of them are already collected into the repository as standalone skills, and that published capabilities and planned capability lines are maintained separately. That is an unusually honest thing to find in a project README, and it is the section to read first if you arrived from a search result promising a specific skill.

The recommended entry point for the method behind all of this is a different repository, `yao-meta-skill`, which handles the systematic creation, evaluation, governance and packaging of skills. The relationship is described in two lines: `yao-meta-skill` defines how to create, evaluate, govern and package skills systematically, while `yao-open-skills` collects the results worth publishing. One is described as the meta-method engine, the other as the public productisation layer.

Editorial conclusion

This repository is worth reading for its governance rather than for anything you can install. There is no package to `pip install` and no command to run; what it offers is a documented standard for deciding which AI skills may be published, which is the hard part that most skill collections skip. Two caveats belong in your reading of it. The README is written in Chinese and the skill catalogue it describes is split across many document sets, so budget real reading time rather than skimming. And the repository draws a firm line between skills that exist and capability lines that are only planned, with Skill Doctor already published and Skill Optimizer and Skill Ranker still on the roadmap. If you want a working skill, open one entry such as `yao-crux-skill` and read its `SKILL.md`; if you want to publish your own, start with `docs/publishing-rules.md` and `docs/naming-conventions.md`, which are the files that decide what gets accepted.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. yaojingang/yao-open-skills on GitHub