Built-in platform schemas

Eight built-ins describe the front matter contract of a documentation toolchain that is not Docusaurus. Like the Docusaurus schemas, they are platform schemas: they say what your site generator accepts, not what your team has agreed a page should say. That makes them safe to stack under any vocabulary.

Id	Toolchain	Files it fits	Requires
`astro:starlight:0.41`	Astro Starlight 0.41	`.md`, `.mdx`	`title`
`antora:page:3.1`	Antora 3.1	`.adoc`, `.asciidoc`	`title`
`sphinx:docinfo:9.1`	Sphinx 9.1	`.rst`	nothing
`myst:frontmatter:1.10`	mystmd 1.10	`.md`	nothing
`hugo:page:0.165`	Hugo 0.165	`.md`	nothing
`jekyll:page:4.4`	Jekyll 4.4	`.md`, `.markdown`	nothing
`vitepress:page:1.6`	VitePress 1.6	`.md`	nothing
`mkdocs:material:9.7`	MkDocs 1.6 + Material 9.7	`.md`	nothing

Each schema has a page of its own, with its field table, an example page, and the finding a common mistake produces:

This page covers what the eight share, and how to stack one with a vocabulary.

What a platform schema requires

The rule across every platform built-in is to require exactly what the generator refuses to build without. What one demands is therefore a fact about the tool, not a judgement manni meta made on your behalf.

Docusaurus and Sphinx mark no field as mandatory, so their schemas require nothing. They can only ever fail a page on the shape of a value it already carries. Starlight and Antora both error without a page title, so both schemas demand title. A page failing that check was already broken, and manni meta is telling you at review time instead of at build time. MyST requires nothing because it will lift a missing title from the first heading in the document.

Hugo, Jekyll, VitePress and MkDocs require nothing either, for the plainest reason of the lot. All four render a page that has no front matter at all. Hugo falls back to a title derived from the file name. MkDocs works down a list of four title sources and stops at the first that answers. VitePress has a default for every option. In Jekyll it is the presence of the --- block, not its contents, that marks a file for processing. An empty one is valid. That makes all four pure shape checks, which is where their value is. The mistakes they catch are the ones the generator accepts without complaint and then acts on wrongly.

Composing with a vocabulary

A platform schema claims the keys your generator reads. A vocabulary claims the keys your team agreed on. They mostly do not overlap, so one run can hold a page to both and attribute each failure to the schema that raised it:

manni meta validate docs/ -s astro:starlight:0.41 -s diataxis:diataxis:1.0

title and description appear in several of these, and every definition agrees that they are strings, so stacking is safe.

meta:
  schemas:
    - astro:starlight:0.41
    - diataxis:diataxis:1.0

Antora content lives in per-component modules/*/pages trees, so the override is usually a glob rather than a single root:

meta:
  schemas:
    - google:okf:0.1
  overrides:
    - files: "**/modules/*/pages/**"
      schemas:
        - antora:page:3.1

Sphinx and MyST can coexist in one tree, split by extension:

meta:
  overrides:
    - files: "**/*.rst"
      schemas:
        - sphinx:docinfo:9.1
    - files: "**/*.md"
      schemas:
        - myst:frontmatter:1.10

Hugo’s content root is content/, and a docs section usually sits under it:

meta:
  schemas:
    - google:okf:0.1
  overrides:
    - files: "content/**"
      schemas:
        - hugo:page:0.165
        - diataxis:diataxis:1.0

Both keep pages at the repo root, so the split is by directory rather than by extension:

meta:
  overrides:
    - files: "_posts/**"
      schemas:
        - jekyll:page:4.4
    - files: "docs/**"
      schemas:
        - vitepress:page:1.6

MkDocs keeps everything under docs_dir, so one override covers the site:

meta:
  schemas:
    - google:okf:0.1
  overrides:
    - files: "docs/**"
      schemas:
        - mkdocs:material:9.7
        - diataxis:diataxis:1.0