Built-in schemas

manni meta bundles twenty-three schemas. You reference any of them by id, with no file to write, no URL to host, and no network call at validation time. This page is the registry: what each one constrains, whether it requires anything, and which are applied when you pass no flags at all.

Run manni meta schemas to print the same list from the version you have installed.

The registry

Id	Constrains	Requires	On by default	JSON	Details
google:okf:0.1	type, title, description, resource, tags, timestamp	type	Yes	okf/0.1.json	OKF schema
passo-uno:seven-action:1.0	action	nothing	Yes	seven-action/1.0.json	Taxonomy schemas
diataxis:diataxis:1.0	type	type	No	diataxis/1.0.json	Taxonomy schemas
tgdp:templates:1.0	type	type	No	tgdp/1.0.json	Taxonomy schemas
docusaurus:docs:3.10	25 Docusaurus docs fields	nothing	No	docusaurus-docs/3.10.json	Docusaurus schemas
docusaurus:blog:3.10	20 Docusaurus blog fields	nothing	No	docusaurus-blog/3.10.json	Docusaurus schemas
docusaurus:pages:3.10	9 Docusaurus pages fields	nothing	No	docusaurus-pages/3.10.json	Docusaurus schemas
astro:starlight:0.41	15 Starlight front matter fields	title	No	starlight/0.41.json	Platform schemas
antora:page:3.1	10 Antora page header attributes	title	No	antora/3.1.json	Platform schemas
sphinx:docinfo:9.1	5 Sphinx file-wide docinfo fields	nothing	No	sphinx/9.1.json	Platform schemas
myst:frontmatter:1.10	41 MyST page frontmatter fields	nothing	No	myst/1.10.json	Platform schemas
ogp:article:1.0	17 Open Graph and article:* properties	og:title, og:type, og:url, og:image	No	ogp/1.0.json	Metadata vocabularies
dcmi:elements:1.1	the 15 Dublin Core elements	nothing	No	dcmi/1.1.json	Metadata vocabularies
microsoft:learn:1.0	16 Microsoft Learn attributes	title, description, author, ms.author, ms.date	No	microsoft-learn/1.0.json	Metadata vocabularies
oasis:dita-metadata:1.3	17 DITA prolog and topicmeta keys	nothing	No	dita/1.3.json	DITA schema
hugo:page:0.165	28 Hugo front matter fields	nothing	No	hugo/0.165.json	Platform schemas
jekyll:page:4.4	7 Jekyll front matter variables	nothing	No	jekyll/4.4.json	Platform schemas
vitepress:page:1.6	16 VitePress front matter options	nothing	No	vitepress/1.6.json	Platform schemas
x:cards:1.0	23 twitter:* card tags	twitter:card	No	x-cards/1.0.json	Metadata vocabularies
agentskills:skill:1.0	the 6 Agent Skills SKILL.md fields	name, description	No	agent-skills/1.0.json	Agent Skills schemas
anthropic:claude-skill:2.1	20 Claude Code SKILL.md fields	nothing	No	claude-skill/2.1.json	Agent Skills schemas
mkdocs:material:9.7	19 MkDocs and Material front matter keys	nothing	No	mkdocs-material/9.7.json	Platform schemas
anthropic:claude-subagent:2.1	18 Claude Code agent definition fields	name, description	No	claude-subagent/2.1.json	Claude Code subagent schema

All twenty-three use Draft 2020-12 and are built-in references. A typo in an id is reported as an unknown built-in rather than a missing file.

Twenty-two of them allow additional properties. agentskills:skill:1.0 is the one exception, and not out of strictness. The tooling that packages a skill for distribution hard-errors on a key outside the standard’s six rather than ignoring it. A schema that tolerated unknown keys would pass exactly the file that cannot ship. See Agent Skills schemas.

The published URLs

Every built-in is also served as plain JSON, at a version-pinned path under https://hawkeyexl.github.io/manni/schemas/. The same bytes stay served under the pre-rename base, https://hawkeyexl.github.io/docmeta/schemas/, and manni resolves both spellings to the bundled copy, so a $schema line or a $ref written before the rename keeps working offline. New references should use the current base:

https://hawkeyexl.github.io/manni/schemas/okf/0.1.json
https://hawkeyexl.github.io/manni/schemas/seven-action/1.0.json
https://hawkeyexl.github.io/manni/schemas/diataxis/1.0.json
https://hawkeyexl.github.io/manni/schemas/tgdp/1.0.json
https://hawkeyexl.github.io/manni/schemas/docusaurus-docs/3.10.json
https://hawkeyexl.github.io/manni/schemas/docusaurus-blog/3.10.json
https://hawkeyexl.github.io/manni/schemas/docusaurus-pages/3.10.json
https://hawkeyexl.github.io/manni/schemas/starlight/0.41.json
https://hawkeyexl.github.io/manni/schemas/antora/3.1.json
https://hawkeyexl.github.io/manni/schemas/sphinx/9.1.json
https://hawkeyexl.github.io/manni/schemas/myst/1.10.json
https://hawkeyexl.github.io/manni/schemas/ogp/1.0.json
https://hawkeyexl.github.io/manni/schemas/dcmi/1.1.json
https://hawkeyexl.github.io/manni/schemas/microsoft-learn/1.0.json
https://hawkeyexl.github.io/manni/schemas/dita/1.3.json
https://hawkeyexl.github.io/manni/schemas/hugo/0.165.json
https://hawkeyexl.github.io/manni/schemas/jekyll/4.4.json
https://hawkeyexl.github.io/manni/schemas/vitepress/1.6.json
https://hawkeyexl.github.io/manni/schemas/x-cards/1.0.json
https://hawkeyexl.github.io/manni/schemas/agent-skills/1.0.json
https://hawkeyexl.github.io/manni/schemas/claude-skill/2.1.json
https://hawkeyexl.github.io/manni/schemas/mkdocs-material/9.7.json
https://hawkeyexl.github.io/manni/schemas/claude-subagent/2.1.json

They exist for three jobs. You can $ref a built-in from a schema of your own, or use one with a JSON Schema tool that is not manni meta. You can also read the actual JSON instead of a description of it.

Inside manni meta, a published URL costs nothing. manni meta recognises its own URLs and answers them from the copy bundled in the package. There is no request, no timeout, and no dependence on GitHub Pages being up. --offline and an air-gapped build work exactly as they do with the id. A schemaTrust policy that refuses URLs still accepts these, because they reach nothing. The two spellings are interchangeable:

---
$schema: https://hawkeyexl.github.io/manni/schemas/okf/0.1.json
type: how-to
---

Each schema's `$id` is not its URL, on purpose

Open one of the files and you will see "$id": "google:okf:0.1" rather than the https://… address you fetched it from. Some strict JSON Schema tooling warns about that mismatch. The warning is expected and the file is not broken.

The $id is manni meta’s reference for the schema. It is what a document’s $schema names, what Ajv de-duplicates registrations on, and what appears in every report. Changing it to the URL would move all three at once and would break every document already carrying $schema: google:okf:0.1. The retrieval URI and the identifier are simply two different names for one schema, and both resolve.

Extend a built-in with $ref

The reason a URL beats a copy-paste. Reference a built-in from your own schema and add to it, by either name. The id and the URL both work, and neither touches the network:

house.schema.json

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "allOf": [{ "$ref": "google:okf:0.1" }],
  "required": ["title", "owner"],
  "properties": {
    "owner": { "type": "string", "minLength": 1 }
  }
}

Every rule the built-in carries still applies, and yours are added on top. That is composition inside one schema. Listing two schemas in a set is different. A set applies each schema whole and attributes failures separately. A $ref lets you narrow or extend what the built-in said.

A published URL never changes, and that is the point

Each of these paths is immutable. The bytes served at schemas/okf/0.1.json today are the bytes served there for good. A fix to a built-in ships as a new version file rather than an edit to a published one. A CI check hashes every schema against a committed manifest and fails the build if an already-published version is altered. This is enforced rather than promised.

Two hosting caveats apply to anything load-bearing outside manni meta. GitHub Pages can return 404 briefly during a deploy, and its Access-Control-Allow-Origin: * is current behaviour rather than a contract. If a build must not depend on either, vendor the file into your own repository and reference the local copy.

Two kinds of built-in

The Requires column above is the distinction that matters when you pick one.

Editorial schemas describe what a page is. google:okf:0.1 and the two type vocabularies demand their key. Adopting them is a claim that every page carries that classification, which makes an unclassified page a gap rather than an abstention. Turning one on for the first time reports every page that has not caught up yet.

Platform schemas describe what your site generator accepts. A platform schema requires exactly what the generator refuses to build without, and nothing more. What it demands is a fact about the tool, not an editorial choice manni meta made for you.

That cuts both ways. The three docusaurus:* schemas and sphinx:docinfo:9.1 require nothing, because those tools mark no field as mandatory. Switching one on cannot fail a page that was already building. astro:starlight:0.41 and antora:page:3.1 both require title, because Starlight and Antora both error without a page title. A page failing that check was already broken, and manni meta is only telling you sooner.

The three agent schemas are platform schemas of a different sort: the platform is the agent runtime rather than a site generator. anthropic:claude-skill:2.1 requires nothing, because Claude Code marks every SKILL.md field optional. agentskills:skill:1.0 requires name and description, because the open standard does and the packaging tools refuse a skill without them. anthropic:claude-subagent:2.1 requires the same two for a third reason. Claude Code will not load an agent definition that is missing either. See Agent Skills schemas and Claude Code subagent schema.

Full field tables are on the Platform schemas, Agent Skills schemas, Claude Code subagent schema and Docusaurus schemas pages.

Vocabulary schemas are a third kind. They describe a document to something outside your docs site: a social card renderer (ogp:article:1.0), a catalogue or repository (dcmi:elements:1.1), or another publisher’s build (microsoft:learn:1.0). Open Graph is the one built-in that checks something no build tool checks. Nothing fails when og:image is missing, and the page just renders badly everywhere it is shared. See Metadata vocabularies.

The two kinds mostly claim different keys, so they compose. One run can hold a page to your generator’s contract and to your own standard, attributing each failure to the schema that raised it:

manni meta validate docs/ -s docusaurus:docs:3.10 -s diataxis:diataxis:1.0

One overlap to know about: `tags`

Stacking a Docusaurus schema with google:okf:0.1 is the exception. Both define tags, and their definitions disagree: OKF allows a list of strings only, while Docusaurus also allows a tag object. Every schema in a set applies in full, so a page using the object form fails OKF:

✗ docs/install.md
    /tags/0  must be string  (line 6)  [google:okf:0.1]

If your docs set uses object tags, pair the Docusaurus schema with diataxis:diataxis:1.0 or tgdp:templates:1.0 rather than with OKF, or use the string form. Those two claim only type. title and description also appear in both, and those definitions agree.

`diataxis` and `tgdp` are alternatives, not a pair

Both claim type. Stacking them is legal but narrows the accepted values to the intersection of the two vocabularies, which is rarely what anyone wants. Pick one. See which ones compose.

What runs when you pass no flags

Only two of the twenty-three are in the default set:

google:okf:0.1 + passo-uno:seven-action:1.0

Everything else is opt-in. Seven-Action is safe to carry by default because it requires nothing. It rules that an action, if present, is legitimate, without insisting on one. The default set sits at the bottom of the precedence chain. It applies only when no --schema flag, no in-file $schema, and no config rule matched.

Turn one on

Three ways, in precedence order. The first one that matches wins, and each replaces the set rather than adding to it.

Command line

Repeat -s to build a set. This overrides everything else for the whole run:

manni meta validate docs/ -s docusaurus:docs:3.10 -s google:okf:0.1

Config file

Set a default for the repo, and override it per directory. This is the right place for the Docusaurus schemas, since a Docusaurus site has three content roots with three different contracts:

manni.config.yaml

meta:
  schemas:
    - google:okf:0.1
  overrides:
    - files: "docs/**"
      schemas:
        - docusaurus:docs:3.10
        - diataxis:diataxis:1.0
    - files: "blog/**"
      schemas:
        - docusaurus:blog:3.10
    - files: "src/pages/**"
      schemas:
        - docusaurus:pages:3.10

In the document

A document can name its own schema, which beats any config rule:

---
$schema: diataxis:diataxis:1.0
type: how-to
---

$schema also takes a list, and manni meta strips the key before validating, so it never trips a schema that forbids unknown properties.

Version ids

A built-in id is vendor:name:version. The version segment tracks the upstream standard, not manni meta’s own release number:

• google:okf:0.1 is OKF v0.1.
• docusaurus:docs:3.10 is the front matter contract of Docusaurus 3.10.
• hugo:page:0.165 is the contract as of Hugo 0.165, and Hugo releases monthly. Its front matter fields change far more slowly, so this id is not expected to move every month. A new one ships when the contract changes, not when Hugo does.
• mkdocs:material:9.7 versions on Material for MkDocs 9.7, not on MkDocs 1.6, even though the vendor segment says mkdocs. MkDocs itself defines two front matter keys and Material defines the other seventeen. Material is what the contract tracks, and Material’s version is the one that can move it. astro:starlight:0.41 pairs a platform with a theme the same way. Ids are stable. A new upstream version arrives as a new id rather than a change to an existing one. Upgrading manni meta never silently retightens a check you already passed. Pin the id you validated against and move it deliberately.

If none of these fit

The built-ins are a shortcut, not a ceiling. A docs set with its own field names or its own vocabulary needs its own schema. That is a .json file you reference by path, or a URL you host for several repos to share. Copying the closest built-in and editing it is usually faster than starting from nothing.

Author a schemaWrite a JSON Schema of your own, from a one-field example up to a full standard.

Schema resolution referenceThe precedence chain, the three reference kinds, and the supported dialects.

Built-in OKF schemaEvery field in google:okf:0.1, its formats, and the upstream spec.

Built-in taxonomy schemasThe diataxis, tgdp, and seven-action vocabularies, and which ones compose.

Built-in Docusaurus schemasThe docs, blog, and pages front matter contracts of Docusaurus 3.10.