Hub review checks

For: plugin authors.

Understand what the hub checks before accepting a listing.

What the hub checks

The hub's CI inspects every new version again and refuses it when the commit packs to other content than the listing pins, the forge reports another repository ID, a file holds what looks like a leaked secret, a pinned package has a known vulnerability, the README breaks one of its limits, or the licence checks fail (the licence).

A maintainer reviews your first plugin, its skills and prompt text included, every growth in permissions (a shell or write tool, a new tool process, a hook, network access, a package, a secret, outside input), a change of hands (another publisher, owner or repository), a licence text the engine does not recognise, and a plugin past the hub's size caps, which it reviews rather than refuses. A name that looks like another publisher's is flagged.

A tool ID, agent or flow name with the prefix oz0_ or oz0- or a look-alike of it, or one that a verified ai.oz0 plugin has, is refused, and so is a new listing with a verified plugin's plugin name; a listed plugin that had such a name before the rule keeps it in new versions, with a warning. A version that shares a tool ID, an agent or flow name or the plugin name with another listing is not refused, but its page and the index say it cannot be installed together with that listing.

A listed version never changes and a listed name is never given to someone else: to fix a version, list a new one and withdraw the old one.

A version whose agents or tools pass their size budget is not refused either: its Generated block carries the figures and a warning, which the maintainer sees.

Once listed, a version stays in the index even if its source disappears: the hub publishes from what it recorded, so one deleted repository never stops it from renewing its signed index. Its daily re-scan retries a source it cannot fetch, and proposes quarantining the version only after three days in a row.

What a listing shows

A version's page on the hub shows what the engine generated, never what you wrote about it: its permissions, requirements and contents, and, when your plugin commits its measured listing (tools.listing.json, which plugin test writes), each function with an estimate of what its definition costs per model request and each agent's capability card.

Without the listing, the tools show as not listed. A listing whose files changed since plugin test measured them says it is stale. A version whose listing carries a passing plugin test report shows that its evals passed, with which engine and on which day, and nothing more (see version states).

It also shows the facts and facets the engine computed (its kind, the models it asks for, its harnesses, what it connects to, and each function's type and default, which the hub's filters read; see Find a plugin by what it needs).

The README is the documentation

The page shows the version's README.md, read from the signed package, as the plugin's documentation. There is no Documentation link and no docs folder: plugin inspect lists the README, each image it shows from the package and the licence files by path, size and SHA-256, the hub stores exactly those files, and its page shows only bytes whose digest matches the signed index. The page renders:

• headings, gathered into a contents list, tables, callouts (> [!NOTE], [!TIP], [!IMPORTANT], [!WARNING], [!CAUTION]), task lists, footnotes and code blocks, highlighted;
• images from the package, PNG, JPEG, WebP or GIF, by a path relative to the README, at the size the engine measured;
• Mermaid diagrams in mermaid code blocks, which the hub draws when it builds the page, with their source beside them.

It never shows raw HTML (it is dropped), an image or badge from another host (its alt text shows instead), or an SVG. The README's limits, and what to do when it is too long, are on Plugin limits: say what the plugin does, how to set it up and its limits, and link longer guides on your own site.

The README's first section, after its title and up to the next heading, is also the listing's excerpt, reduced to paragraphs, emphasis, code, lists and web or mail links, at most 2,000 characters: oz0 hub search, the console's Install dialog and the hub's search show it. Say there in a sentence or two what the plugin does and for whom.

Links and the repository

For a Git source, the page links Repository under Source, marked as from the verified source: the repository's address at the pinned commit and the plugin's folder in it, in its forge's form (/tree/<commit>/<path> on GitHub, /-/tree/<commit>/<path> on GitLab, /src/commit/<commit>/<path> on Gitea). You never write it, so it always points at the code that was inspected. A bundle or an OCI artifact has none.

The links you write are a homepage (--homepage), an issues page (--issues) and a security contact (--security, https:// or mailto:); the page shows them as written by the authors, not checked by the hub. A listing file with links.repository or links.documentation is refused.

The licence

The page says what the licence files read as and what license: declares, never that a licence is valid or that a use is allowed:

A text it does not recognise links the stored copy of the file, so you can read it on the page.

Used by and the graph

Used by names the listed plugins whose uses: names this one, each linking to its page (at most 200, then how many more). The Contents tab starts with a graph of the plugin's parts and how they connect: its agents, tools and functions, flows and their steps, event sources, channels, connections, skills, hooks, evals and harnesses, a set's members, and the plugins it uses. A grouped list says the same in words, for screen readers and without script. plugin inspect computes the graph from the manifest; one past 1,000 parts or 2,000 links is cut and says so.

Advisories in the index

The hub publishes its advisory file (advisories/advisories.json, known vulnerabilities and packages it refuses) in its signed index, so every cluster that trusts the index scans its installed plugins against it. When an advisory names a fixed version of a package a listed version locks, the hub's bot opens a pull request in the hub repository, never on your repository: it marks that version deprecated with a reason naming the package, the advisory and the fixed version, for a maintainer to merge. Release a version that locks the fixed package, and it is listed as any release is.